Free AZ-700 Practice Test Questions and Answers (2026)

Connection Monitor, a feature within Azure Network Watcher, is the specific tool designed for this purpose. It provides end-to-end monitoring of network connections between various endpoints, including Azure virtual machines and on-premises machines connected via ExpressRoute. It allows for the creation of tests that periodically check for reachability, which tracks uptime, and measure round-trip time, which tracks latency. The results are stored in a Log Analytics workspace, enabling historical analysis and alerting, perfectly matching the scenario's requirements.

A. Azure Monitor is the overarching monitoring platform in Azure, but Connection Monitor is the specific, purpose-built tool within it for monitoring network connectivity and latency.

B. IP flow verify is a diagnostic tool in Network Watcher used to verify if network traffic is allowed or denied by Network Security Group (NSG) rules, not for monitoring uptime or latency.

D. Azure Internet Analyzer is used to compare the performance of internet-facing services from an end-user perspective, not for monitoring private, hybrid connections like ExpressRoute.

1. Microsoft Documentation | Azure Network Watcher | What is Connection Monitor?: "Connection Monitor provides unified

end-to-end connection monitoring in Azure Network Watcher... You can monitor connectivity between... Azure virtual machines (VMs)... and on-premises machines... It helps you detect connectivity issues and identify the reason for them. Supported capabilities include... Monitoring for changes in reachability and for measuring network latency and packet loss over time."

2. Microsoft Documentation | Azure Network Watcher | Monitor network connectivity by using Connection Monitor: Under the "Create a connection monitor" section

the steps detail how to select source and destination endpoints

which can be Azure VMs and on-premises machines. The "Test configurations" section describes setting up protocols and thresholds for success

which directly relates to uptime and latency checks.

3. Microsoft Documentation | Azure Network Watcher | Introduction to IP flow verify: "IP flow verify checks if a packet is allowed or denied to or from a virtual machine. The information is useful when you're diagnosing if a network security group (NSG) rule is blocking ingress or egress traffic to or from a VM." This confirms its role as a security rule diagnostic tool.

4. Microsoft Documentation | Azure Internet Analyzer | What is Internet Analyzer?: "Internet Analyzer is a client-side measurement service that enables you to test how networking infrastructure changes will impact your customers' performance. Whether you're migrating from on-premises to Azure or evaluating a new Azure service

Internet Analyzer allows you to learn from your users' data..." This highlights its focus on public

internet-based performance testing.

When a NAT gateway is associated with a subnet, it performs SNAT for every VM in that subnet and supersedes any instance-level public IP that the VMs may have. Therefore, to let VM1 and VM2 continue to use their own public IPs for outbound traffic, they must each reside in subnets that are not associated with Gateway1.

Gateway1 itself must be linked to (at least) one other workload subnet to provide NAT for the remaining resources.

Because Vnet1 already contains the mandatory GatewaySubnet that hosts the existing virtual network gateway, the minimum subnet count becomes:

• GatewaySubnet (VPN gateway)

• Subnet-VM1 (no NAT)

• Subnet-VM2 (no NAT)

• NATed-Subnet (associated with Gateway1)

Total = 4 subnets.

A. 2 Cannot separate VM traffic from NAT traffic and still accommodate the required GatewaySubnet.

B. 3 One subnet would still be shared, forcing a VM to lose its instance-level public IP for outbound flows.

D. 5 Works, but exceeds the minimum; the requirement is to find the least number.

1. Microsoft Azure Virtual Network NAT – Limitations: “NAT gateway supersedes any instance-level public IP…” (docs.microsoft.com

Virtual Network NAT overview

section ‘Limitations’

para 3).

2. Microsoft VPN Gateway Documentation – “The virtual network gateway must be deployed in a dedicated subnet named GatewaySubnet.” (docs.microsoft.com

About VPN gateway settings

section ‘GatewaySubnet’).

3. Microsoft Learn Tutorial – Configure NAT gateway: association to individual subnets only; multiple subnets can exist in the same VNet (docs.microsoft.com

Quickstart: Create NAT gateway

step 6).

Traffic Analytics is a cloud-native solution that ingests and analyzes Network Security Group (NSG) flow logs. It provides rich visualizations and insights into traffic patterns, malicious flows, and security threats within your Azure environment. To use Traffic Analytics, you must first enable NSG flow logs for the network security groups associated with the virtual machines you wish to monitor. The flow logs serve as the raw data source that Traffic Analytics processes. Therefore, implementing NSG flow logs is the foundational and mandatory first step.

