AZ-700 Questions and Answers

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

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/expressroute-about-virtual-network-gateways

To achieve the task of ensuring that virtual machines on VNET1 and VNET2 are included automatically in a DNS zone named contoso.azure, and that they can resolve the names of the virtual machines on either virtual network, you can follow these steps:

Step-by-Step Solution

Step 1: Create a Private DNS Zone

Navigate to the Azure Portal.

Search for “Private DNS zones” in the search bar and select it.

Click on “Create”.

Enter the DNS zone name as contoso.azure.

Select the appropriate subscription and resource group.

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

Step 2: Link VNET1 and VNET2 to the DNS Zone

Go to the newly created DNS zone (contoso.azure).

Select “Virtual network links” from the left-hand menu.

Click on “Add”.

Enter a name for the link (e.g., VNET1-link).

Select the subscription and virtual network (VNET1).

Enable auto-registration to ensure that VMs are automatically registered in the DNS zone.

Click on “OK”.

Repeat the process for VNET2.

Step 3: Configure DNS Settings for VNET1 and VNET2

Navigate to VNET1 in the Azure Portal.

Select “DNS servers” under the “Settings” section.

Ensure that the DNS server is set to “Default (Azure-provided)”.

Repeat the process for VNET2.

Step 4: Verify Name Resolution

Deploy a virtual machine in VNET1 and another in VNET2.

Connect to the virtual machines using Remote Desktop Protocol (RDP) or Secure Shell (SSH).

Test name resolution by pinging the VM in VNET2 from the VM in VNET1 using its hostname (e.g., ping .contoso.azure).

Explanation

Private DNS Zone: This allows you to manage and resolve domain names in a private network without exposing them to the public internet.

Virtual Network Links: Linking VNET1 and VNET2 to the DNS zone ensures that VMs in these networks can register their DNS records automatically.

Auto-registration: This feature automatically registers the DNS records of VMs in the linked virtual networks, simplifying management.

DNS Settings: Using Azure-provided DNS ensures that the VMs can resolve each other’s names without additional configuration.

By following these steps, you ensure that virtual machines on VNET1 and VNET2 are included automatically in the DNS zone contoso.azure and can resolve each other’s names seamlessly.

To prevent all Azure hosts outside of subnet1-2 from connecting to TCP port 5585 on hosts within subnet1-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 where 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.

Enter 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

Network Security Group (NSG): NSGs are used to filter network traffic to and from Azure resources in an Azure virtual network. They contain security rules that allow or deny inbound and outbound traffic based on source and destination IP addresses, port, and protocol1.

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 configure a policy in Azure API Management that can be used by an Azure Application Gateway to protect against known web attack vectors and only allow requests from IP addresses in Canada, follow these steps:

Step-by-Step Solution

Step 1: Create or Access Your API Management Instance

Navigate to the Azure Portal.

Search for “API Management services” and select your API Management instance.

Step 2: Configure the Policy

In the API Management instance, go to the “APIs” section.

Select the API you want to apply the policy to.

Go to the “Design” tab.

Select “All operations” if you want to apply the policy to all operations, or select a specific operation.

Step 3: Add the Inbound Policy

In the Inbound processing section, click on “+ Add policy”.

Select “IP filter” from the list of policies.

Add the IP address ranges for Canada. You can find the IP ranges for Canada from a reliable source or use a service that provides this information.

Here is an example of the XML configuration for the policy:

Save the policy to apply the changes.

Explanation

IP Filter Policy: This policy allows you to filter incoming requests based on their IP addresses. By specifying the IP ranges for Canada, you ensure that only requests originating from these IPs are allowed.

Inbound Processing: Applying the policy in the inbound section ensures that the requests are filtered before they reach your API.

By following these steps, you can configure a policy in Azure API Management that restricts access to your API to only those requests originating from IP addresses in Canada, thereby enhancing security and compliance

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 settings for your storage account. You can do this in the Azure portal by selecting your storage account and then selecting Networking under Settings1.

On the Networking page, select Firewalls and virtual networks, and then select Selected networks under Allow access from1. 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 optional rule name and description1. This will allow access from any IP address in the 10.1.1.0/24 range.

Select Save to apply your changes1.

