Technical Lab: Connect a virtual network to an ExpressRoute circuit
Questions
Question 1 — Multiple Choice
A network team needs to connect three distinct virtual networks to the same ExpressRoute circuit. Each virtual network is in a different Azure region. Which Azure resource is required to enable this connectivity across all three virtual networks?
A. An ExpressRoute Gateway in each virtual network, with virtual network peering between them
B. A Virtual Network Gateway of type ExpressRoute in each virtual network, with each gateway connected to the circuit via connection resource
C. A single Virtual Network Gateway of type ExpressRoute in a hub virtual network, with the others connected via VNet peering without gateway transit
D. An ExpressRoute Direct port pair shared between the three virtual networks, eliminating the need for individual gateways
Question 2 — Technical Scenario
An administrator created an ExpressRoute circuit and received confirmation from the provider that the circuit is provisioned. He then created a Virtual Network Gateway of type ExpressRoute and attempted to create the connection resource to link the gateway to the circuit. The operation fails with a validation error. The circuit was created in the same subscription and region as the gateway.
What is the most likely cause of the failure?
A. The gateway was created in a common subnet of the VNet, and not in the GatewaySubnet
B. The circuit still has status "Not Provisioned" on the provider side, meaning the provider provisioning state is not "Provisioned"
C. The chosen gateway SKU is incompatible with the ExpressRoute circuit SKU
D. The connection resource requires that the circuit and gateway be in the same availability zone
Question 3 — True or False
An ExpressRoute circuit with FastPath enabled eliminates the need for a Virtual Network Gateway in the destination virtual network, as traffic is routed directly to VMs without passing through the gateway.
Question 4 — Technical Scenario
A company successfully connected a virtual network to an ExpressRoute circuit. After six months, the team decides to add a second virtual network to the same circuit. The new gateway is created and the connection resource is configured. However, VMs in the second virtual network cannot reach on-premises resources.
Consider the configuration below for the second VNet:
Address space: 10.2.0.0/16
GatewaySubnet: 10.2.255.0/27
Connection State: Succeeded
BGP Status: Connected
Advertised routes: 0 prefixes
What is the most likely cause of the problem?
A. The prefix 10.2.0.0/16 is not being advertised via BGP to the circuit because the VNet's BGP route advertisement was not explicitly enabled
B. The GatewaySubnet 10.2.255.0/27 is too small to support the gateway in high availability mode
C. There is address space overlap between the second VNet and the on-premises network, causing route drops on the provider side
D. The maximum number of connections per ExpressRoute circuit has already been reached with the first VNet
Question 5 — Multiple Choice
When choosing the Virtual Network Gateway SKU for an ExpressRoute connection, what is the most relevant functional difference between the ErGw1AZ, ErGw2AZ, and ErGw3AZ SKUs?
A. Only ErGw3AZ supports connectivity with ExpressRoute circuits; the others are exclusive to VPN Gateway
B. All three SKUs support ExpressRoute, but differ in maximum supported throughput and the number of virtual network connections allowed simultaneously
C. All three SKUs have equivalent throughput, but differ only in the number of availability zones used for redundancy
D. ErGw2AZ and ErGw3AZ support FastPath natively, while ErGw1AZ requires additional peering configuration to enable this feature
Answer Key and Explanations
Answer Key — Question 1
Answer: B
Each virtual network that needs to connect to an ExpressRoute circuit requires its own Virtual Network Gateway of type ExpressRoute. The connection between the gateway and the circuit is established through a connection resource, which references both the gateway and the circuit. This model is independent per virtual network, regardless of how many VNets connect to the same circuit.
Alternative A is incorrect by suggesting that peering between VNets replaces the need for individual gateways in each network. Virtual network peering can be used for gateway transit in some scenarios, but all VNets that need direct connectivity to the circuit still require their own gateway or access via a hub configured explicitly with Use Remote Gateways. Alternative C partially describes this hub-spoke model, but omits that the spoke VNets need to have Allow Gateway Transit and Use Remote Gateways configured correctly, and don't work automatically just with peering. Alternative D confuses ExpressRoute Direct (which deals with dedicated physical ports) with virtual gateway logic.
Answer Key — Question 2
Answer: B
For a connection resource to be created successfully, the ExpressRoute circuit needs to have the provider provisioning state equal to "Provisioned". This state indicates that the connectivity provider has completed provisioning on their side. While this state is "Not Provisioned" or "Provisioning", Azure blocks connection creation because the circuit is not operational.
Alternative A describes a real gateway configuration error, but would result in failure when creating the gateway itself, not the connection resource. Alternative C is a plausible distractor: while gateway and circuit SKUs must be compatible, Azure doesn't block the connection for SKU incompatibility with immediate validation error in this context. Alternative D is incorrect because availability zones refer to gateway resilience, not a co-location requirement with the circuit.
Answer Key — Question 3
Answer: False
FastPath was designed to improve data path performance by allowing inbound traffic to bypass the Virtual Network Gateway and reach VMs directly. However, the gateway is still required: it continues to be necessary for the control plane, i.e., for establishing the BGP session, learning routes, and managing the connection with the circuit. FastPath only optimizes data packet forwarding, it doesn't eliminate the gateway from the architecture. Additionally, FastPath is only available for ErGw3AZ and Ultra Performance SKUs, and requires the connection resource to be explicitly configured to enable it.
Answer Key — Question 4
Answer: C
The "Advertised routes: 0 prefixes" field indicates that the gateway is not advertising any routes to the circuit via BGP, which typically points to address space overlap. When the VNet prefix (10.2.0.0/16) conflicts with a prefix already advertised by the on-premises network or another VNet connected to the same circuit, BGP drops or doesn't advertise this route to avoid loops or routing ambiguity.
Alternative A is an attractive distractor, but Azure automatically advertises VNet prefixes via BGP when the connection is established: there's no manual "enable advertisement" configuration. Alternative B is incorrect because /27 is the minimum recommended size for GatewaySubnet and supports gateways in high availability. Alternative D is incorrect because a Standard ExpressRoute circuit supports up to 10 VNet connections, and the limit wouldn't generate "Advertised routes: 0" as a symptom.
Answer Key — Question 5
Answer: B
The ErGw1AZ, ErGw2AZ, and ErGw3AZ SKUs form a progressive capacity scale for ExpressRoute gateways with availability zone support. The most relevant functional difference between them is the maximum supported throughput (respectively 1 Gbps, 2 Gbps, and 10 Gbps) and the number of virtual network connections supported simultaneously. Choosing an inadequate SKU for expected traffic volume is a sizing error with direct performance impact.
Alternative A is clearly false: all three SKUs support ExpressRoute. Alternative C is incorrect because all three SKUs offer availability zone redundancy by definition (the "AZ" suffix indicates this), but their throughput capacities are distinct. Alternative D is incorrect: FastPath is only available on ErGw3AZ (and Ultra Performance), not on ErGw2AZ, and doesn't require additional peering configuration to be enabled.