AZ-700 Practice Questions

Azure Application Gateway's rewrite feature allows for the modification of HTTP(S) request and response headers. To modify server variables in the response header of the backend application (App1), you must configure a rewrite set. This rewrite set contains one or more rewrite rules with conditions and actions. The action would be to set, add, or delete a specific response header. This rewrite set is then associated with a routing rule to be applied to the traffic flowing through the Application Gateway to the client.

A. HTTP settings define backend properties like port, protocol, and session affinity, but they do not modify headers.

C. Rules associate listeners with backend pools and HTTP settings. While a rewrite set is applied to a rule, "rewrites" is the specific feature configured for this task.

D. Listeners are the entry point for traffic, checking for incoming requests on a specific port and protocol, but they do not perform header modifications.

1. Microsoft Learn. "Rewrite HTTP headers and URL with Azure Application Gateway." Under the "What you can rewrite" section

it explicitly states: "You can use rewrite rules in Application Gateway to add

remove

or update HTTP(S) request and response headers..."

2. Microsoft Learn. "Common rewrite scenarios in Azure Application Gateway." The document provides a specific scenario titled "Modify a response header

" which details the steps to create a rewrite rule and action to modify a response header

such as the Strict-Transport-Security header.

3. Microsoft Learn. "Application Gateway components." This document defines the purpose of each component. The "Routing rules" section explains that a rule binds a listener to a backend pool and can have a rewrite set associated with it. The "HTTP settings" section describes its role in determining protocol

port

and other settings for backend communication.

The security status of an Azure Virtual WAN hub is designated as "Secured" only when a security provider is deployed within it. This is achieved by converting the hub into a "Secured Virtual Hub" using Azure Firewall Manager to deploy either Azure Firewall or a supported third-party security provider. Azure NAT Gateway is a service that provides Source Network Address Translation (SNAT) for outbound internet connectivity from a virtual network. It does not provide the traffic inspection and filtering capabilities required to change the hub's security status.

A. Yes: This is incorrect. Implementing Azure NAT Gateway provides outbound connectivity but does not fulfill the requirement of deploying a security provider like Azure Firewall, which is necessary to mark the hub as "Secured".

1. Microsoft Learn

Azure Virtual WAN documentation

"What is a secured virtual hub?": This document explicitly states

"A secured virtual hub is an Azure Virtual WAN hub with security and routing policies configured by Azure Firewall Manager." It further clarifies that this involves deploying Azure Firewall or a third-party security provider.

Source: https://learn.microsoft.com/en-us/azure/virtual-wan/secured-virtual-hub

Section: "What is a secured virtual hub?".

2. Microsoft Learn

Azure Virtual WAN documentation

"How to configure Azure Firewall in a Virtual WAN hub": This guide details the process of securing a hub. The overview states

"This article shows you how to secure your virtual hub using Azure Firewall Manager." This confirms that Azure Firewall is the mechanism for securing the hub.

Source: https://learn.microsoft.com/en-us/azure/virtual-wan/howto-secure-virtual-hub

Section: "Overview".

3. Microsoft Learn

Azure NAT Gateway documentation

"What is Azure NAT Gateway?": This document defines the service's purpose: "Azure NAT Gateway is a fully managed and highly resilient Network Address Translation (NAT) service... to allow all instances in a private subnet to connect outbound to the internet while remaining fully private." This confirms its role is for outbound connectivity

not hub security.

Source: https://learn.microsoft.com/en-us/azure/nat-gateway/nat-overview

Section: "What is Azure NAT Gateway?".

The core issue is the SKU of the internal load balancer, LB1. Azure's Basic SKU internal load balancer does not support receiving traffic from a peered virtual network. To enable clients in a peered VNet (Vnet2) to access the frontend IP of an internal load balancer (LB1 in Vnet1), the load balancer must be upgraded to the Standard SKU. The Standard SKU is designed for production workloads and includes support for advanced networking features like VNet peering, ensuring high availability and scalability across virtual networks.

A. Change the Floating IP configurations of LB1.

Floating IP (Direct Server Return) is a feature for specific scenarios like Network Virtual Appliance high availability and does not enable cross-VNet connectivity for a Basic SKU load balancer.

B. From the Peerings settings of Vnet2, set Traffic forwarded from remote virtual network to Allow.

