AZ-700 Designing and Implementing Microsoft Azure Networking Solutions Questions and Answers

No

subnet1(WM1- > NSG1 outbound- > NSG10 outbound)- > subnet2(NSG1 inbound- > NSG11 inbound- > VM2)

Yes

NSG10 blocks ICMP from VNet4 (source 10.10.0.0/16) but it is not blocked from VM2 ג €™s subnet (VNet1 /Subnet2).

No

NSG11 blocks RDP (port TCP 3389) destined for ג €˜VirtualNetwork ג €™. VirtualNetwork is a service tag and means the address space of the virtual network (VNet1) which in this case is 10.1.0.0/16. Therefore, RDP traffic from subnet2 to anywhere else in VNet1 is blocked.

Box 1: VM2, VM3 and VM4.

VM1 is in VNet1/Subnet1. VNet1 is peered with VNet2 and VNet3.

There are no NSGs blocking outbound ICMP from VNet1. There are no NSGs blocki ng inbound ICMP to VNet1/Subnet2, VNet2 or VNet3. Therefore, VM1 can ping VM2 in VNet1/Subnet2, VM3 in VNet2 and VM4 in VNet3.

Box 2:

VM4 is in VNet3. VNet3 is peered with VNet1 and VNet2. There are no NSGs blocking outbound ICMP from VNet3. There are no NSGs blocking inbound ICMP to VNet1/Subnet1, VNet1/Subnet2 or VNet2 from VNet3 (NSG10 blocks inbound ICMP from VNet4 but not from VNet3). Therefore, VM4 can ping VM1 in VNet1/Subnet1, VM2 in VNet1/Subnet2 and VM3 in VNet2.

NGS1 only

VM2, VM3, VM4 and VM5

There is no virtual network peering between VM4’s VNet (VNet3) and VM5’s VNet (VNet4). To enable the VMs to communicate over the Microsoft backbone network a VNet peering is required between VNet3 and VNet4.

Box 1: No

Zone2.contoso.com is not linked to any virtual networks. Therefore, no VMs are able to resolve names in the zone.

Box 2: Yes

VM4 is in VNet3. Zone1.contoso.com has a link to VNet3 and auto-registration is enabled on the link.

Box3: No

VNet3 is linked to zone1.contoso.com and auto-registration is enabled on the link. A virtual network can only have one registration zone. You can link zone2.contoso.com to VNet3 but you won’t be able to enable auto-registration on the link.

To prevent all Azure hosts outside of subnet1-2 from connecting to TCP port 5585 on hosts within subnet 1-2, you can use a  Network Security Group (NSG) . This solution is straightforward and minimizes administrative effort.

Step-by-Step Solution

Step 1: Create a Network Security Group (NSG)

Navigate to the Azure Portal .

Search for “Network security groups”  and select it.

Click on “Create” .

Enter the following details :

Subscription : Select your subscription.

Resource Group : Select an existing resource group or create a new one.

Name : Enter a name for the NSG (e.g., NSG-Subnet1-2).

Region : Select the region w here your virtual network is located.

Click on “Review + create”  and then  “Create” .

Step 2: Create an Inbound Security Rule

Navigate to the newly created NSG .

Select “Inbound security rules”  from the left-hand menu.

Click on “Add”  to create a new rule.

Ent er the following details :

Source : Select  Service Tag .

Source Service Tag : Select  VirtualNetwork .

Source port ranges : Leave as *.

Destination : Select  IP Addresses .

Destination IP addresses/CIDR ranges : Enter the IP range of subnet1-2 (e.g., 10.1.2.0/24).

Destination port ranges : Enter 5585.

Protocol : Select  TCP .

Action : Select  Deny .

Priority : Enter a priority value (e.g., 100).

Name : Enter a name for the rule (e.g., Deny-TCP-5585).

Click on “Add”  to create the rule.

Step 3: Associate the NSG with Subnet1-2

Navigate to the virtual network  that contains subnet1-2.

Select “Subnets”  from the left-hand menu.

Select subnet1-2  from the list of subnets.

Click on “Network security group” .

Select the NSG  you created (NSG-Subnet1-2).

Click on “Save” .

Explanation