A. Connection monitor: This feature tests connectivity and measures latency between endpoints. It is not the data source for Traffic Analytics.

B. Packet capture: This is a diagnostic tool for capturing detailed network packet data for a limited time, used for deep-dive troubleshooting, not for continuous, aggregated analysis.

D. IP flow verify: This is a diagnostic tool used to verify if a specific traffic flow is allowed or denied by NSG rules, not a continuous logging mechanism.

1. Microsoft Learn

Azure Network Watcher documentation

"Traffic analytics": Under the "Prerequisites" section

it explicitly states

"To use traffic analytics

you need... A network security group (NSG) enabled for flow logging...". This confirms that NSG flow logs are a direct prerequisite.

Source: Microsoft Corporation. (2023). Traffic analytics. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/azure/network-watcher/traffic-analytics#prerequisites

2. Microsoft Learn

Azure Network Watcher documentation

"Introduction to flow logging for network security groups": This document describes how NSG flow logs work and their purpose. The "Traffic Analytics" section highlights that "Traffic analytics is a native Azure service that uses the NSG flow logs to provide deep visibility of your network traffic."

Source: Microsoft Corporation. (2023). Introduction to flow logging for network security groups. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/azure/network-watcher/network-watcher-nsg-flow-logging-overview#traffic-analytics

3. Microsoft Learn

Azure Network Watcher documentation

"Tutorial: Log network traffic to and from a virtual machine using the Azure portal": This tutorial guides the user through the process. Step 1 is "Enable NSG flow log

" and a later step is "Enable Traffic Analytics

" demonstrating the required sequence.

Source: Microsoft Corporation. (2023). Tutorial: Log network traffic to and from a virtual machine using the Azure portal. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/azure/network-watcher/network-watcher-nsg-flow-logging-portal (See sections "Enable NSG flow log" and "Enable Traffic Analytics").

The diagnostic log indicates that the Web Application Firewall (WAF) blocked the request due to rule 942440, which detected a potential SQL Injection attack. The Matched Data field shows the pattern 1=1 was found within ARGS:text. The term ARGS refers to the request arguments, such as query string parameters or the request body.

The proposed solution is to create an exclusion for request headers. This solution is incorrect because the WAF detected the pattern in the request arguments, not the headers. An exclusion rule must target the specific attribute where the false positive occurs. Therefore, this solution will not prevent the WAF from blocking the request.

A. Yes: This is incorrect because the proposed exclusion targets the wrong request attribute (headers). The block is occurring in the request arguments, so the solution will be ineffective.

1. Microsoft Learn

Azure Web Application Firewall (WAF) exclusion lists on Azure Application Gateway. This document details the request attributes that can be excluded. It explicitly lists "Request arg name" as a match variable

which would be the correct attribute to target in this scenario

not "Request header name".

Reference: In the "Exclusion attributes" section

see the table listing the supported "Match variable" values.

2. Microsoft Learn

Troubleshoot Web Application Firewall (WAF) for Azure Application Gateway. This guide explains how to interpret WAF logs. The details.data field shows what was matched in the request

and the log entry in the question clearly states the match was in ARGS:text

confirming the issue is in the request arguments.

Reference: See the "Understanding WAF logs" section for descriptions of log fields like matchedDatas and detailsdatas.

3. OWASP

Core Rule Set Project. The rule ID 942440 corresponds to the OWASP ModSecurity Core Rule Set (CRS) rule for "SQL Injection Attack: SQL Tautology Detected." This rule specifically inspects request arguments and other locations for common SQL injection patterns like 1=1.

Reference: OWASP CRS documentation for rule 942440 in the REQUEST-942-APPLICATION-ATTACK-SQLI.conf file.

The proposed solution is incorrect because it uses a service tag for Microsoft.Storage. A service tag represents a group of public IP address prefixes for an entire Azure service within a region, not for a specific resource instance. Using this service tag in a Network Security Group (NSG) rule would either allow or deny traffic to all Azure Storage accounts in that region. It cannot differentiate between storage1, storage2, and storage3. Therefore, it is impossible to meet the goal of allowing access to only storage1 while blocking others using this method. The correct approach would involve using a Virtual Network service endpoint for Microsoft.Storage on Subnet1 and then configuring the firewall on storage1 to allow traffic from that specific subnet.

A. Yes: This is incorrect. The solution fails because a service tag is too broad and applies to the entire Azure Storage service, not a single, specific storage account.

1. Microsoft Learn

Azure virtual network service tags. "A service tag represents a group of IP address prefixes from a given Azure service. Microsoft manages the address prefixes encompassed by the service tag and automatically updates the service tag as addresses change." This confirms that a service tag is a collection of prefixes for a service

