AZ-104 Implement and Manage Virtual Networking Practice Question
Two application teams created separate VNets for independent workloads. VNet-A uses 10.40.0.0/16 and VNet-B uses 10.40.128.0/17. The teams want to peer the VNets so both apps can communicate privately. What should the administrator do first?
⚠ Common exam trap
Watch out — candidates often assume overlapping ranges can be handled with routing or filtering (NSGs, route tables, or gateways), but Azure VNet peering strictly requires non-overlapping address spaces and will reject the peering creation outright.
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
✓
Renumber one VNet so its address space no longer overlaps before creating the peering.
B is correct because Azure VNet peering requires non-overlapping address spaces. VNet-A (10.40.0.0/16) and VNet-B (10.40.128.0/17) overlap, as 10.40.128.0/17 is a subset of 10.40.0.0/16. Before peering can be established, one VNet must be renumbered to eliminate the overlap; otherwise, the peering creation will fail with an error indicating overlapping address spaces.
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 the peering now and add a route table to one VNet later.
Why it's wrong here
You cannot 'create the peering now' with overlapping ranges — the create operation itself will fail with a validation error because Azure detects the address overlap before any route table can be added. Even if a route table (UDR) were applied later, it would not resolve the underlying issue: Azure's infrastructure routing for peering relies on non-conflicting VNet address space announcements, and overlapping prefixes create ambiguous routes. Adding a route table is a control-plane traffic-routing change, not an address-space fix, so it cannot substitute for the required renumbering.
When this WOULD be correct
If the VNets had non-overlapping address spaces but needed to force asymmetric routing or override default peering routes, creating the peering first and adding a route table later would be correct.
- ✓
Renumber one VNet so its address space no longer overlaps before creating the peering.
Why this is correct
Azure VNet peering cannot be established between two virtual networks whose address spaces overlap; the peering request is validated and rejected at creation time. The only way to resolve this is to modify one VNet's address plan by renumbering it to a unique, non-overlapping CIDR range before attempting to peer. This may require reconfiguring or redeploying workloads, but without this change neither peering nor any subsequent traffic flow will be possible.
- ✗
Add an NSG rule that allows traffic between the two address ranges.
Why it's wrong here
Network security group rules operate at layer 4 and merely allow or deny traffic between IP addresses, so they cannot alter the fact that the two VNets assign the same RFC 1918 ranges. With overlapping address spaces, Azure's routing engine has no way to decide which VNet should receive traffic for a duplicated prefix — even if an NSG permits it, the flow's next hop is unresolved. Furthermore, the peering itself would not be created, so an NSG rule would never have a connected path to act upon.
When this WOULD be correct
In a scenario where two VNets have non-overlapping address spaces and you need to control which traffic is allowed between them after peering, adding an NSG rule would be the correct step.
- ✗
Enable gateway transit on both VNets so overlapping ranges can route through a shared gateway.
Why it's wrong here
Gateway transit allows one VNet to route through a gateway in a peered hub VNet, but it still requires the peering between the VNet and the hub to succeed, and that peering's address space must be unique. Overlapping ranges are not made routable by a shared VPN/ExpressRoute gateway; the gateway would still have multiple interfaces with the same subnet, causing the routing table to have identical destinations with conflicting next hops. Enabling gateway transit on both VNets also creates a routing loop because neither side has a unique destination, so this is not a valid workaround.
When this WOULD be correct
In a scenario where two VNets have non-overlapping address spaces but need to connect to an on-premises network through a single VPN gateway, enabling gateway transit on one VNet and using the other as a spoke allows the spoke VNet to use the hub's gateway without deploying its own.
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.
✓Renumber one VNet so its address space no longer overlaps before creating the peering.Correct answer▾
Why this is correct
Azure VNet peering cannot be established between two virtual networks whose address spaces overlap; the peering request is validated and rejected at creation time. The only way to resolve this is to modify one VNet's address plan by renumbering it to a unique, non-overlapping CIDR range before attempting to peer. This may require reconfiguring or redeploying workloads, but without this change neither peering nor any subsequent traffic flow will be possible.
✗Create the peering now and add a route table to one VNet later.Wrong answer — click to see why▾
Why this is wrong here
VNet peering requires non-overlapping address spaces. Creating the peering first with overlapping ranges will fail, and adding a route table later cannot resolve the fundamental address conflict.
★ When this WOULD be the correct answer
If the VNets had non-overlapping address spaces but needed to force asymmetric routing or override default peering routes, creating the peering first and adding a route table later would be correct.
Why candidates choose this
Candidates may think peering can be established first and routing adjusted later, underestimating that Azure blocks peering creation when address spaces overlap.
✗Add an NSG rule that allows traffic between the two address ranges.Wrong answer — click to see why▾
Why this is wrong here
VNet peering requires non-overlapping address spaces; NSG rules cannot resolve the fundamental routing conflict caused by overlapping IP ranges.
★ When this WOULD be the correct answer
In a scenario where two VNets have non-overlapping address spaces and you need to control which traffic is allowed between them after peering, adding an NSG rule would be the correct step.
Why candidates choose this
Candidates may mistakenly think that NSGs can filter traffic between overlapping ranges, not realizing that overlapping IPs prevent routing from working at all.
✗Enable gateway transit on both VNets so overlapping ranges can route through a shared gateway.Wrong answer — click to see why▾
Why this is wrong here
VNet-A (10.40.0.0/16) and VNet-B (10.40.128.0/17) have overlapping address ranges (10.40.128.0/17 is within 10.40.0.0/16). Azure VNet peering requires non-overlapping address spaces; overlapping ranges cannot communicate via peering even with a shared gateway. Gateway transit does not resolve address overlap.
★ When this WOULD be the correct answer
In a scenario where two VNets have non-overlapping address spaces but need to connect to an on-premises network through a single VPN gateway, enabling gateway transit on one VNet and using the other as a spoke allows the spoke VNet to use the hub's gateway without deploying its own.
Why candidates choose this
Candidates may mistakenly think that a shared gateway can route traffic between overlapping VNets, similar to how a VPN gateway can connect overlapping on-premises networks with NAT, but Azure VNet peering does not support overlapping ranges.
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 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.
Key term
VNet
A virtual private network inside a cloud provider that lets you securely connect and isolate your cloud resources.
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
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. Two application teams created separate virtual networks so their workloads can communicate through VNet peering. VNet-A uses 10.20.0.0/16. VNet-B was created with 10.20.128.0/17. The peering request fails during validation. What is the best fix?
easy- A.Add an NSG rule to allow traffic between the two VNets.
- ✓ B.Change one VNet to use a non-overlapping address space.
- C.Create a private endpoint in each VNet.
- D.Attach a route table to both subnets.
Why B: VNet peering requires that the address spaces of the peered virtual networks do not overlap. VNet-A uses 10.20.0.0/16, which includes the entire range from 10.20.0.0 to 10.20.255.255. VNet-B uses 10.20.128.0/17, which is a subset of VNet-A's range (10.20.128.0 to 10.20.255.255). This overlap causes the peering validation to fail because Azure cannot route traffic between overlapping address spaces. Changing one VNet to a non-overlapping address space resolves the conflict.
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.