VNet Peering with Overlapping Address Spaces
Two virtual networks are in different subscriptions. VNet-A uses 10.20.0.0/16 and VNet-B uses 10.20.128.0/17. A design review also states that traffic between two spoke VNets should flow through a hub VNet instead of directly between spokes. Which two statements are correct? Select two.
Quick Answer
The correct answer is that VNet peering with overlapping address spaces is not allowed in Azure, and to route traffic between spoke VNets through a hub, you must implement an explicit design like gateway transit or custom routing. This is because Azure requires the address spaces of peered VNets to be unique and non-overlapping; in this case, VNet-A’s 10.20.0.0/16 fully contains VNet-B’s 10.20.128.0/17, making the peering request invalid until one range is changed. On the AZ-104 exam, this scenario tests your understanding of both VNet peering constraints and hub-spoke topology requirements—a common trap is assuming that simply peering all VNets to the hub will automatically route spoke-to-spoke traffic through it, but without gateway transit or user-defined routes, traffic will attempt direct peering or fail. Remember the memory tip: “No overlap, no direct spoke-to-spoke—route through the hub with transit or UDRs.”
⚠ Common exam trap
Test-takers frequently assume VNet peering is transitive (like in some other cloud providers) or that a VPN gateway automatically routes spoke-to-spoke traffic, but Azure requires explicit routing configuration for transitive traffic through a hub.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The two VNets cannot be peered until one address space is changed because the ranges overlap.
VNet peering in Azure requires that the address spaces of the peered VNets do not overlap. VNet-A uses 10.20.0.0/16 and VNet-B uses 10.20.128.0/17, which are overlapping ranges (10.20.128.0/17 is a subset of 10.20.0.0/16). Azure will reject the peering request until one of the address spaces is changed to eliminate the overlap.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The two VNets cannot be peered until one address space is changed because the ranges overlap.
Why this is correct
VNet peering in Azure mandates that connected virtual networks must have unique, non-overlapping IP address spaces. In this scenario, VNet-A (10.20.0.0/16) encompasses the entire address range of VNet-B (10.20.128.0/17). This direct overlap violates the fundamental peering requirement. Consequently, peering cannot be established between VNet-A and VNet-B until one of their address spaces is reconfigured to ensure complete separation.
- ✗
VNet peering is transitive, so spoke-to-spoke traffic will automatically use the hub peering.
Why it's wrong here
Peering is nontransitive, so one peering does not automatically connect other peerings together.
When this WOULD be correct
In a scenario where the hub VNet is configured as a network virtual appliance (NVA) with IP forwarding enabled, and user-defined routes (UDRs) are applied to the spoke subnets to force traffic through the NVA, then spoke-to-spoke traffic can flow through the hub.
- ✓
To reach another spoke through the hub, you need an explicit design such as gateway transit or routing controls.
Why this is correct
A hub-and-spoke architecture needs deliberate routing or gateway design to carry traffic between spokes.
- ✗
Overlapping CIDR blocks are allowed if the VNets are placed in separate resource groups.
Why it's wrong here
Resource group boundaries do not change the overlap restriction for virtual network address spaces.
When this WOULD be correct
If the question asked about using Azure Firewall or Network Virtual Appliances to filter traffic between VNets with overlapping IPs, then placing them in separate resource groups might be acceptable as they are not peered directly.
- ✗
If the hub has a VPN gateway, spoke traffic to other spokes is routed automatically without additional configuration.
Why it's wrong here
A gateway alone does not make peering transitive or create spoke-to-spoke reachability by default.
When this WOULD be correct
If the question described a hub VNet with a VPN gateway configured for BGP and the spokes were connected via gateway transit (enabled on the peering), then traffic between spokes could be routed automatically through the hub without additional UDRs.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The AZ-104 exam frequently reuses these exact scenarios with slightly different constraints.
✓The two VNets cannot be peered until one address space is changed because the ranges overlap.Correct answer▾
Why this is correct
VNet peering in Azure mandates that connected virtual networks must have unique, non-overlapping IP address spaces. In this scenario, VNet-A (10.20.0.0/16) encompasses the entire address range of VNet-B (10.20.128.0/17). This direct overlap violates the fundamental peering requirement. Consequently, peering cannot be established between VNet-A and VNet-B until one of their address spaces is reconfigured to ensure complete separation.
✗VNet peering is transitive, so spoke-to-spoke traffic will automatically use the hub peering.Wrong answer — click to see why▾
Why this is wrong here
VNet peering is non-transitive; a peered connection between VNet-A and the hub, and between VNet-B and the hub, does not automatically enable direct traffic between VNet-A and VNet-B through the hub.
★ When this WOULD be the correct answer
In a scenario where the hub VNet is configured as a network virtual appliance (NVA) with IP forwarding enabled, and user-defined routes (UDRs) are applied to the spoke subnets to force traffic through the NVA, then spoke-to-spoke traffic can flow through the hub.
Why candidates choose this
Candidates often confuse the transitive nature of on-premises routing with Azure VNet peering, which is non-transitive by default, leading them to assume that hub-and-spoke peering automatically enables spoke-to-spoke communication.
✗Overlapping CIDR blocks are allowed if the VNets are placed in separate resource groups.Wrong answer — click to see why▾
Why this is wrong here
Overlapping CIDR blocks are not allowed for VNet peering even if VNets are in separate resource groups; peering requires non-overlapping address spaces.
★ When this WOULD be the correct answer
If the question asked about using Azure Firewall or Network Virtual Appliances to filter traffic between VNets with overlapping IPs, then placing them in separate resource groups might be acceptable as they are not peered directly.
Why candidates choose this
Candidates may think resource group isolation allows overlapping IPs, but Azure enforces address space uniqueness for peering regardless of resource group or subscription.
✗If the hub has a VPN gateway, spoke traffic to other spokes is routed automatically without additional configuration.Wrong answer — click to see why▾
Why this is wrong here
In Azure, VNet peering is non-transitive; traffic from one spoke to another must be explicitly routed through a hub, typically using a network virtual appliance or gateway transit. A VPN gateway in the hub does not automatically route spoke-to-spoke traffic without additional configuration like user-defined routes.
★ When this WOULD be the correct answer
If the question described a hub VNet with a VPN gateway configured for BGP and the spokes were connected via gateway transit (enabled on the peering), then traffic between spokes could be routed automatically through the hub without additional UDRs.
Why candidates choose this
Candidates may assume that a VPN gateway in the hub acts as a central router that automatically forwards traffic between connected spokes, similar to a traditional hub-and-spoke topology in on-premises networks.
Analysis generated from the official AZ-104blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
Learn chapter
Managed Identities for Azure Resources
Key term
VNet
A virtual private network inside a cloud provider that lets you securely connect and isolate your cloud resources.
Key term
VNet peering
VNet peering is a networking connection that links two virtual networks so they can communicate with each other as if they were a single network.
About these practice questions
This AZ-104 question is part of Courseiva's 1,049-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on AZ-104
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A new spoke virtual network will peer with an existing hub that uses 10.10.0.0/16 and an on-premises network that uses 10.20.0.0/16. Which two address spaces could you assign to the new spoke without overlapping those ranges? Select two.
easy- ✓ A.10.11.0.0/16
- B.10.10.128.0/17
- ✓ C.192.168.50.0/24
- D.10.20.1.0/24
- E.10.10.1.0/24
Why A: Options A (10.11.0.0/16) and C (192.168.50.0/24) are both correct because they do not overlap with the hub's 10.10.0.0/16 or the on-premises 10.20.0.0/16. The other options are subsets of those ranges and would cause conflicts in Azure virtual network peering.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-104 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-104 exam.