not a specific instance. See the section "What is a service tag?".

2. Microsoft Learn

Network security groups. "You can use service tags in the source and destination fields of a security rule." This document confirms how service tags are used in NSGs but also implicitly shows that the destination is a service

not a specific resource. See the section "Security rules".

3. Microsoft Learn

Virtual Network service endpoints. "Endpoints allow you to secure your critical Azure service resources to only your virtual networks... You can secure Azure service resources to your virtual network by adding a virtual network rule to the resources. This provides improved security by fully removing public internet access to resources and allowing traffic only from your virtual network." This describes the correct mechanism for achieving the goal stated in the question. See the section "Key benefits".

To enable on-premises DNS servers to resolve hostnames within an Azure private DNS zone, a DNS forwarder or proxy within the Azure VNet is required. Azure Firewall can fulfill this role. The solution involves two steps:

1. Enable the DNS Proxy feature on the Azure Firewall (FW1). This configures the firewall to listen for DNS queries on its private IP address and forward them to the Azure-provided DNS service, which can resolve records in the linked private zone.

2. Configure the on-premises DNS servers with a conditional forwarder for the contoso.com zone. This forwarder must point to the private IP address of the Azure Firewall (FW1), ensuring that queries for contoso.com are sent to the firewall's DNS proxy for resolution.

B. The IP address 168.63.129.16 is a virtual IP for Azure platform resources and is not routable or reachable directly from an on-premises network.

C. Modifying the VNet's DNS settings affects name resolution for VMs inside the VNet, but it does not establish the required forwarding path from on-premises.

E. Configuring a custom DNS server on the firewall would bypass the Azure-provided DNS needed to resolve the private zone, unless that custom server was also configured to forward to Azure.

1. Microsoft Learn. (2023). Azure Firewall DNS settings. "To use DNS proxy for on-premises networks

configure on-premises DNS servers to forward queries to the firewall's private IP address." and "When you enable DNS Proxy... Azure Firewall... process and forward DNS queries from a Virtual Network(s) to your desired DNS server." This document directly supports enabling the proxy (D) and configuring on-premises forwarders to the firewall's IP (A).

Source: https://learn.microsoft.com/en-us/azure/firewall/dns-settings

2. Microsoft Learn. (2023). Azure Private DNS scenarios. Under the section "On-premises workloads using a DNS forwarder

" the document explains the architectural pattern: "To resolve records from a private DNS zone from on-premises

you need to deploy a DNS forwarder in the virtual network... You can then create a conditional forwarder on your on-premises DNS server that points to the forwarder in Azure." Azure Firewall's DNS proxy feature serves as this forwarder.

Source: https://learn.microsoft.com/en-us/azure/dns/private-dns-scenarios

3. Microsoft Learn. (2023). What is IP address 168.63.129.16?. "The IP address 168.63.129.16 is used in all regions and all national clouds. Microsoft owns this special public IP address... The IP address can't be accessed from outside Azure." This confirms that on-premises servers cannot forward queries directly to this address

invalidating option B.

Source: https://learn.microsoft.com/en-us/azure/virtual-network/what-is-ip-address-168-63-129-16

Each of the three requirements must be configured as a separate custom rule because a single rule can only have one action (Log, Block, Allow, or Redirect) and one rule type (MatchRule or RateLimitRule).

1. Log connections from Australia: This requires a MatchRule with a geo-location condition for Australia and the Log action.

2. Deny connections from New Zealand: This requires a separate MatchRule with a geo-location condition for New Zealand and the Block action.

3. Rate limit connections from 131.107.100.0/24: This requires a RateLimitRule, a distinct rule type, with an IP address condition and the Block action.

Since the actions and rule types are different, they cannot be combined, necessitating three distinct custom rules.

B. one custom rule that has three conditions: A single custom rule cannot have different actions (e.g., Log and Block) or be both a MatchRule and a RateLimitRule simultaneously.

C. one custom rule that has one condition: This is insufficient as it cannot address all three distinct requirements with their different actions and conditions.

D. one rule that has two conditions and another rule that has one condition: The requirements for Australia (Log) and New Zealand (Block) cannot be combined into a single rule because they require different actions.

1. Microsoft Learn

"Custom rules for Azure Web Application Firewall with Azure Front Door": This document outlines the components of a custom rule. Under the "Action" section

it specifies that a rule has a single action. It also describes the two "Rule types": MatchRule and RateLimitRule

confirming that rate limiting is a distinct rule type.

