AZ-800 Azure Virtual Network Peering 4 — Questions and Answers
Question 1: An administrator needs to peer two VNets in different Azure subscriptions but under the same AAD tenant. What is a prerequisite for completing this peering?
- Both subscriptions must be linked to the same billing account only
- The user must have the Network Contributor role (or equivalent write permission on Microsoft.Network/virtualNetworks/peer) on both VNets (Correct answer)
- Cross-subscription peering requires opening a Microsoft support ticket first
- Both VNets must use the same address space prefix
Correct answer: The user must have the Network Contributor role (or equivalent write permission on Microsoft.Network/virtualNetworks/peer) on both VNets
The initiating user must have Network Contributor or a custom role with Microsoft.Network/virtualNetworks/peer/* permission on both VNets to create a cross-subscription peering.
Question 2: Which Azure CLI command is used to create a VNet peering from VNet-A to VNet-B?
- az network vnet peering create --name peer-A-to-B --vnet-name VNet-A --remote-vnet VNet-B (Correct answer)
- az network vnet connect --source VNet-A --destination VNet-B --name peer-A-to-B
- az network peering add --local-vnet VNet-A --peer-vnet VNet-B
- az vnet peering create --source VNet-A --target VNet-B --bidirectional
Correct answer: az network vnet peering create --name peer-A-to-B --vnet-name VNet-A --remote-vnet VNet-B
The correct command is 'az network vnet peering create' with --vnet-name for the local VNet and --remote-vnet for the peer VNet.
Question 3: A security team requires that all traffic between a spoke VNet and a hub VNet be inspected by Azure Firewall. The VNets are peered. What must be configured to enforce this?
- Enable 'Allow forwarded traffic' and 'Allow gateway transit' on both peering links
- Create UDRs on spoke subnets with next hop set to the Azure Firewall's private IP in the hub (Correct answer)
- Configure a Network Security Group on the peering link itself
- Enable Azure Firewall Premium and associate it with both VNets directly
Correct answer: Create UDRs on spoke subnets with next hop set to the Azure Firewall's private IP in the hub
User Defined Routes (UDRs) with the next hop pointing to Azure Firewall's private IP must be applied to spoke subnets to force all traffic through the firewall for inspection.
Question 4: What is the effect of setting 'Allow virtual network access' to Disabled on a VNet peering link?
- VMs in the peered VNet can still communicate using public IPs but not private IPs
- Traffic between the two VNets is blocked, effectively disabling all communication across the peering (Correct answer)
- Only management traffic (RDP/SSH) is blocked; application traffic continues
- The peering is deleted automatically after 24 hours
Correct answer: Traffic between the two VNets is blocked, effectively disabling all communication across the peering
Setting 'Allow virtual network access' to Disabled tags the peered VNet's address space as outside the virtual network, blocking all traffic across the peering link.
Question 5: A company uses a hub-spoke model with Azure VNet peering. They want on-premises users to resolve DNS names for resources in spoke VNets via a DNS forwarder in the hub. Which peering configuration supports DNS query forwarding from spoke to hub to on-premises?
- Enable 'Use remote gateways' on hub peering and 'Allow gateway transit' on spoke peering
- Enable 'Allow forwarded traffic' on the hub-side peering link and on the spoke-side peering link (Correct answer)
- Enable 'Allow virtual network access' only — DNS forwarding works automatically
- Configure Azure Private DNS Resolver in the hub with no special peering settings required
Correct answer: Enable 'Allow forwarded traffic' on the hub-side peering link and on the spoke-side peering link
Enabling 'Allow forwarded traffic' on both sides of the peering allows DNS query traffic that originates from the spoke (destined beyond the hub) to traverse the peering correctly.
Question 6: Which peering state indicates that a VNet peering was previously connected but the peer VNet or its peering configuration has been deleted?
- Initiated
- Disconnected (Correct answer)
- Updating
- Degraded
Correct answer: Disconnected
'Disconnected' state indicates the remote peering link has been removed or the peer VNet deleted; you must delete and recreate the local peering to resolve it.
Question 7: An organization overlaps address spaces between two VNets (both use 10.1.0.0/16). Can these VNets be peered?
- Yes, with custom route tables to disambiguate subnets
- Yes, but only if one VNet uses IPv4 and the other uses IPv6
- No, VNet peering requires non-overlapping address spaces (Correct answer)
- No, unless they are in different Azure regions using global peering
Correct answer: No, VNet peering requires non-overlapping address spaces
Azure VNet peering requires that the address spaces of the two VNets do not overlap; overlapping CIDRs will cause the peering creation to fail regardless of region.
An administrator needs to peer two VNets in different Azure subscriptions but under the same AAD tenant.
What is a prerequisite for completing this peering?