This setting is used to allow traffic that is forwarded by a Network Virtual Appliance (NVA) from the peered VNet. This scenario involves direct communication, not traffic forwarded by an NVA.

D. From the Peerings settings of Vnet1, set Traffic forwarded from remote virtual network to Allow.

Similar to the previous option, this setting relates to traffic forwarded by an NVA. It does not apply to direct client-to-load-balancer communication across a VNet peering.

---

1. Microsoft Learn | Azure Load Balancer SKUs: In the feature comparison table

it is explicitly stated that a Basic SKU internal load balancer is limited to a "Single Virtual Network

" whereas a Standard SKU internal load balancer is "Open by default" and can be secured with Network Security Groups

allowing access from peered VNets.

Source: Microsoft Corporation. (2023). Azure Load Balancer SKUs. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/azure/load-balancer/skus#skus (Section: SKU comparison).

2. Microsoft Learn | Use an internal load balancer with Azure Virtual Network peering: This document directly addresses the scenario. It states

"To load balance traffic from a peered virtual network

you must configure your internal load balancer with a Standard SKU. A Basic SKU internal load balancer isn't supported via virtual network peering."

Source: Microsoft Corporation. (2023). Use an internal load balancer with Azure Virtual Network peering. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-internal-vnet-peering (Section: Prerequisites and Introduction).

3. Microsoft Learn | Virtual network peering: This document explains the "Allow forwarded traffic" setting. It clarifies that this option is for scenarios involving Network Virtual Appliances (NVAs) to forward traffic

which is not the configuration described in the question.

Source: Microsoft Corporation. (2023). Virtual network peering. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview#gateways-and-on-premises-connectivity (Paragraph discussing the "Allow forwarded traffic" setting).

Azure Application Gateway must reside in its own, dedicated subnet that contains no other resource types and is not the special GatewaySubnet that is reserved for VPN/ER gateways.

In VNet1 only Subnet2 satisfies these two technical rules: it is large enough (/28 or larger, giving ≥16 addresses) and, per the scenario, is empty of other resources.

Subnet1 is ruled out because it already hosts workloads, and GatewaySubnet is invalid by definition. Therefore, AppGW1 can be deployed only to Subnet2.

A. GatewaySubnet cannot contain anything except VPN/ExpressRoute gateway resources.

C. Subnet1 already contains resources; Application Gateway requires an empty, dedicated subnet.

D. GatewaySubnet is invalid for Application Gateway deployments.

E. Subnet1 and GatewaySubnet both violate Application Gateway subnet rules, leaving only Subnet2.

1. Microsoft Learn – “Application Gateway infrastructure configuration requirements”