Reference: See sections "Custom rule components" and "Rule types".

2. Microsoft Learn

"Azure Web Application Firewall (WAF) with Front Door rate limiting": This document details the configuration of rate-limiting rules. It states

"Rate limiting rule is configured by using a custom rule in a WAF policy." This confirms that the rate-limiting requirement must be implemented as its own custom rule.

Reference: See the "Rate limiting custom rules" section.

3. Microsoft Learn

"Tutorial: Create a Web Application Firewall policy on Azure Front Door using the Azure portal": This tutorial demonstrates the process of creating custom rules. In the "Add custom rules" section

the user interface shows that for each rule

you must select a single "Action" from a dropdown list

reinforcing the one-action-per-rule principle.

Reference: See Step 3 under the "Add custom rules" section.

To configure a Site-to-Site (S2S) VPN with BGP in Azure, two fundamental resources must be configured. The virtual network gateway is the VPN endpoint in Azure. BGP must be enabled on this gateway, and it is configured with an Azure Autonomous System Number (ASN). The local network gateway is an Azure resource that represents the on-premises VPN device and network. This resource holds the public IP of the on-premises device, the on-premises network address prefixes, and, critically for this scenario, the on-premises BGP peer IP address and ASN. Both resources are essential for establishing the connection and enabling dynamic route exchange via BGP.

B. Azure Application Gateway is a Layer 7 web traffic load balancer and is not involved in establishing network-level S2S VPN connections.

C. Azure Firewall is a network security service. While it can be used to inspect traffic, it is not a core component required to configure the BGP VPN connection itself.

E. Azure Front Door is a global application delivery and acceleration service that operates at the application layer, not the network layer required for S2S VPNs.

1. Microsoft Learn

Official Documentation. "About BGP with Azure VPN Gateway". In the "BGP configuration steps" section

the documentation explicitly outlines the two main steps: 1. "Enable BGP on your Azure VPN gateway..." and 2. "Create a Local Network Gateway with BGP parameters to represent your on-premises network." This confirms that both a virtual network gateway and a local network gateway are required.

2. Microsoft Learn

Official Documentation. "Configure BGP for a site-to-site VPN connection using the Azure portal". This tutorial is structured into two main parts for configuration: "Part 1: Configure BGP on the virtual network gateway" and "Part 2: Configure BGP on the local network gateway"

demonstrating that both resources are integral to the solution.

3. Microsoft Learn

Official Documentation. "Azure VPN Gateway FAQ". Under the "BGP" section

the FAQ "Do I need to assign an ASN to my local network gateway?" is answered with "You need to assign an ASN to your local network gateway only if you're using BGP to advertise routes to that on-premises site." This directly links the local network gateway to the BGP configuration.

Creating or deleting a resource lock requires the permission Microsoft.Authorization/locks/, which is included in the Microsoft.Authorization//write action.

Among the built-in roles, Owner and User Access Administrator both contain Microsoft.Authorization//write, but Owner can modify or delete every resource in the scope, exceeding the required privileges.

User Access Administrator does not allow management of the resources themselves; it only lets the principal manage access control (RBAC) and locks. Therefore, assigning User Access Administrator on NW1 (or RG1) lets Admin1 place a lock while adhering to the principle of least privilege.

B. Network Contributor lacks Microsoft.Authorization/ permissions; it cannot create or delete locks.

C. Resource Policy Contributor is limited to policy resources (Microsoft.Authorization/policy); it has no lock permissions.

D. Monitoring Contributor grants rights to monitoring resources (metrics, alerts) only; it has no authorization or lock permissions.

1. Microsoft

“Azure built-in roles – User Access Administrator

” Microsoft Entra and RBAC documentation

section “Actions

” shows Microsoft.Authorization//write (including locks). https://learn.microsoft.com/azure/role-based-access-control/built-in-roles#user-access-administrator

2. Microsoft

“Lock resources to prevent unexpected changes

” Azure Resource Manager docs

section “Required permissions

” para. 2: “You must have Microsoft.Authorization/locks/ permission

such as Owner or User Access Administrator.” https://learn.microsoft.com/azure/azure-resource-manager/management/lock-resources

3. Microsoft

“Azure built-in roles – Network Contributor

” same page

lists NotActions Microsoft.Authorization/

confirming no lock rights.

4. Microsoft

“Azure built-in roles – Resource Policy Contributor” and “Monitoring Contributor

” same page

list only policy- or monitor-related actions

not Microsoft.Authorization/locks/.

