AZ-800 Azure Virtual Network Peering 5 ā Questions and Answers
Question 1: A VNet peering is established between VNet-A (with a VPN Gateway) and VNet-B with 'Use remote gateways' enabled on VNet-B's side. An administrator then tries to add a new VPN Gateway to VNet-B. What happens?
- The new gateway in VNet-B coexists with the remote gateway setting
- The 'Use remote gateways' setting must be disabled on VNet-B's peering before a gateway can be created in VNet-B (Correct answer)
- Azure automatically disables 'Use remote gateways' when a local gateway is provisioned
- VNet-B's peering is automatically upgraded to allow both gateways
Correct answer: The 'Use remote gateways' setting must be disabled on VNet-B's peering before a gateway can be created in VNet-B
A VNet cannot have 'Use remote gateways' enabled on its peering AND have a local VPN Gateway; you must disable 'Use remote gateways' before provisioning a gateway in VNet-B.
Question 2: Which resource type is used to represent a VNet peering connection in Azure Resource Manager (ARM)?
- Microsoft.Network/virtualNetworks/virtualNetworkPeerings (Correct answer)
- Microsoft.Network/peeringConnections
- Microsoft.Network/virtualNetworks/gatewayConnections
- Microsoft.Network/networkInterfaces/peerings
Correct answer: Microsoft.Network/virtualNetworks/virtualNetworkPeerings
VNet peering connections are represented as child resources of type Microsoft.Network/virtualNetworks/virtualNetworkPeerings under the parent virtual network.
Question 3: An enterprise has 50 spoke VNets all peered to a single hub VNet. They are approaching the default peering limit. Which approach can increase the number of supported peerings?
- Deploy multiple hub VNets and distribute spokes across them, or request a limit increase via Azure Support (Correct answer)
- Switch to Azure ExpressRoute connections between each spoke pair
- Enable VNet peering chaining to extend the limit automatically
- Use Azure Virtual WAN hubs in place of standard VNet peering ā no limit applies
Correct answer: Deploy multiple hub VNets and distribute spokes across them, or request a limit increase via Azure Support
You can distribute spoke VNets across multiple hub VNets to stay within limits, or submit an Azure Support request to increase the per-VNet peering limit beyond 500.
Question 4: A packet capture on a VM in a spoke VNet shows traffic to the hub is being sent to the correct IP but responses are not returning. NSGs allow the traffic. What VNet peering misconfiguration could cause this asymmetric routing?
- 'Allow virtual network access' is disabled on the hub-to-spoke peering link (Correct answer)
- 'Allow forwarded traffic' is enabled on the spoke-to-hub link but not the hub-to-spoke link
- The hub VNet's address space was recently changed and peering was not refreshed
- 'Use remote gateways' is enabled on both sides simultaneously
Correct answer: 'Allow virtual network access' is disabled on the hub-to-spoke peering link
If 'Allow virtual network access' is disabled on the hub-to-spoke peering, the hub cannot route return traffic back to the spoke, causing asymmetric routing symptoms.
Question 5: In the context of AZ-800, which statement about global VNet peering and load balancers using the Basic SKU is accurate?
- Basic Load Balancers are fully supported across global VNet peering
- Basic Load Balancers cannot be used to load-balance traffic across globally peered VNets; Standard SKU is required (Correct answer)
- Global peering automatically upgrades Basic Load Balancers to Standard SKU
- Basic Load Balancers work with global peering only if UDRs are configured
Correct answer: Basic Load Balancers cannot be used to load-balance traffic across globally peered VNets; Standard SKU is required
Basic SKU Load Balancers do not support global VNet peering; you must use the Standard SKU Load Balancer for traffic load-balancing scenarios that span globally peered VNets.
Question 6: A company wants to monitor the data transfer volume across a VNet peering connection. Which Azure service provides peering-specific traffic metrics?
- Azure Network Watcher traffic analytics only
- Azure Monitor with VNet peering metrics (Peering in/out bytes) in the virtual network metrics (Correct answer)
- Azure Advisor cost recommendations for peering
- Log Analytics workspace with VNet flow logs aggregated per peering link
Correct answer: Azure Monitor with VNet peering metrics (Peering in/out bytes) in the virtual network metrics
Azure Monitor exposes peering-specific metrics such as 'Peering ingress bytes' and 'Peering egress bytes' under the virtual network resource, allowing traffic volume monitoring per peering link.
Question 7: A network team is designing a topology where multiple VNets must share centralized services (DNS, NVA, monitoring). They want to avoid creating a full mesh of peerings. What is the recommended Azure design pattern?
- Full-mesh VNet peering between all VNets for direct communication
- Hub-and-spoke topology with one hub VNet peered to each spoke, and UDRs for spoke-to-spoke traffic via the hub (Correct answer)
- Chain peering where each VNet peers only to the next in sequence
- Azure VPN Gateway mesh connecting all VNets via site-to-site VPN
Correct answer: Hub-and-spoke topology with one hub VNet peered to each spoke, and UDRs for spoke-to-spoke traffic via the hub
The hub-and-spoke topology uses a central hub VNet peered to each spoke, hosting shared services; UDRs route spoke-to-spoke traffic through hub NVAs, avoiding O(n²) full-mesh peerings.
A VNet peering is established between VNet-A (with a VPN Gateway) and VNet-B with 'Use remote gateways' enabled on VNet-B's side.
An administrator then tries to add a new VPN Gateway to VNet-B.
What happens?