To map a custom domain name to your storage account, you need to create a CNAME record with your domain provider that points to your storage account endpoint2. A CNAME record is a type of DNS record that maps a source domain name to a destination domain name.

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

Create a CNAME record with the following information2:

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

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

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

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

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

To ensure that hosts on VNET1 and VNET2 can communicate with minimal latency, you can use Virtual Network Peering. This method connects the two virtual networks directly through the Microsoft backbone network, ensuring low-latency and high-bandwidth communication.

Step-by-Step Solution

Step 1: Set Up Virtual Network Peering

Navigate to the Azure Portal.

Search for “Virtual networks” and select VNET1.

In the left-hand menu, select “Peerings” under the “Settings” section.

Click on “Add” to create a new peering.

Enter the following details:

Name: Enter a name for the peering (e.g., VNET1-to-VNET2).

Peer virtual network: Select VNET2.

Allow virtual network access: Ensure this is enabled.

Allow forwarded traffic: Enable if needed.

Allow gateway transit: Enable if needed.

Click on “Add”.

Step 2: Configure Peering on VNET2

Navigate to VNET2 in the Azure Portal.

In the left-hand menu, select “Peerings” under the “Settings” section.

Click on “Add” to create a new peering.

Enter the following details:

Name: Enter a name for the peering (e.g., VNET2-to-VNET1).

Peer virtual network: Select VNET1.

Allow virtual network access: Ensure this is enabled.

Allow forwarded traffic: Enable if needed.

Allow gateway transit: Enable if needed.

Click on “Add”.

Explanation

Virtual Network Peering: This feature connects two virtual networks in the same or different regions, allowing resources in both networks to communicate with each other as if they were part of the same network. The traffic between peered virtual networks uses the Microsoft backbone infrastructure, ensuring low latency and high bandwidth12.

Allow Virtual Network Access: This setting ensures that the virtual networks can communicate with each other.

Allow Forwarded Traffic: This setting allows traffic forwarded from a network security appliance in the peered virtual network.

Allow Gateway Transit: This setting allows the peered virtual network to use the gateway in the local virtual network.

By following these steps, you can ensure that hosts on VNET1 and VNET2 can communicate with minimal latency, leveraging the high-speed Microsoft backbone network.

Here are the steps and explanations for creating the object that will provide the IP addressing configuration of the on-premises network to the Site-to-Site VPN:

The object that you need to create is called a local network gateway. A local network gateway represents your on-premises network and VPN device in Azure. It contains the public IP address of your VPN device and the address prefixes of your on-premises network that you want to connect to the Azure virtual network1.

To create a local network gateway, you need to go to the Azure portal and select Create a resource. Search for local network gateway, select Local network gateway, then select Create2.

On the Create local network gateway page, enter or select the following information and accept the defaults for the remaining settings:

Name: Type a unique name for your local network gateway.

IP address: Type the public IP address of your VPN device, which is 131.107.50.60 in this case.

Address space: Type the internal address range of your on-premises network, which is 10.10.0.0/16 in this case.

Subscription: Select your subscription name.

Resource group: Select your resource group name.

Location: Select the same region as your virtual network.

Select Review + create and then select Create to create your local network gateway2.

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, including 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 External 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 the 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 SolutionStep 1: Create a Traffic Manager ProfileStep 2: Configure EndpointsStep 3: Adjust Geographic RoutingStep 4: Test the ConfigurationExplanationBy 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 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. Virtual network peering allows you to create low-latency, high-bandwidth connections between virtual networks without using gateways or the internet1.

To create a virtual network peering, you need to go to the Azure portal and select your virtual network. Then select Peerings under Settings and select + Add2.

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

Name: Type a unique name for the peering from the source virtual 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 settings: 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 either 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 peering2.

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 rules that allow or deny inbound or outbound traffic based on source or destination IP address, port, or protocol3.

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 Create4.

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 create your NSG4.

To add rules to your NSG, you need to go to the Network security groups service in the Azure portal and select your NSG. Then select Inbound security rules or Outbound security rules under Settings and select + Add4.

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 Destination 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 to 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.

Name: Type a unique name for your rule.

Select Add to create your rule4.

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 and select your virtual network. Then select Subnets under Settings and select the subnet that you want to associate with your NSG5.

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

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

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: 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 blocking 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.

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.

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.