An internal Azure Load Balancer is used to distribute traffic to resources inside a virtual network. To function, it requires a frontend IP configuration, which must be a private IP address allocated from the address space of a specific subnet within the virtual network. This private IP address serves as the destination for the traffic that the load balancer distributes. Other resources, like virtual machines or virtual machine scale sets, are then added to the backend pool of the load balancer.

B. storage account: A storage account itself does not reside in a subnet or consume an IP address from it. Connectivity can be enabled via a private endpoint, which is a network interface that gets an IP from the subnet, but the storage account resource is distinct.

C. service endpoints: A service endpoint is a feature enabled on a subnet to provide a direct, secure connection to Azure services over the Azure backbone. It does not consume any private IP addresses from the subnet's address range.

D. service endpoint policies: Service endpoint policies are applied to a subnet to filter egress traffic to specific Azure service instances over a service endpoint. They are a policy construct and do not require an IP address.

1. Microsoft Learn | Azure Load Balancer components: Under the "Frontend IP configuration" section

it states

"The IP address of your Azure Load Balancer. It's the point of contact for clients. ... For an internal load balancer

the frontend is a private IP address." This confirms the internal load balancer's frontend is an IP from the VNet.

2. Microsoft Learn | What is an internal load balancer?: In the "Frontend IP configuration" section

it details

"The private IP address is selected from a subnet of the virtual network where the load balancer is deployed." This explicitly links the required IP address to a subnet.

3. Microsoft Learn | Virtual Network service endpoints: In the "Key benefits" section

it clarifies that service endpoints allow VNet resources to connect to services without needing public IPs and that the connection is direct. It does not mention the consumption of private IPs by the endpoint itself.

4. Microsoft Learn | Use private endpoints for Azure Storage: This document explains

"A private endpoint is a network interface that uses a private IP address from your virtual network." This distinguishes the private endpoint (which gets an IP) from the storage account resource itself.

Enabling BGP on the VNet gateway in Vnet1 is a necessary step for dynamically advertising routes to Point-to-Site (P2S) clients, but it is insufficient on its own to resolve the issue. For the P2S client (Client1) to learn the routes to the peered network (Vnet2) via BGP, the client itself must also be configured for BGP. This involves downloading the updated VPN client configuration package after enabling BGP on the gateway and then configuring the client to establish a BGP session. Since the proposed solution only involves action on the gateway and not the client, the communication path will not be established, and the goal is not met.

A. This is incorrect because enabling BGP solely on the gateway is an incomplete solution. The P2S client must also be updated and configured to use BGP to receive the necessary routes.

1. Microsoft Learn. (2023). Configure BGP for a P2S IKEv2 or OpenVPN connection. This document explicitly states the requirements for using BGP with P2S clients. In the "Workflow" section

it outlines a multi-step process: "1. Enable BGP on your gateway... 2. Download the VPN client configuration files... 3. Configure the P2S client." This confirms that enabling BGP on the gateway is only one of several required steps.

2. Microsoft Learn. (2023). About BGP and Azure VPN Gateway. In the "FAQ" section

under the question "Can I use BGP with P2S VPNs?"

the documentation states

"Yes... You must also configure BGP on your P2S client." This reinforces that client-side configuration is mandatory for the solution to work.

3. Microsoft Learn. (2023). Configure VPN gateway transit for virtual network peering. In the "Point-to-site" section

this document provides the non-BGP alternative

stating

"If you want your point-to-site clients to be able to connect to the spoke VNet

you must download and reinstall the P2S client package." This highlights that route propagation to P2S clients across peered networks requires a specific configuration update on the client side.

The route table RT1 is configured with a rule that forces all outbound traffic (0.0.0.0/0) from Subnet1 through the Azure Firewall FW1. This includes traffic required for Windows Server activation, which must reach the Azure Key Management Service (KMS). The KMS service uses the special public IP address 168.63.129.16. By forcing this traffic to the firewall, the connection to the KMS server fails. To fix this, a more specific User-Defined Route (UDR) must be added to RT1 for the KMS host IP (168.63.129.16/32) with a next hop type of Internet. This route will take precedence over the general 0.0.0.0/0 route, allowing activation traffic to bypass the firewall and follow the correct Azure platform path.

A. Application security groups are used within Network Security Group (NSG) rules to filter traffic, but they do not correct the underlying traffic routing issue.

B. An Azure Standard Load Balancer is used for distributing traffic or providing outbound NAT, neither of which resolves the misrouting of KMS traffic to the firewall.

C. A DNAT rule is used to translate inbound traffic to the firewall's public IP into traffic for a private IP. The activation issue is with outbound traffic from the VMs.

