This AZ-104 practice question tests your understanding of implement and manage virtual networking. The scenario asks you to isolate a root cause — eliminate options that address a different problem before choosing. After answering, compare your reasoning against the explanation and wrong-answer breakdown below. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.
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?
Clue words in this question
Noticing these words before you look at the options changes how you read each choice.
Clue: "first"
Why it matters: Order matters here. You are being tested on which action comes before the others — not which action is generally useful.
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.
A
Create a user-defined route in VNet-Prod to force traffic through a firewall.
Why wrong: A route table does not resolve overlapping IP ranges between virtual networks. The peering operation fails before routing is even relevant.
B
Readdress one of the VNets so the address spaces no longer overlap.
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.
C
Enable gateway transit on both VNets and retry the peering.
Why wrong: Gateway transit helps with on-premises connectivity through a gateway, but it does not solve overlapping CIDR ranges. The peering still cannot be created while address spaces conflict.
D
Add an NSG rule that allows traffic from the other VNet.
Why wrong: NSG rules control filtering after connectivity exists. They cannot overcome a hard peering requirement such as overlapping address spaces, so the peering failure remains.
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.
Key principle: Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
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 route table does not resolve overlapping IP ranges between virtual networks. The peering operation fails before routing is even relevant.
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.
Clue confirmation
The clue word "first" in the question point toward this answer.
Related concept
Read the scenario before looking for a memorised answer.
✗
Enable gateway transit on both VNets and retry the peering.
Why it's wrong here
Gateway transit helps with on-premises connectivity through a gateway, but it does not solve overlapping CIDR ranges. The peering still cannot be created while address spaces conflict.
When this WOULD be correct
If an administrator needs to allow a spoke VNet to use a VPNgateway 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
NSG rules control filtering after connectivity exists. They cannot overcome a hard peering requirement such as overlapping address spaces, so the peering failure remains.
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?”
Common exam traps
Common exam trap: answer the scenario, not the keyword
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.
Detailed technical explanation
How to think about this question
Azure VNet peering relies on the Azure backbone to route traffic between VNets using the system routes. If address spaces overlap, the Azure platform cannot uniquely determine which VNet a packet belongs to, leading to ambiguous routing and peering failure. This is enforced at the control plane during peering creation, and the error message typically indicates 'Address space overlap' or 'Cannot peer virtual networks with overlapping address spaces'.
KKey Concepts to Remember
Read the scenario before looking for a memorised answer.
Find the constraint that changes the correct option.
Eliminate answers that are true in general but not in this case.
TExam Day Tips
→Watch for words such as best, first, most likely and least administrative effort.
→Review why wrong options are wrong, not only why the correct option is correct.
Key takeaway
Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Real-world example
How this comes up in practice
A healthcare organisation deploys an application with a public-facing web tier and a private database tier. The database subnet has no public IP and only accepts connections from the web tier's security group. Questions like this test whether you can design cloud network isolation using VNets/VPCs, subnets, and security group rules.
Related glossary terms
Concepts from this question explained
These glossary pages explain the core terms tested in this AZ-104 question in full detail.
Implement and Manage Virtual Networking — This question tests Implement and Manage Virtual Networking — Read the scenario before looking for a memorised answer..
What is the correct answer to this question?
The correct answer is: 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.
What should I do if I get this AZ-104 question wrong?
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
Are there clue words in this question I should notice?
Yes — watch for: "first". Order matters here. You are being tested on which action comes before the others — not which action is generally useful.
What is the key concept behind this question?
Read the scenario before looking for a memorised answer.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
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.
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
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.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.