Netwo rk Security Group (NSG) : NSGs are used to filter network traffic to and from Azure resources in an Azure virtual network.  They contain security rules tha t allow or deny inbound and outbound traffic based on source and destination IP addresses, port, and pr otocol 1 .

Inbound Security Rule : By creating a rule that denies traffic on TCP port 5585 from any source outside of subnet1-2, you ensure that only hosts within subnet1-2 can connect to this port.

Association with Subnet : Associating the NSG with subnet1-2 ensures that the security rules are applied to all resources within this subnet.

By following these steps, you can effectively prevent all Azure hosts outside of subnet1-2 from connecting to TCP port 5585 on hosts within subnet1-2, while minimizing administrative effort.

To archive all the metrics of VNET1 to an existing storage account, you can use Azure Monitor’s diagnostic settings. Here’s how you can do it:

Step-by-Step Solution

Step 1: Navigate to VNET1 in the Azure Portal

Ope n the Azure Portal .

Search for “Virtual networks”  and select  VNET1  from the list.

Step 2: Configure Diagnostic Settings

In the VNET1 blade , select  “Diagnostic settings”  under the “Monitoring” section.

Click on “Add diagnostic setting” .

Step 3: Set Up the Diagnostic Setting

Enter a name  for the diagnostic setting (e.g., VNET1-Metrics-Archive).

Select the metrics  you want to archive. You can choose from various metrics like TotalBytesReceived, TotalBytesSent, etc.

Under “Destination details” , select  “Archive to a storage account” .

Choose the existing storage account  where you want to archive the metrics.

Configure the retention period  if needed.

Step 4: Save the Configuration

Review your settings  to ensure everything is correct.

Click on “Save”  to apply the diagnostic setting.

Explanation

Diagnostic Settings : These allow you to collect and route metrics and logs from your Azure resources to various destinations, including storage accounts, Log Analytics workspaces, and Event Hubs.

Metrics : Metrics provide num erical data about the performance and health of your resources. Archiving these metrics helps in long-term analysis and compliance.

Storage Account : Using an existing storage account ensures that the metrics are stored securely and can be accessed for futu re analysis.

By following these steps, you can ensure that all the metrics of VNET1 are archived to your existing storage account, enabling you to monitor and analyze the performance and health of your virtual network over time.

Here are the steps and explanations for ensuring that connections to the storage34280945 storage account can be made by using an IP address in the 10.1.1.0/24 range and the name stor-age34280945.pnvatelinlcblob.core.windows.net:

To allow access from a specific IP address range, you need to configure the Azure Storage firewall and virtual network setti ngs for your storage account.  You can do this in the Azure port al by selecting your storage account and then sele cting Networking under Settings 1 .

On the Networking page, sele ct Firewall s and virtual networks, and then select Selected networks under Allow access from 1 . This will block all access to your storage account except from the networks or resources that you specify.

Under Firewall, select Add rule, and then enter 10. 1.1.0/24 as the IP address or range.  You can also enter an option al rule name and description 1 . This will allow access from any IP address in the 10.1.1.0/24 range.

Sele ct Save to apply your changes 1 .

To map a custom domain name to your storage accou nt, you need to create a CNAME record with your domain provider that points to your s torage account endpoint 2 . A CNAME record is a type of DNS record that maps a source domain name to a desti nation domain name.

Sign in to your domain registrar’s website, and then go to the page for managing DNS settings 2 .

Create a CNAME record with the following information 2 :

Source domain name: stor-age34280945.pnvatelinlcblob.core.windows.net

Destination domain name: stor-age34280945.pnvatelinlcblob.core.windows.ne t

Save your changes a nd wait for the DNS propagation to take e ffec t 2 .

To register the custom domain name with Azure, you need to go back to the Azure portal and select you r storage account.  Then select Custom domain under Blob service 2 .

On the Custom domain page, enter stor-age34280945.pnvatelinlcblob.core.windows .net as the custom domain name and select Save 2 .

Here are the steps and explanations for ensuring that subnet4-3 can accommodate 507 hosts:

To determine the subnet size that can ac commoda te 507 hosts, you need to use the formula:  number of hosts = 2^( 32 - n) - 2 , where  n  is the number of bits in the subnet mask 1 . You need to find the value of  n  that satisfies this equation for 507 hosts.