1. Microsoft Learn

"What is IP address 168.63.129.16?": This document explicitly states

"The public IP address 168.63.129.16 is used in all public clouds and all national clouds. This special public IP address is owned by Microsoft and doesn't change... Enables communication with the Windows activation endpoint for Windows virtual machines." This confirms the IP address and its purpose for activation.

2. Microsoft Learn

"Azure Firewall FAQ": In the section on Forced Tunneling

it states

"For Windows Activation to work

you must add a route for the Windows Activation host IP addresses to bypass the firewall." This directly supports the solution of adding a specific route to bypass the firewall for activation.

3. Microsoft Learn

"Virtual network traffic routing": Under the "User-defined" section

this document explains how Azure selects routes. "When multiple routes exist in a route table

Azure selects a route based on the longest prefix match." A route for 168.63.129.16/32 is more specific than 0.0.0.0/0 and will be selected for traffic to the KMS server.

Forced Tunneling: Azure Firewall forced tunneling redirects all internet-bound traffic to an on-premises location for inspection. This feature must be configured when the firewall is initially created. Since Firewall1 is an existing, provisioned firewall, forced tunneling cannot be enabled on it post-deployment.

Azure Firewall Manager: The exhibit provides two clear indicators that Firewall1 is managed by Azure Firewall Manager. First, it explicitly states, "Visit Azure Firewall Manager to configure and manage this firewall." Second, it shows that the firewall is associated with a FirewallPolicy1. Firewalls managed by Azure Firewall Manager use Firewall Policies for centralized rule management, whereas standalone firewalls use Classic Rules.

Microsoft Docs - Azure Firewall forced tunneling: "You can configure forced tunneling during firewall creation to enable it...You can't configure an existing firewall for forced tunneling."

Source: Microsoft Corporation. (2024). Azure Firewall forced tunneling. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/azure/firewall/forced-tunneling.

Microsoft Docs - Azure Firewall Manager overview: "Azure Firewall Policy is a global resource that can be used to centrally manage your firewalls using Azure Firewall Manager."

Source: Microsoft Corporation. (2024). What is Azure Firewall Manager?. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/azure/firewall-manager/overview.

Statement 1 is TRUE (Yes). The VM1 exhibit shows that the virtual machine is located in Subnet1. The Subnet1 exhibit explicitly shows that it is configured to use NATgateway1 as its NAT gateway. Therefore, VM1 will use NATgateway1 for all outbound internet traffic.

Statement 2 is FALSE (No). The NATgateway1 exhibit shows that it is associated with only one subnet. Since we know from the Subnet1 exhibit that Subnet1 is associated with NATgateway1, it follows that Subnet2 is not. A NAT gateway only serves the subnets it is explicitly associated with.

Statement 3 is FALSE (No). The NATgateway1 exhibit indicates it has 0 Public IP addresses but 1 Public IP prefix. A public IP prefix is a contiguous range of public IP addresses. When a NAT gateway uses a public IP prefix, it can use any of the IP addresses within that range for outbound connections. Therefore, it is not guaranteed that all virtual machines will use the same single public IP address.

Microsoft Learn: What is Virtual Network NAT?

Reference: Under the "Outbound connectivity with NAT" section, it states: "When a NAT gateway is configured on a subnet, all outbound connectivity uses the static public IP addresses of the NAT gateway. A virtual machine without a public IP address in a subnet configured with NAT gateway can have outbound connectivity." This supports the answer for Statement 1.

Microsoft Learn: Design a virtual network with a NAT gateway

Reference: In the "Subnets" section, the documentation clarifies: "A NAT gateway can be associated with one or more subnets in a virtual network. When a NAT gateway is associated with a subnet, it provides outbound connectivity for all virtual machines within that subnet." This supports the reasoning for Statement 2, as a subnet must be explicitly associated.

Microsoft Learn: Virtual Network NAT resources

Reference: Under the "Public IP prefixes" section, it says: "A public IP prefix is a contiguous range of standard SKU public IP addresses... Once a prefix is associated with a NAT gateway, all of the IP addresses of the prefix can be used for outbound connections." This confirms that multiple IPs are available from the prefix, supporting the answer for Statement 3.

The connectivity is determined by VNet peering and gateway transit configurations.

