Technical Lab: Implement VNet Peering
Questions
Question 1 — Multiple Choice
A network team configured peering between VNet-A (10.1.0.0/16) and VNet-B (10.2.0.0/16). Subsequently, peering was created between VNet-B and VNet-C (10.3.0.0/16). A developer reports that resources in VNet-A cannot communicate with resources in VNet-C, even though both peerings are active and correctly configured.
What is the technical reason for this behavior?
A) The peering between VNet-A and VNet-B needs to be recreated after adding VNet-C for routes to be automatically propagated.
B) VNet peering in Azure is not transitive, therefore connectivity between VNet-A and VNet-C requires a direct peering between them or the use of an intermediate resource like Azure Virtual WAN or NVA.
C) The problem is with the IP address ranges, as peered VNets cannot belong to address spaces of the same class.
D) The peering between VNet-B and VNet-C needs to have the Allow gateway transit option enabled for VNet-A to see VNet-C.
Question 2 — Technical Scenario
An engineer is configuring peering between two VNets in different regions (global VNet peering). After completing the configuration on both sides, the peering status shows Connected in the portal, but traffic between VMs still does not flow.
When investigating, the engineer verifies the following configuration on one of the VMs:
VM: vm-prod-eastus
NSG associated with NIC: nsg-prod
Active inbound rule:
Priority: 100 | Port: 3389 | Source: 10.1.0.0/16 | Action: Allow
Priority: 200 | Port: * | Source: * | Action: Deny
The source VM is in 10.2.0.0/16 and tries to access port 22 (SSH) on vm-prod-eastus.
What is the most likely cause of the failure?
A) Global VNet peering does not support SSH traffic between different regions due to protocol restrictions.
B) The NSG is blocking SSH traffic originating from 10.2.0.0/16, as no rule allows port 22 for that source before the general denial rule.
C) The priority 100 rule needs to be reconfigured to include the 10.2.0.0/16 range as destination, not as source.
D) Traffic is being blocked because global peering requires Allow forwarded traffic to be enabled before NSGs can process packets between regions.
Question 3 — True or False
When creating a VNet peering, it is sufficient to configure only the source VNet side for bidirectional connectivity to be automatically established by Azure.
True or False?
Question 4 — Technical Scenario
A company has the following topology:
VNet-Hub (10.0.0.0/16) — contains a VPN Gateway
VNet-Spoke (10.1.0.0/16) — connected to Hub via VNet peering
On-premises network: 192.168.0.0/24
The goal is to allow resources in VNet-Spoke to reach the on-premises network through the VPN Gateway installed in VNet-Hub, without installing a gateway in VNet-Spoke.
The engineer configures peering on both Hub and Spoke sides, but resources in VNet-Spoke still cannot reach the on-premises network.
What is the missing configuration that solves the problem?
A) Enable Allow gateway transit on the peering from the VNet-Hub side and Use remote gateways on the peering from the VNet-Spoke side.
B) Enable Allow forwarded traffic on both sides of the peering so that VPN packets are forwarded correctly.
C) Install a second VPN Gateway in VNet-Spoke and configure a VNet-to-VNet connection between Hub and Spoke.
D) Enable Use remote gateways on both sides of the peering, as the option needs to be symmetric to work.
Question 5 — Multiple Choice
Two distinct teams in an organization are each responsible for a VNet in different subscriptions within the same Microsoft Entra ID tenant. They need to establish VNet peering between the two VNets.
Which statement correctly describes the minimum permission requirement for each team to complete the operation?
A) Only the team that initiates the peering needs permission; Azure automatically propagates the configuration to the remote VNet.
B) Both teams need to have, at minimum, the Network Contributor role or a custom role with the Microsoft.Network/virtualNetworks/virtualNetworkPeerings/write action on their respective VNets.
C) One of the teams needs to have the Owner role on the entire subscription of the other team for cross-subscription peering to be authorized.
D) Peering between VNets in different subscriptions is not supported when the subscriptions belong to the same Microsoft Entra ID tenant.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
VNet peering in Azure is non-transitive by design. This means that even if VNet-A peers with VNet-B and VNet-B peers with VNet-C, Azure's data plane does not automatically create a route between VNet-A and VNet-C. Each peering is an isolated layer 3 relationship.
To resolve this scenario, valid alternatives include creating a direct peering between VNet-A and VNet-C, using a Hub-and-Spoke with NVA (Network Virtual Appliance) that forwards traffic, or adopting Azure Virtual WAN, which offers managed transitive routing.
Alternative D represents a very common misconception: Allow gateway transit allows a spoke VNet to use the hub VNet's gateway to reach external networks (like on-premises), but does not resolve transitivity between spoke VNets.
Answer Key — Question 2
Answer: B
The Connected status confirms that the peering control plane is correct. The problem is at the security layer: the NSG associated with the destination VM's NIC has a general denial rule at priority 200 that blocks any traffic not explicitly allowed before it. The only existing allow rule covers port 3389 (RDP) for source 10.1.0.0/16, with no rule allowing port 22 for 10.2.0.0/16.
Global VNet peering does not impose protocol restrictions (alternative A is false). Alternative C confuses the source and destination fields of the NSG rule. Alternative D is incorrect: Allow forwarded traffic is relevant for scenarios where traffic enters a VNet from outside the direct peering, but does not affect NSG processing itself.
Answer Key — Question 3
Answer: False
VNet peering in Azure requires configuration on both sides for the status to reach Connected and traffic to flow. When only one side is configured, the peering status shows Initiated (or Not connected), indicating that the relationship is incomplete.
This behavior is intentional: it ensures that the owner of each VNet explicitly authorizes connectivity, which is especially relevant in cross-subscription or cross-tenant peering scenarios. The absence of configuration on one side is not just a technical limitation, but a deliberate governance control.
Answer Key — Question 4
Answer: A
For a VNet-Spoke to use the gateway of another VNet (the Hub), two complementary and asymmetric configurations are required:
- On the Hub side peering: enable Allow gateway transit, signaling that this gateway can be used by remote VNets.
- On the Spoke side peering: enable Use remote gateways, signaling that this VNet should use the peered VNet's gateway instead of its own gateway.
Alternative B describes Allow forwarded traffic, which solves a different problem: it allows traffic originating outside a VNet to be forwarded through the peering, useful in topologies with NVA. It does not solve the remote gateway usage issue.
Alternative D represents the most common conceptual error: applying Use remote gateways on both sides is invalid and would result in an error, as only the VNet without a gateway can use the remote gateway.
Answer Key — Question 5
Answer: B
VNet peering between subscriptions is fully supported, even when both belong to the same Microsoft Entra ID tenant (alternative D is false). The permission requirement is that each responsible party has write authorization over the peering resource in their own VNet, which is satisfied by the Network Contributor role or a custom role containing the Microsoft.Network/virtualNetworks/virtualNetworkPeerings/write action.
Alternative A is incorrect: Azure does not automatically propagate the configuration to the remote VNet, as it requires explicit consent from both sides.
Alternative C represents an unnecessary permission escalation. Owner access over the entire subscription is not required; the minimum scope is the VNet itself. Granting more permissions than necessary violates the principle of least privilege, a security pillar relevant in any Azure environment.