To solve this equation, you can use trial and error or a binary search method. For example, you can start with  n = 24 , which is the default subnet mask for Class C networks. Then, plug in the value of  n  into the formula and see if it is too big or too small for 507 hosts.

If you try  n = 24 , you get  number of hosts = 2^(32 - 24) - 2 = 254 , which is too small. You need to increase the value of  n  to get a larger number of hosts.

If you try  n = 25 , you get  number of hosts = 2^(32 - 25) - 2 = 510 , which is just enough to accommodate 507 hosts. You can stop here or try a smaller value of  n  to see if it still works.

If you try  n = 26 , you get  number of hosts = 2^(32 - 26) - 2 = 254 , which is too small again. You need to decrease the value of  n  to get a larger number of hosts.

Therefore, the smallest value of  n  that can accommodate 507 hosts is  n = 25 .  This means that the subnet mask for subnet4-3 should be  /25  or  255.255.255.128  in dot-decimal notation 1 .

To change the subnet mask for subnet4-3, you need to go to the Azure portal and select your virtual network.  Then select Subnets under Settings and select subnet4-3 from the list 2 .

On the Edit subnet page, under Address range (CIDR block), change the value from  /24  to  / 25 .  Then select Save 2 .

Here are the steps and explanations for ensuring that hosts on VNET2 can access hosts on both VNET1 and VNET3, but hosts on VNET1 and VNET3 cannot communicate through VNET2:

To connect different virtual networks in Azure, you need to use virtual network peering.  Vir tual network peering allows you to create low-latency, high-bandwidth connections between virtua l networks without using gatew ays or the internet 1 .

To create a virtual network peering, you need to go to the Azure portal and select your virtual network.  The n select Peerings under Settings a nd select + Add 2 .

On the Add peering page, enter or select the following information:

Name: Type a unique name for the peering from the source virt ual network to the destination virtual network.

Virtual network deployment model: Select Resource manager.

Subscription: Select the subscription that contains the destination virtual network.

Virtual network: Select the destination virtual network from the list or enter its resource ID.

Name of the peering from [destination virtual network] to [source virtual network] : Type a unique name for the peering from the destination virtual network to the source virtual network.

Configure virtual network access sett ings: Select Enabled to allow resources in both virtual networks to communicate with each other.

Allow forwarded traffic: Select Disabled to prevent traffic that originates from outside either of the peered virtual networks from being forwarded through eit her of them.

Allow gateway transit: Select Disabled to prevent either of the peered virtual networks from using a gateway in the other virtual network.

Use remote gateways: Select Disabled to prevent either of the peered virtual networks from using a gateway in the other virtual network as a transit point to another network.

Select Add to create the peering 2 .

Repeat the previous steps to create peerings between VNET2 and VNET1, and between VNET2 and VNET3. This will allow hosts on VNET2 to access hosts on both VNET1 and VNET3.

To prevent hosts on VNET1 and VNET3 from communicating through VNET2, you need to use network security groups (NSGs) to filter traffic between subnets.  NSGs are r ules that allow or deny inboun d or outbound traffic based on source o r destination IP address, port, or prot ocol 3 .

To create an NSG, you need to go to the Azure portal and select Create a resource. Search for network security group and select Network security group.  Then select Create 4 .

On the Create a network security group page, enter or select the following information:

Subscription: Select your subscription name.

Resource group: Select your resource group name.

Name: Type a unique name for your NSG.

Region: Select the same region as your virtual networks.

Select Review + create and then select Create to crea te your NSG 4 .

To add rules to your NSG, you need to go to the Network security groups service in the Azure portal and select your NSG.  T hen select Inbound security rule s or Outbound security rules under Settings and select + Add 4 .

On the Add inbound security rule page or Add outbound security rule page, enter or select the following information:

Source or Destination: Select CIDR block.

Source CIDR blocks or Destinatio n CIDR blocks: Enter the IP address range of the source or destination subnet that you want to filter. For example, 10.0.1.0/24 for VNET1 subnet 1, 10.0.2.0/24 for VNET2 subnet 1, and 10.0.3.0/24 for VNET3 subnet 1.