1. VM1 Connectivity: VM1 resides in VNET1. VNET1 has a direct Site-to-Site VPN connection to the on-premises datacenter and a direct bi-directional VNet peering with VNET2, allowing communication with VM2. However, VNet peering is not transitive. This means VM1 cannot communicate with VM3 through VNET2. Therefore, VM1 can only reach the on-premises datacenter and VM2.
2. VM2 Connectivity: VM2 resides in VNET2. VNET2 has direct peerings with VNET1 and VNET3, enabling communication with VM1 and VM3. The peering with VNET1 has gateway transit enabled, which allows VNET2 to use VNET1's VPN gateway to connect to the on-premises datacenter. As a result, VM2 has the most extensive connectivity in this setup.

Microsoft Learn, Azure Virtual Network documentation, "Virtual network peering".

This document states, "Resources in either virtual network can communicate with resources in the other virtual network with the same latency and bandwidth as if the resources were in the same virtual network." This supports the direct communication between VM1 and VM2, and between VM2 and VM3.

It also clarifies a key principle for this scenario: "Virtual network peering is non-transitive." This is the reason why VM1 and VM3 cannot communicate with each other.

Microsoft Learn, Azure Virtual Network documentation, "Configure gateway transit for virtual network peering".

Under the "Hub-and-spoke network" section, it explains, "Gateway transit allows spoke virtual networks to use the hub virtual network's VPN gateway to communicate with on-premises networks." This directly validates why VM2 (in a spoke VNet) can communicate with the on-premises datacenter through the gateway in VNET1 (the hub VNet).

To configure a custom domain like app1.contoso.com with Azure Front Door, two specific DNS records are required. First, a CNAME record is created to map the custom domain to the Azure Front Door endpoint hostname (e.g., your-front-door.azurefd.net), directing user traffic accordingly. Second, to enable HTTPS and prove ownership of the domain, Azure requires you to create a TXT record with a specific value.

For securing the custom domain with a third-party SSL certificate (Bring Your Own Certificate model), the certificate must be stored in a secure location accessible by Azure Front Door. The designated and secure service for this is Azure Key Vault. Therefore, the certificate for app1.contoso.com must be imported into the provided Key Vault, Vault1. Front Door then retrieves the certificate from the vault to terminate the SSL/TLS connections from users.

Microsoft Learn: Tutorial - Add a custom domain to your Azure Front Door.

Reference: Under the "Create a CNAME DNS record" section, it states, "Before you can use a custom domain... you must first create a canonical name (CNAME) record with your domain provider to point to your Front Door."

Reference: Under the "Map the custom domain" section, it details the domain validation process: "For a domain that is in use... Azure validates your domain ownership by asking you to add a TXT DNS record."

Microsoft Learn: Tutorial - Configure HTTPS on an Azure Front Door custom domain.

Reference: In the "Prerequisites" and "Enable HTTPS" sections, it clearly states that when using your own certificate, "The certificate must be imported into an Azure Key Vault." It also specifies the necessary permissions for Front Door to access the certificate within the Key Vault.

Azure Virtual WAN hub gateway capacity is configured using scale units. To meet the requirements while minimizing costs, you must select the lowest number of scale units that satisfy the specified throughput.

• S2S VPN Gateway: Each scale unit provides 500 Mbps of aggregate throughput. To support the required 4 Gbps (4000 Mbps), you need 4000 Mbps/500 Mbps per unit=8 scale units.
• ExpressRoute Gateway: Each scale unit provides 2 Gbps of aggregate throughput. To support the required 8 Gbps, you need 8 Gbps/2 Gbps per unit=4 scale units.

This configuration meets the exact performance needs without over-provisioning, thereby minimizing costs.

Microsoft Learn, "About Virtual WAN gateway settings." This document provides the official tables detailing the relationship between scale units and throughput for different gateway types.

Under the section "Gateway scale units," the "VPN scale units" table explicitly states that 1 scale unit equals 500 Mbps.

The "ExpressRoute scale units" table in the same section shows that 1 scale unit equals 2 Gbps.

Microsoft Azure, "Virtual WAN pricing." The official pricing page reinforces these values. In the pricing calculator and details for Virtual WAN, the "VPN Gateway Scale Unit" is defined at 500 Mbps increments, and the "ExpressRoute Gateway Scale Unit" is defined at 2 Gbps increments, directly linking cost to these performance metrics.

The parent Traffic Manager profile must use the Geographic routing method. This method directs traffic based on the geographic origin of the DNS query, fulfilling the requirements to route North Europe traffic to the North Europe region and North America traffic to the East US region.

Each regional endpoint in the parent profile is a nested (child) Traffic Manager profile. These child profiles must use the Weighted routing method. By assigning an equal weight to each App Service instance within a region's child profile, traffic is distributed evenly among them, satisfying the equal assignment requirement. This nested configuration combines geographic steering with even load distribution.

