AZ-104 Implement and Manage Virtual Networking Practice Question
Exhibit
VNet-Prod address space: 10.40.0.0/16 VNet-Shared address space: 10.40.128.0/17 Operation result: Create peering failed Error: Address space overlap detected between the selected virtual networks.
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?
⚠ Common exam trap
The trap here is that candidates often focus on network security or traffic control (NSGs, UDRs, gateway transit) instead of recognizing that VNet peering has a strict prerequisite of non-overlapping address spaces, which is a common misconfiguration in real-world scenarios.
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
✓
Readdress one of the VNets so the address spaces no longer overlap.
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.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Create a user-defined route in VNet-Prod to force traffic through a firewall.
Why it's wrong here
A UDR cannot resolve the underlying address space conflict. Azure VNet peering validates non-overlapping CIDR ranges at creation time; if two VNets share even a single prefix, the peering resource fails to become 'Connected' before any route table is consulted. Even if a UDR were applied, traffic destined to an overlapping prefix would have multiple possible next hops, and Azure would not be able to deterministically route the packet. Thus, the only remedy is to realign one VNet's address space.
When this WOULD be correct
If the VNets were successfully peered but traffic was being blocked or misrouted, and a firewall appliance was required to inspect or filter traffic between them, then creating a UDR to force traffic through a firewall would be correct.
- ✓
Readdress one of the VNets so the address spaces no longer overlap.
Why this is correct
Azure VNet peering requires non-overlapping address spaces. The correct first step is to change one VNet to a unique, non-conflicting prefix before attempting peering again. Once the overlap is removed, the peering can be created and traffic can flow privately between the networks.
- ✗
Enable gateway transit on both VNets and retry the peering.
Why it's wrong here
Gateway transit is a peering feature that permits one VNet to use the other's VPN/ExpressRoute gateway to reach on-premises networks, but it does not alter or validate address spaces. Enabling gateway transit on both VNets still requires the peering to be successfully established first, which will fail due to overlapping CIDR ranges. Gateway transit also introduces transitive routing complexities but cannot bypass the foundational requirement that peered VNets must not share any address prefixes.
When this WOULD be correct
If an administrator needs to allow a spoke VNet to use a VPN gateway in a hub VNet for connectivity to on-premises, enabling gateway transit on the hub and using remote gateways on the spoke is required.
- ✗
Add an NSG rule that allows traffic from the other VNet.
Why it's wrong here
NSGs are stateful packet filters applied at the subnet or NIC boundary and have no influence on the control-plane operation that creates a VNet peering. The peering API checks for address space overlap and will reject the request even if an NSG allow rule is present, because the security rule has no connection to route resolution. In fact, without a functional peering, the NSG would never see traffic from the other VNet, making the rule moot; the blocked condition is a topology error, not a filtering problem.
When this WOULD be correct
An NSG rule allowing traffic from the other VNet would be correct if the peering is already established but traffic is being blocked by default NSG rules. For example, if VNet peering succeeds but VMs cannot communicate, adding an NSG rule to permit traffic between the VNets would resolve the issue.
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.
✓Readdress one of the VNets so the address spaces no longer overlap.Correct answer▾
Why this is correct
Azure VNet peering requires non-overlapping address spaces. The correct first step is to change one VNet to a unique, non-conflicting prefix before attempting peering again. Once the overlap is removed, the peering can be created and traffic can flow privately between the networks.
✗Create a user-defined route in VNet-Prod to force traffic through a firewall.Wrong answer — click to see why▾
Why this is wrong here
The peering fails due to overlapping address spaces, not routing. A UDR is irrelevant until peering is established.
★ When this WOULD be the correct answer
If the VNets were successfully peered but traffic was being blocked or misrouted, and a firewall appliance was required to inspect or filter traffic between them, then creating a UDR to force traffic through a firewall would be correct.
Why candidates choose this
Candidates may think routing issues are the default cause of connectivity failures, and UDRs are a common solution for controlling traffic flow between VNets.
✗Enable gateway transit on both VNets and retry the peering.Wrong answer — click to see why▾
Why this is wrong here
Gateway transit is used for connecting VNets via a VPN gateway, not for VNet peering. The peering fails due to overlapping address spaces, which is unrelated to gateway transit.
★ When this WOULD be the correct answer
If an administrator needs to allow a spoke VNet to use a VPN gateway in a hub VNet for connectivity to on-premises, enabling gateway transit on the hub and using remote gateways on the spoke is required.
Why candidates choose this
Candidates may confuse VNet peering with gateway transit scenarios, thinking that enabling transit is a prerequisite for any peering to work, especially when troubleshooting connectivity issues.
✗Add an NSG rule that allows traffic from the other VNet.Wrong answer — click to see why▾
Why this is wrong here
The peering failure is due to overlapping address spaces, not because traffic is being blocked. NSG rules control traffic flow but do not resolve the fundamental issue of overlapping IP ranges, which prevents peering from being established.
★ When this WOULD be the correct answer
An NSG rule allowing traffic from the other VNet would be correct if the peering is already established but traffic is being blocked by default NSG rules. For example, if VNet peering succeeds but VMs cannot communicate, adding an NSG rule to permit traffic between the VNets would resolve the issue.
Why candidates choose this
Candidates often assume that connectivity issues after peering are due to security rules, so they think adding an NSG rule will fix the problem. They may overlook that overlapping address spaces prevent peering from being created at all.
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
Azure Virtual Machine Deployment
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
One of 1,049 original AZ-104 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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, the administrator cannot create VNet peering between the hub and spoke networks. What should be changed?
easy- A.Change the hub VNet to use a smaller subnet mask.
- ✓ B.Change the spoke VNet address space so it does not overlap the hub.
- C.Add a route table to the spoke VNet before creating peering.
- D.Enable a service endpoint on both VNets.
Why B: 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.
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.