Protocol: Select Any to apply the rule t o any protocol.

Action: Select Deny to block traffic from or to the source or destination subnet.

Priority: Enter a number between 100 and 4096 that indicates the order of evaluation for this rule. Lower numbers have higher priority than higher numbers.

Na me: Type a unique name for your rule.

Select Add to create your rule 4 .

Repeat the previous steps to create inbound and outbound rules for your NSG that deny traffic between VNET1 and VNET3 subnets. For example, you can create an inbound rule that denies traffic from 10.0.1.0/24 (VNET1 subnet 1) to 10.0.3.0/24 (VNET3 subnet 1), and an outbound rule that denies traffic from 10.0.3.0/24 (VNET3 subnet 1) to 10.0.1.0/24 (VNET1 subnet 1).

To associate your NSG with a subnet, you need to go to the Virtual networks service in the Azure portal a nd select your virtual network.  Then select Subnets under Settings and select the subnet that you want to associ ate with y our NSG 5 .

On the Edit subnet page, under Network security group, select your NSG from the drop-down list.  Then select Save 5 .

Repeat the previous steps to associate your NSG with the subnets in VNET1 and VNET3 that you want to isolate from each other.

Here are the steps and explanations for ensuring that all hosts deployed to subnet3-2 connect to the internet by using the same static public IP address:

To use the same static public IP address for multiple hosts, you need to create a NAT gateway and associate it with subnet3-2.  A N AT gateway is a resourc e that performs network address translation ( N AT) for outbound traffic from a subnet 1 .  It allows you to use a single public IP address for multiple private IP addre sses 2 .

To create a NAT gateway, you need to go to the Azure portal and select Create a resource.  Search for  NAT gateway , select  NAT gat eway , then select  Create 3 .

On the Create a NAT gateway page, enter or sele ct the following information and accept the defaults for the remaining settings:

Subscription: Select your subscription name

Resource group: Select your resource group

Name: Type a unique name for your NAT gateway

Region: Select the same region as your vir tual network

Public IP address: Select Create new and type a name for your public IP address.  Select  Sta ndard  a s the SKU an d  Static  as the assignment method 4 .

Se lect  Review + create  and then select  Create  to c reate your NAT gatewa y 3 .

To associate the NAT gateway with subnet3-2, you need to go to the Virtual networks service in the Azure portal and select your virtual network.

On the Virtual network page, select Subnet s under Settings, and then select subnet3-2 from the list.

On the Edit subnet page, under NAT gateway, select your NAT gateway from the drop-down list. Then select Save.

To ensure that the owner of VNET3 receives an alert whenever an administrative operation is performed on the virtual network, you can set up an  Activity Log Alert  in Azure Monitor. Here’s how you can do it:

Step-by-Step Solution

Step 1: Create an Activity Log Alert

Navigate to the Azure Portal .

Search for “Monitor”  and select it.

In the Monitor blade , select  “Alerts”  from the left-hand menu.

Click on “New alert rule” .

Step 2: Configure the Alert Rule

Select the Scope :

Click on  “Select resource” .

Choose  “Virtual Network”  as the resource type.

Select  VNET3  from the list of virtual networks.

Define the Condition :

Click on  “Add condition” .

In the  “Signal type”  dropdown, select  “Activity Log” .

Choose  “Administrative”  as the category.

Select the specific operations you want to monitor (e.g., Microsoft.Network/virtualNetworks/write for any write operations on the virtual network).

Set the Alert Details :

Enter a  name  for the alert rule (e.g., VNET3 Admin Operations Alert).

Provide a  description  if needed.

Configure the Action Group :

Click on  “Add action group” .

Enter a  name  for the action group.

Select the  action type  (e.g., Email/SMS/Push/Voice).

Enter the  details  of the recipient (e.g., the email address of the owner of VN ET3).

Review and Create :

Review the alert rule settings.

Click on  “Create alert rule” .

Explanation

Activity Log Alerts : These alerts notify you when specific operations are performed on your Azure resources. By setting up an alert for administrative operations, you ensure that any changes to VNET3 are promptly reported.

Action Groups : These define the actions to take when an alert is triggered. You can configure notifications via email, SMS, or other methods to ensure the owner of VNET3 is informed im mediately.