1. Microsoft Azure Documentation

Traffic Manager routing methods. Microsoft Learn. Accessed May 20

2024.

Section: Geographic traffic-routing method: "Use this routing method to direct users to specific endpoints (Azure

External

or Nested) based on the geographic location their DNS query originates from. This method enables you to be in compliance with data sovereignty mandates

localization of content & user experience and measuring traffic from different regions."

Section: Weighted traffic-routing method: "Use this routing method to distribute traffic across a set of endpoints based on their weight. You set the weight

which is an integer from 1 to 1000

for each endpoint in the Traffic Manager profile configuration. ... If you want to use an even distribution

you set the weights for all endpoints to be the same."

2. Microsoft Azure Documentation

Nested Traffic Manager profiles. Microsoft Learn. Accessed May 20

2024.

Section: Example: Using nested profiles to mix routing methods: This document provides a specific example of a parent profile using 'Geographic' routing to direct traffic to child profiles. The child profiles then use 'Weighted' routing to distribute traffic across endpoints within their respective regions

which directly mirrors the solution required by the question.

Statement 1: Yes. An Azure Private Link service exposes a service that is running behind a Standard Load Balancer. Traffic sent to the Private Link service is directed to the frontend IP of the load balancer, which then distributes it to the virtual machines in its backend pool. As shown in the exhibits, privatelinkservice1 is associated with the load balancer lb1, so the resources providing the service must be in backendpool1.

Statement 2: No. The IP address 10.3.0.7 is the Network Address Translation (NAT) IP address within the service provider's virtual network (Subscription1). Users in the consumer's network (Subscription2) will connect to the service by using the private IP address assigned to the private endpoint within their own virtual network (vnet5), not the NAT IP in the provider's network.

Statement 3: Yes. The exhibit showing the private endpoint connections for privatelinkservice1 clearly displays the Connection State as Pending. This state indicates that a consumer in Subscription2 has requested a connection, and it must be explicitly approved by an administrator with permissions on the Private Link service in Subscription1 before the connection becomes active and traffic can flow.

Azure Private Link Service Concepts: According to the official Microsoft documentation, "A Private Link service is mapped to the frontend IP address of a Standard Load Balancer. All the virtual machines in the back-end pool of the Standard Load Balancer serve the traffic of the Private Link service." This validates the first statement. (Source: Microsoft Docs, "What is Azure Private Link service?", Service provider section).

Private Endpoint Connection Workflow: The documentation on managing private endpoint connections states that a connection can be in a "Pending" state, which means "The connection is created manually by the user and is pending approval from the Private Link resource owner." This confirms the third statement, as the owner is in Subscription1. (Source: Microsoft Docs, "Manage a private endpoint connection," Review and approve a private endpoint connection from a service provider section).

Source Network Address Translation (SNAT): For traffic from the private endpoint, the service provider sees the source IP address as a NAT IP allocated from the provider's virtual network. The consumer side uses the private endpoint's IP to connect. This confirms that users in Subscription2 would not use the NAT IP 10.3.0.7. (Source: Microsoft Docs, "Azure Private Link service," Source Network Address Translation (SNAT) section).

To remove the origin port from the HTTP header forwarded to the backend pool, you must rewrite the header that communicates the original host to the backend. The X-Forwarded-Host header serves this purpose by carrying the original Host header value from the client's request.

By setting the value of this header to the Azure Application Gateway server variable host, you are populating it only with the hostname from the incoming request. The host variable inherently excludes the port number, effectively stripping it before the request is sent to the backend. For example, if the incoming request's Host header is www.contoso.com:8080, setting X-Forwarded-Host to host will result in the header having a value of www.contoso.com.

Microsoft Azure Documentation | Rewrite HTTP headers and URL with Application Gateway: This official documentation details the capabilities of Application Gateway rewrite rules. Under the "Rewrite headers" section, it lists the supported headers, including X-Forwarded-Host. The "Server variables" section explains the available variables.

Section: Server variables

Details: The documentation clarifies how server variables can be used to store information about requests and responses. The host variable specifically extracts the hostname from the Host request header, excluding the port.

Microsoft Azure Documentation | How an application gateway works: This document provides a high-level overview of the request flow. It explains that the gateway acts as a reverse proxy, modifying requests before forwarding them to backend servers. This modification capability includes rewriting headers like X-Forwarded-Host to ensure proper routing and application behavior on the backend.

Section: How a request is routed

Details: The document implies the necessity of header manipulation for seamless communication between the client, gateway, and backend, which justifies the use of rewrite rules.