AZ-800 Azure Virtual Network Peering 3 — Questions and Answers
Question 1: A spoke VNet is peered to a hub VNet with 'Use remote gateways' enabled. The hub VNet has an Azure VPN Gateway. What effect does deleting the hub's VPN Gateway have on the spoke peering?
- The peering remains connected but the spoke loses on-premises connectivity
- The peering connection is automatically deleted and must be re-created
- The spoke VNet's peering enters a 'Disconnected' state and 'Use remote gateways' must be disabled before re-enabling it (Correct answer)
- No effect — spoke VMs automatically reroute via the Azure backbone
Correct answer: The spoke VNet's peering enters a 'Disconnected' state and 'Use remote gateways' must be disabled before re-enabling it
When the remote gateway is deleted, the peering with 'Use remote gateways' enters a 'Disconnected' state; you must disable and re-enable the option once a new gateway is provisioned.
Question 2: In a hub-spoke topology using VNet peering, how can spoke-to-spoke communication be achieved without direct peering between every spoke?
- Enable transitive routing in the hub VNet's routing table
- Deploy an NVA or Azure Firewall in the hub and use UDRs to force spoke traffic through it (Correct answer)
- Enable 'Allow forwarded traffic' on all peering links automatically enables spoke-to-spoke routing
- Use Azure Virtual WAN instead, as VNet peering cannot support hub-spoke topologies
Correct answer: Deploy an NVA or Azure Firewall in the hub and use UDRs to force spoke traffic through it
Because peering is non-transitive, deploying an NVA or Azure Firewall in the hub with UDRs on spoke subnets forces spoke-to-spoke traffic through the hub device, enabling communication.
Question 3: Which type of VNet peering connects VNets in different Azure regions?
- Regional VNet peering
- Global VNet peering (Correct answer)
- Cross-region ExpressRoute peering
- Inter-region gateway peering
Correct answer: Global VNet peering
Global VNet peering connects VNets that reside in different Azure regions, while regional VNet peering connects VNets within the same region.
Question 4: A company is migrating an on-premises workload to Azure. They have an existing VPN Gateway in VNet-Hub. A new spoke VNet needs on-premises connectivity via the hub's gateway. Which TWO peering settings must be configured correctly? (Choose the combination)
- Hub peering: 'Allow gateway transit' ON; Spoke peering: 'Use remote gateways' ON (Correct answer)
- Hub peering: 'Use remote gateways' ON; Spoke peering: 'Allow gateway transit' ON
- Hub peering: 'Allow forwarded traffic' ON; Spoke peering: 'Allow forwarded traffic' ON
- Hub peering: 'Allow virtual network access' OFF; Spoke peering: 'Allow gateway transit' ON
Correct answer: Hub peering: 'Allow gateway transit' ON; Spoke peering: 'Use remote gateways' ON
The hub peering link needs 'Allow gateway transit' enabled to share its gateway, and the spoke peering link needs 'Use remote gateways' enabled to route through it.
Question 5: What happens to existing VNet peering connections when you resize (change the address space of) one of the peered VNets?
- Peering connections are automatically updated with the new address space (Correct answer)
- All peering connections to that VNet are automatically dropped and must be re-created
- The address space change is blocked until all peerings are deleted
- Peering connections enter 'Updating' state for up to 60 seconds then reconnect
Correct answer: Peering connections are automatically updated with the new address space
Azure automatically updates all peering connections when a VNet's address space is modified, so no manual re-creation of peering links is required.
Question 6: A network engineer notices that a VM in a peered VNet cannot access Azure PaaS services via a private endpoint deployed in the hub VNet. What is the most likely cause?
- Private endpoints cannot be accessed from peered VNets under any configuration
- The private endpoint's NSG is blocking peered VNet traffic by default
- 'Allow forwarded traffic' is not enabled on the peering link and Private DNS zones are not linked to the spoke VNet (Correct answer)
- Global peering does not support private endpoint DNS resolution
Correct answer: 'Allow forwarded traffic' is not enabled on the peering link and Private DNS zones are not linked to the spoke VNet
Accessing a private endpoint from a peered VNet requires 'Allow forwarded traffic' on the peering and the Private DNS zone linked to the spoke VNet for correct name resolution.
Question 7: Which billing model applies to VNet peering traffic between VNets in different Azure regions?
- No charge — all VNet peering traffic is free regardless of region
- Ingress is free; egress is charged at the global peering rate per GB
- Both ingress and egress are charged at the global peering rate per GB (Correct answer)
- Traffic is charged at standard internet egress rates since it crosses regions
Correct answer: Both ingress and egress are charged at the global peering rate per GB
Global VNet peering charges both inbound and outbound data transfer at the global peering rate per GB, unlike regional peering which only charges egress.
AZ-800 Azure Virtual Network Peering 3
A spoke VNet is peered to a hub VNet with 'Use remote gateways' enabled.
The hub VNet has an Azure VPN Gateway.
What effect does deleting the hub's VPN Gateway have on the spoke peering?