Technical Lab: Create and configure virtual network peering
Questions
Question 1 — Multiple Choice
Two Azure virtual networks are configured with the following address spaces:
- VNet-A:
10.1.0.0/16 - VNet-B:
10.1.128.0/17
An administrator attempts to establish peering between them, but the operation fails.
What is the root cause of the failure?
A) The two networks are in different regions, which requires the use of global peering, which requires a Premium SKU.
B) The address spaces of the two networks overlap, which is a fundamental restriction of peering.
C) Peering can only be created between networks that are in the same Azure subscription.
D) The gateway subnet was not configured in either network before initiating peering.
Question 2 — Technical Scenario
An administrator configured peering between VNet-Prod and VNet-Shared, where VNet-Shared contains a VPN gateway connected to the on-premises network. The goal is to allow resources in VNet-Prod to access the on-premises network through this gateway.
The current peering configuration is:
VNet-Prod --> VNet-Shared
Allow forwarded traffic: Enabled
Allow gateway transit: Disabled
Use remote gateways: Disabled
VNet-Shared --> VNet-Prod
Allow forwarded traffic: Enabled
Allow gateway transit: Disabled
Use remote gateways: Disabled
Traffic from VNet-Prod is not reaching the on-premises network. Which change resolves the problem?
A) Enable Allow gateway transit on the VNet-Prod --> VNet-Shared side and Use remote gateways on the VNet-Shared --> VNet-Prod side.
B) Enable Allow gateway transit on the VNet-Shared --> VNet-Prod side and Use remote gateways on the VNet-Prod --> VNet-Shared side.
C) Enable Allow forwarded traffic on both sides, as this is the option that allows routing through the remote gateway.
D) Recreate the peering with both networks in the same subscription, as remote gateway usage is not supported between different subscriptions.
Question 3 — True or False
After creating a peering between VNet-A and VNet-B, if a new address space is added to VNet-A, the existing peering automatically goes to the Disconnected state and must be manually resynchronized for the new address space to be recognized by VNet-B.
Is the statement True or False?
Question 4 — Multiple Choice
A company has three virtual networks: VNet-A, VNet-B, and VNet-C. Peering is configured between VNet-A and VNet-B, and between VNet-B and VNet-C. An engineer assumes that resources in VNet-A can communicate with resources in VNet-C through VNet-B.
Which statement correctly describes Azure's behavior in this scenario?
A) Communication works because Azure automatically routes traffic between transitively peered networks.
B) Communication does not work because peering in Azure is not transitive by default, requiring direct peering between VNet-A and VNet-C or the use of a hub with configured routing.
C) Communication works only if VNet-B has an active VPN gateway with the Allow gateway transit option enabled.
D) Communication does not work because peered networks cannot act as routing hubs, regardless of any additional configuration.
Question 5 — Technical Scenario
An administrator attempts to create a peering between VNet-Alpha (subscription A, tenant X) and VNet-Beta (subscription B, tenant Y). When executing the command below, they receive an authorization error:
az network vnet peering create \
--name Alpha-to-Beta \
--resource-group rg-alpha \
--vnet-name VNet-Alpha \
--remote-vnet /subscriptions/<sub-b>/resourceGroups/rg-beta/virtualNetworks/VNet-Beta \
--allow-vnet-access
The administrator has Network Contributor permission only in subscription A. What is the cause of the error and what should be done to resolve it?
A) Peering between different tenants is not supported by Azure, regardless of configured permissions.
B) The command is incomplete as it's missing the --allow-forwarded-traffic parameter, which is mandatory in cross-tenant peerings.
C) The administrator does not have permission in subscription B to create peering on the VNet-Beta side; it's necessary for a user with adequate permission in subscription B to create the corresponding peering, or for the administrator to receive the necessary role there.
D) Peering between subscriptions from different tenants requires both networks to be in the same Azure region before being established.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
Peering between Azure virtual networks requires that address spaces do not overlap in any way. In the presented scenario, 10.1.0.0/16 completely encompasses the range 10.1.128.0/17, characterizing direct overlap. Azure rejects the peering before any region or subscription validation.
The main misconception represented by the distractors is confusing network topology restrictions (address overlap) with platform restrictions (region, subscription, SKU). The overlap restriction is absolute and cannot be circumvented through configuration. The consequence of ignoring it would be attempting to restructure routing before identifying the real problem, wasting diagnostic time.
Answer Key — Question 2
Answer: B
For a spoke network to use another hub network's gateway, the configuration must be:
- On the side of the network that has the gateway (VNet-Shared --> VNet-Prod): enable Allow gateway transit.
- On the side of the network that wants to use the remote gateway (VNet-Prod --> VNet-Shared): enable Use remote gateways.
Alternative A reverses this logic, which is the most common error in this scenario. The Allow gateway transit option must be on the side that has the gateway, not on the consuming side. Allow forwarded traffic controls traffic originated outside the direct peering, and has no relation to using remote gateways. Regarding alternative D, remote gateway usage is supported between subscriptions and even between different tenants.
Answer Key — Question 3
Answer: True
When a virtual network's address space is modified after peering establishment, Azure does not automatically propagate this change to peers. The peering enters the Disconnected state, and the administrator needs to perform manual resynchronization (the "Sync" option in the portal or via CLI/PowerShell) for the new routing information to be distributed.
This behavior is not intuitive because Azure manages many network aspects automatically, but address space updates in peerings require explicit action. Ignoring this step results in silent connectivity failure for the newly added ranges.
Answer Key — Question 4
Answer: B
Azure virtual network peering is non-transitive by design. The existence of peering between A-B and B-C does not imply connectivity between A and C. Each pair of networks that needs to communicate must have its own direct peering, or transitivity must be explicitly implemented through a hub-and-spoke solution with Azure Virtual WAN, NVA (Network Virtual Appliance), or Azure Route Server with appropriate routing.
Alternative C is a sophisticated distractor because it correctly mixes the concept of gateway transit with the idea of routing, but gateway transit does not resolve peering transitivity; it only allows the use of a remote VPN/ExpressRoute gateway. Alternative D is incorrect because, with the correct architecture, a hub VNet can indeed route traffic between spokes.
Answer Key — Question 5
Answer: C
Peering between virtual networks is a bidirectional operation that requires authorization on both sides. When networks are in different tenants, having permission in a single subscription is not sufficient. The administrator needs at least the Network Contributor role (or equivalent permission with Microsoft.Network/virtualNetworks/peer/action) in subscription B to create peering on the VNet-Beta side.
Cross-tenant peering is supported by Azure, which invalidates alternative A. The --allow-forwarded-traffic parameter is not mandatory, only optional, invalidating alternative B. The region restriction does not apply to cross-tenant peerings, invalidating alternative D. The real cause is purely role-based access control (RBAC) on the remote subscription.