Administrative Operations : Monitoring these operations helps in tracking changes and maintaining the security and integrity of your virtual network.

By following these steps, you can ensure that the owner of VNET3 receives timely alerts for any administrative operations performed on the virtual network, helping to maintain oversight and security.

To provide a single host name that routes traffic based on the origin, you can use  Azure Traffic Manager . This service allows you to route traffic to different endpoints based on various routing methods, i ncluding geographic routing.

Navigate to the Azure Portal .

Search for “Traffic Manager profiles”  and select it.

Click on “Create” .

Enter the following details :

Name : Enter a name for the Traffic Manager profile (e.g.,  ContosoTrafficManager ).

Routing method : Select  Geographic .

Subscription : Select your subscription.

Resource group : Select an existing resource group or create a new one.

Resource group location : Choose a location (this does not affect the routing).

Click on “Create” .

Navigate to the newly created Traffic Manager profile .

Select “Endpoints”  from the left-hand menu.

Click on “Add”  to add a new endpoint.

Enter the following details :

Type : Select  Exter nal endpoint .

Name : Enter a name for the endpoint (e.g.,  NewYorkEndpoint ).

FQDN : Enter  ny.contoso.com .

Geographic region : Select  “World”  (this will be adjusted later).

Click on “Add”  to save the endpoint.

Repeat the process  to add the second endpoint:

Type : Select  External endpoint .

Name : Enter a name for the endpoint (e.g.,  GermanyEndpoint ).

FQDN : Enter  de.contoso.com .

Geographic region : Select  Europe .

Navigate to the Traffic Manager profile .

Select “Configuration”  from the left-hand menu.

Under “Geographic routing” , adjust the regions:

For the  GermanyEndpoint , ensure that the geographic region is set to  Europe .

For the  NewYorkEndpoint , ensure that the geographic region is set to  World  (excluding Europe).

Use a DNS query tool  to test the routing.

From a location in Germany , query the Traffic Manager profile’s DNS name and ensure it resolves to  de.contoso.com .

From a location outside Europe , query the Traffic Manager profile’s DNS name and ensure it resolves to  ny.contoso.com .

Azure Traffic Manager : This service uses DNS to direct client requests to the most appropriate endpoint based on the routing method you choose. Geographic routing ensures that traffic is directed based on t he origin of the request.

Geographic Routing : This method allows you to route traffic based on the geographic location of the DNS query origin, ensuring that users are directed to the nearest or most appropriate endpoint.

Step-by-Step Solution Step 1: Create a Traffic Manager Profile Step 2: Configure Endpoints Step 3: Adjust Geographic Routing Step 4: Test the Configuration Explanation By following these steps, you can provide a single host name that routes traffic to  de.contoso.com  for users in Germany and to  ny.contoso.com  for users from other locations, ensuring efficient and appropriate traffic management.

Here are the steps and explanations for ensuring that the storage34280945 storage account will only accept connections from hosts on VNET1:

To restrict network access to your storage account, you need to config ure the Azure Storage firewall and virtual network settings for your storage account.  You can do this in the Azure portal by selecti ng your storage account and then selecting  Networki ng  under  Settings 1 .

O n the  Networking   page, select  Firewalls and virtual networks , and then select  Selected ne tworks  under  Allow access from 1 . This will block all access to your storage account except from the networks or resources that you specify.

Under Virtual networks, select + Add existing virtual network.  Then select VNET1 from the list of virtual networks and select the sub net that c ontains the hosts that you want to allow access to y our storage acco unt 1 .  This will enable a service endpoin t for Storage in the sub net and configure a virtual network rule f or that subnet through the Azure storage firewall 2 .

Select  Add  to add the virtual network and subnet to your storage accoun t 1 .

Select  Save  to apply your changes 1 .

Here are the steps and explanations for ensuring that requests for wwwjelecloud.com from any of your Azure virtual networks resolve to frontdoor1.azurefd.net:

To use a custom domain with your Azure Front Door, you need to create a CNAME record with your domain provider that points to the Front Door default frontend host.  A CNAME record is a type of DNS record that maps a source domain name to a destination domain name 1 .

To create a CNAME r ecor d, you need to sign in to your domain registrar’s website and go to the page for managing DNS settings 1 .

