VNet Peering Overlapping Address Spaces: How to Fix
Exhibit
HubVNet address space: 10.40.0.0/16 SpokeVNet address space: 10.40.1.0/24 Peering status: Failed Error: Virtual network address space overlaps with another peered network
Based on the exhibit, the administrator cannot create VNet peering between the hub and spoke networks. What should be changed?
Quick Answer
The answer is to change the spoke VNet address space so it does not overlap the hub. This is correct because VNet peering requires that the address spaces of peered virtual networks be unique and non-overlapping; overlapping address spaces create routing conflicts where Azure cannot differentiate between resources in the hub and spoke that share the same IP range, breaking connectivity. On the AZ-104 exam, this scenario tests your understanding of VNet peering prerequisites and is a common trap where candidates mistakenly try to adjust routes or subnets instead of fixing the root cause—overlapping CIDR blocks. A reliable memory tip is "Peering needs separation: no overlap, no conflict."
⚠ Common exam trap
Many candidates confuse VNet peering prerequisites with routing or security features, mistakenly thinking route tables or service endpoints are required, when the core requirement is non-overlapping address spaces.
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
✓
Change the spoke VNet address space so it does not overlap the hub.
VNet peering requires that the address spaces of the peered VNets do not overlap. Overlapping address spaces cause routing conflicts because Azure cannot distinguish between resources in the hub and spoke when IP addresses are identical or within the same CIDR range. Changing the spoke VNet address space to a non-overlapping range resolves this issue and allows peering to be established.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Change the hub VNet to use a smaller subnet mask.
Why it's wrong here
Peering problems caused by overlapping ranges are not fixed by simply resizing the hub network. The overlap must be removed between the two VNet address spaces first.
When this WOULD be correct
In a scenario where VNet peering is failing due to subnet exhaustion or routing issues, and the hub VNet has too many subnets causing routing table limits, using a smaller subnet mask (larger subnet) could reduce the number of routes and resolve the issue.
- ✓
Change the spoke VNet address space so it does not overlap the hub.
Why this is correct
This is the correct fix because Azure VNet peering requires non-overlapping IP ranges. The exhibit shows the spoke range sits inside the hub range, which causes the peering attempt to fail. Readdressing the spoke to a unique CIDR block resolves the conflict and allows the peering to be created.
- ✗
Add a route table to the spoke VNet before creating peering.
Why it's wrong here
Route tables control traffic flow after connectivity exists, but they do not solve CIDR overlap during peering creation. The error in the exhibit is about address space conflict, not routing.
When this WOULD be correct
In a scenario where traffic between peered VNets must be routed through a network virtual appliance (NVA), you would add a route table to the spoke VNet with a route pointing to the NVA as the next hop for traffic destined to the hub or on-premises.
- ✗
Enable a service endpoint on both VNets.
Why it's wrong here
Service endpoints extend access to supported Azure services, but they do not affect VNet-to-VNet address space validation. They cannot make overlapping peering ranges acceptable.
When this WOULD be correct
In a scenario where an administrator needs to secure access from a VNet to an Azure service (e.g., Azure Storage) and restrict traffic to that service from only specific subnets, enabling a service endpoint on the VNet and the service resource would be the correct action.
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.
✓Change the spoke VNet address space so it does not overlap the hub.Correct answer▾
Why this is correct
This is the correct fix because Azure VNet peering requires non-overlapping IP ranges. The exhibit shows the spoke range sits inside the hub range, which causes the peering attempt to fail. Readdressing the spoke to a unique CIDR block resolves the conflict and allows the peering to be created.
✗Change the hub VNet to use a smaller subnet mask.Wrong answer — click to see why▾
Why this is wrong here
VNet peering fails due to overlapping address spaces, not subnet mask size. Changing the subnet mask does not resolve address space overlap.
★ When this WOULD be the correct answer
In a scenario where VNet peering is failing due to subnet exhaustion or routing issues, and the hub VNet has too many subnets causing routing table limits, using a smaller subnet mask (larger subnet) could reduce the number of routes and resolve the issue.
Why candidates choose this
Candidates may confuse subnet mask adjustments with address space conflicts, thinking that a smaller subnet mask reduces the address range and thus avoids overlap.
✗Add a route table to the spoke VNet before creating peering.Wrong answer — click to see why▾
Why this is wrong here
VNet peering does not require route tables; overlapping address spaces are the issue here, not routing.
★ When this WOULD be the correct answer
In a scenario where traffic between peered VNets must be routed through a network virtual appliance (NVA), you would add a route table to the spoke VNet with a route pointing to the NVA as the next hop for traffic destined to the hub or on-premises.
Why candidates choose this
Candidates may confuse VNet peering with routing requirements, thinking that a route table is necessary to enable connectivity between VNets.
✗Enable a service endpoint on both VNets.Wrong answer — click to see why▾
Why this is wrong here
Enabling a service endpoint does not resolve VNet peering failures caused by overlapping address spaces; service endpoints are used for secure access to Azure services, not for VNet connectivity.
★ When this WOULD be the correct answer
In a scenario where an administrator needs to secure access from a VNet to an Azure service (e.g., Azure Storage) and restrict traffic to that service from only specific subnets, enabling a service endpoint on the VNet and the service resource would be the correct action.
Why candidates choose this
Candidates may mistakenly think that service endpoints are required for VNet peering or that they help establish connectivity between VNets, confusing them with VNet peering prerequisites.
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?”
Visual reference
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
Courseiva writes every AZ-104 question from scratch — 1,049 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
2 more ways 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. Based on the exhibit, an administrator is trying to peer two VNets so workloads can communicate privately. The peering creation fails. What should the administrator do first?
medium- A.Create a user-defined route in VNet-Prod to force traffic through a firewall.
- ✓ B.Readdress one of the VNets so the address spaces no longer overlap.
- C.Enable gateway transit on both VNets and retry the peering.
- D.Add an NSG rule that allows traffic from the other VNet.
Why B: VNet peering requires that the address spaces of the two virtual networks do not overlap. Overlapping address spaces cause routing conflicts and prevent the peering from being established. The administrator must readdress one of the VNets so their IP ranges are unique before retrying the peering.
Variation 2. Based on the exhibit, what should the administrator do so the hub and spoke can be peered successfully?
easy- A.Keep the current ranges and enable gateway transit on the peering.
- ✓ B.Change the spoke VNet to a non-overlapping address space.
- C.Add another subnet inside the spoke VNet and reuse the current address space.
- D.Create a network security group on the spoke subnet before peering.
Why B: VNet peering requires that the address spaces of the peered VNets do not overlap. Overlapping IP ranges cause routing conflicts and prevent successful peering. Changing the spoke VNet to a non-overlapping address space resolves this issue and allows the peering to be established.
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.