section “Virtual network and subnet” (https://learn.microsoft.com/azure/application-gateway/overview#virtual-network).

2. Microsoft Learn – “Tutorial: Create an application gateway” > Prerequisites

bullet “Create a subnet named appgwsubnet of size /27 or larger” (https://learn.microsoft.com/azure/application-gateway/quick-create-portal).

3. Microsoft Learn – “About VPN gateway configuration settings” – note that GatewaySubnet is reserved for VPN/ExpressRoute gateway resources only (https://learn.microsoft.com/azure/vpn-gateway/vpn-gateway-about-vpn-gateway-settings#gateway-subnet).

In a hub-and-spoke topology where spoke VNets (Vnet2, Vnet3) need to use a central gateway in the hub VNet (Vnet1), the most scalable and dynamic method to propagate a default route (0.0.0.0/0) is via BGP. The hub's VPN or ExpressRoute gateway advertises the default route to its BGP peers. When the VNet peering from the spokes to the hub is configured with the "Use the remote virtual network's gateway" option, the spokes automatically learn this advertised route. This directs traffic from the spokes through the hub gateway without requiring manual User-Defined Routes (UDRs) on every spoke subnet.

A. Route filters are used with ExpressRoute Microsoft peering to selectively allow specific Azure service prefixes; they do not configure default routes within a VNet.

C. A user-defined route on the hub's GatewaySubnet controls traffic originating from the gateway, not traffic coming to the gateway from peered spoke VNets.

D. Spoke VNets in a hub-spoke model with gateway transit do not have their own GatewaySubnet. UDRs would be applied to workload subnets, not a gateway subnet.

1. Microsoft Documentation | About BGP with Azure VPN Gateway: Under the section "Frequently asked questions (FAQ)"

the question "Can I advertise default route (0.0.0.0/0) to my virtual networks?" is answered with "Yes. You can advertise 0.0.0.0/0 to your on-premises networks via BGP." This route is then learned by peered VNets using gateway transit.

2. Microsoft Documentation | Hub-and-spoke network topology in Azure: In the "Gateway transit" section

it states

"Gateway transit allows spoke virtual networks to share the hub gateway... Routes to the on-premises network are propagated to the routing tables of the subnets in the spoke virtual network." BGP is the protocol that facilitates this dynamic route propagation.

3. Microsoft Documentation | Virtual network peering: In the "Gateways and on-premises connectivity" section

it explains that when "Use remote gateways" is enabled on a peering

"Routes that the gateway propagates are propagated to the routing tables of the subnets in the peered virtual network." This automatic propagation is the result of the BGP route exchange.

To route a specific percentage of traffic from a single geographic location (Tokyo) to a new endpoint, you must combine two different Traffic Manager routing methods. A single profile cannot simultaneously perform both geographic-based and percentage-based routing.

The solution is to use nested profiles. A parent profile configured with Geographic routing will direct all traffic originating from Japan to a child profile. This child profile will then use Weighted routing to distribute that traffic between the original Tokyo endpoint (weight 90) and the new test endpoint (weight 10). This configuration requires two profiles (parent and child) and four total endpoints (London, New York, the original Tokyo, and the new test endpoint).

A. A single profile cannot use both Geographic and Weighted routing methods, which is required to meet the scenario's conditions.

C. Only two profiles are needed: one parent for geographic routing and one child for weighted distribution. A third profile is unnecessary.

D. The scenario adds one new endpoint to the existing three, resulting in a total of four endpoints, not five.

1. Microsoft Learn. (2023). Traffic Manager routing methods. In the "Geographic traffic routing" section

it states

"It is common to nest profiles. For example

a profile may be configured with the Geographic routing method to route users in a particular region to a second (nested) profile that has been configured with the Weighted routing method..." This directly validates the use of two profiles to combine these routing methods.

2. Microsoft Learn. (2023). Nested Traffic Manager profiles. This document explains the concept and provides an example: "By combining Traffic Manager profiles

you can create sophisticated and flexible traffic-routing configurations... For example

you can combine a 'Geographic' profile with a 'Weighted' profile to direct traffic to a set of endpoints based on both geography and weight." This confirms the required architecture.

The virtual networks are located in two different Azure geopolitical regions: North America (East US, West US) and Europe (North Europe, West Europe). An ExpressRoute Standard circuit only provides access to Azure regions within the same geopolitical region as the peering location (in this case, North America). To connect the New York office to all virtual networks, including those in the Europe geopolitical region, global connectivity is required. The ExpressRoute Premium add-on provides this global connectivity. Therefore, a single ExpressRoute Premium circuit is the most cost-effective solution that meets all requirements.

A. one ExpressRoute Standard circuit: A Standard circuit would not provide connectivity to the virtual networks in the Europe geopolitical region from a North American peering location.

C. two ExpressRoute Premium circuits: This is not a cost-minimized solution, as a single Premium circuit is sufficient to provide the required global connectivity.

D. four ExpressRoute Standard circuits: This solution is unnecessarily complex, significantly more expensive, and does not meet the requirement for global connectivity from a single office.

1. Microsoft Learn

"ExpressRoute circuits and peering": Under the "ExpressRoute SKUs" section

it states

"ExpressRoute Standard SKU gives you connectivity to all Azure regions in a geopolitical region... ExpressRoute Premium SKU provides connectivity to all Azure regions globally." This directly contrasts the capabilities of the two SKUs.

2. Microsoft Learn

"ExpressRoute FAQ": In the "What is ExpressRoute Premium?" section

it clarifies

"A VNet created in one geopolitical region can be accessed through an ExpressRoute circuit in another geopolitical region. For example

you can create a virtual network in West Europe and link it to an ExpressRoute circuit created in Silicon Valley." This confirms Premium is needed for the scenario.

3. Microsoft Learn

"ExpressRoute locations and connectivity providers": The table under "Locations by geopolitical region" confirms that "North America" and "Europe" are distinct geopolitical regions

necessitating the Premium SKU for cross-region connectivity as described in the question.

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

A public load balancer is the appropriate Azure service for this scenario. It is designed to distribute incoming traffic from the internet to a pool of backend virtual machines. By configuring a public IP address on the frontend of the load balancer, all backend VMs can be reached via that single IP. The load balancer then uses rules to forward the traffic to the healthy VMs in the backend pool, providing both internet accessibility and high availability for the applications. This directly meets the requirement of making applications on multiple VMs accessible from the internet using a shared, single public IP address.

A. a NAT gateway: This service is used to provide outbound-only internet connectivity for virtual machines, not for handling inbound connections from the internet.

B. an internal load balancer: This distributes traffic only within a virtual network using a private IP address and is not accessible from the public internet.

D. Azure Application Gateway: This is a Layer 7 load balancer specifically for web traffic (HTTP/S). A public load balancer is a more general-purpose Layer 4 solution suitable for any application protocol.

1. Microsoft Learn. (2023). What is Azure Load Balancer?. Microsoft Docs.

Section: "Public load balancer"

Quote: "A public load balancer maps the public IP address and port of incoming traffic to the private IP address and port of the VM

and vice versa. By applying load-balancing rules

you can distribute specific types of traffic across multiple VMs or services."

2. Microsoft Learn. (2023). What is Azure NAT Gateway?. Microsoft Docs.

Section: "Overview"

Quote: "Azure NAT Gateway is a fully managed and highly resilient Network Address Translation (NAT) service. You can use Azure NAT Gateway to let all instances in a private subnet connect outbound to the internet while remaining fully private."

3. Microsoft Learn. (2023). Load Balancer types. Microsoft Docs.

Section: "Internal (or private) load balancer"

Quote: "An internal (or private) load balancer is used to distribute traffic to virtual machines and cloud services that reside inside a private network."

4. Microsoft Learn. (2023). What is Azure Application Gateway?. Microsoft Docs.

Section: "Overview"

Quote: "Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your web applications... Application Gateway is a layer 7 load balancer."

Traffic Analytics processes and aggregates NSG flow logs. An aggregated flow is defined by a common source IP, destination IP, destination port, protocol, and the NSG rule that processed the traffic.

1. RDP from VM1 to VM2: This is outbound traffic from VM1. The NSG1 outbound rule with priority 65500, DenyAllOutBound, will block this traffic. Both RDP attempts share the same source IP (VM1), destination IP (VM2), destination port (3389), protocol (TCP), and are processed by the same deny rule. Traffic Analytics aggregates these two denied sessions into a single flow entry.

2. SSH from VM2 to VM1: This is inbound traffic to VM1. The NSG1 inbound rule with priority 200, Allow-SSH-Inbound, will permit this traffic. All three SSH sessions share the same source IP (VM2), destination IP (VM1), destination port (22), protocol (TCP), and are processed by the same allow rule. Traffic Analytics aggregates these three allowed sessions into a second, distinct flow entry.

Therefore, a total of two aggregated flow entries are identified.

A. 1: This is incorrect because there are two distinct traffic flows (RDP and SSH) with different sources, destinations, ports, and processing rules, which are aggregated separately.

C. 5: This is incorrect as it counts each individual session. Traffic Analytics aggregates sessions with common properties, it does not log each session as a unique entry.

D. 10: This is incorrect. This number does not correspond to any logical aggregation of the five initiated sessions based on how Traffic Analytics functions.

1. Microsoft Learn

Traffic analytics schema and data aggregation. Under the "Data aggregation logic" section

it states: "Flows that have the same source IP

destination IP

destination port

protocol (TCP or UDP)

and NSG rule are aggregated into a single flow by Traffic Analytics." This directly supports the aggregation of the two RDP sessions into one entry and the three SSH sessions into another.

2. Microsoft Learn

How network security groups filter network traffic. The section "How filtering rules are evaluated" explains that rules are processed by priority. This confirms that the outbound RDP traffic is denied by the priority 65500 rule

and the inbound SSH traffic is allowed by the priority 200 rule.

3. Microsoft Learn

Introduction to flow logging for network security groups. This document confirms that NSG flow logs record both allowed and denied inbound and outbound IP traffic

which are then used as the data source for Traffic Analytics.