Creat e a CNAME record with the followin g information 1 :

Source domain name: wwwjelecloud.com

Destination domain name: frontdoor1.azurefd.net

Save your changes and wait for the DNS propagation to take effect 1 .

To verify the custom domain, you need to go to the Azure portal and select your Front Door profile.  Then select Domains un der Settings and select Add 2 .

On the Add a domain page, select Non-Azure validated domain as the Domain type and enter wwwjeleclou d.com as the Domain name.  Then select Add 2 .

On the Domains page, select wwwjelecloud.com and select Verify.  This will check if the CNAME record is correctly configured 2 .

Once the domain is verified, you can associate it with your Front Door endpoint. On the Domains page, select wwwjelecloud.com and select Associate endpoint.  Then select your Front Door endpoint from the drop-down list and select Associa te 2 .

To deploy Azure virtual machines to the France Central region and ensure they are in a network segment with an IP address range of 10.5.1.0/24, follow these steps:

Step-by-Step Solution

Step 1: Create a Virtual Network in France Central

Navi gate to the Azure Portal .

Search for “Virtual networks”  in the search bar and select it.

Click on “Create” .

Enter the following details :

Subscription : Select your subscription.

Resource Group : Select an existing resource group or create a new one.

Name : Enter a name for the virtual network (e.g., VNet-FranceCentral).

Region : Select  France Central .

Click on “Next: IP Addresses” .

Step 2: Configure the Address Space and Subnet

In the IP Addresses tab , enter the address space as 10.5.1.0/24.

Click on “Add sub net” .

Enter the following details :

Subnet name : Enter a name for the subnet (e.g., Subnet-1).

Subnet address range : Enter 10.5.1.0/24.

Click on “Add” .

Click on “Review + create”  and then  “Create” .

Step 3: Deploy Virtual Machines to the Virtual Network

Navi gate to the Azure Portal .

Search for “Virtual machines”  in the search bar and select it.

Click on “Create”  and then  “Azure virtual machine” .

Enter the following details :

Subscription : Select your subscription.

Resource Group : Select the same resource group used for the virtual network.

Virtual machine name : Enter a name for the VM.

Region : Select  France Central .

Image : Select the desired OS image.

Size : Select the appropriate VM size.

Click on “Next: Disks” , configure the disks as needed, and then click on  “Next: Networking” .

In the Networking tab , select the virtual network (VNet-FranceCentral) and subnet (Subnet-1) created earlier.

Complete the remaining configuration steps  and click on  “Review + create”  and then  “Create” .

Explanation

Virtual Network : A vi rtual network in Azure allows you to create a logically isolated network that can host your Azure resources.

Address Space : The address space 10.5.1.0/24 ensures that the VMs are in a specific network segment.

Subnet : Subnets allow you to segment the virtu al network into smaller, manageable sections.

Region : Deploying the virtual network and VMs in the France Central region ensures that the resources are physically located in that region.

By following these steps, you can ensure that your Azure virtual machines in the France Central region are deployed within the specified IP address range of 10.5.1.0/24.

For the first question, only ExpressRoute GW SKU Ultra Performance support FastPath feature.

For the second question, vnet1 will connect to ExpressRoute gw, once Vnet1 peers with Vnet2, the traffic from on-premise network will bypass GW and Vnet1, directly goes to Vnet2, while this feature is under public preview.

====Reference

ExpressRoute virtual network gateway is designed to exchange network routes and route network traffic. FastPath is designed to improve the data path performance between your on-premises network and your virtual network. When enabled, FastPath sends network traffic directly to virtual machines in the virtual network, bypassing the gateway.

To configure FastPath, the virtual network gateway must be either:

Ultra Performance

ErGw3AZ

VNet Peering - FastPath will send traffic directly to any VM deployed in a virtual network peered to the one connected to ExpressRoute, bypassing the ExpressRoute virtual network gateway.

https://docs.microsoft.com/en-us/azure/expressroute/about-fastpath

Gateway SKU

https://docs.microsoft.com/en-us/azure/expressroute/express route-about-virtual-network-gateways

VNet 1 will get the default from BGP and propagate it to VNET 2 and 3

Yes, Yes, No