AZ-104 Implement and Manage Virtual Networking Practice Question
A company created a new spoke virtual network with the address space 10.40.1.0/24. The existing hub virtual network already uses 10.40.0.0/16. The administrator must peer the two VNets so resources can communicate normally. What must be changed before peering can succeed?
⚠ Common exam trap
A common mix-up: candidates confuse overlapping address spaces with connectivity issues that can be fixed by routing or security rules, but Azure strictly prohibits overlapping address spaces for VNet peering at the control plane level.
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 to a range that does not overlap the hub.
Azure Virtual Network peering requires that the address spaces of the peered VNets do not overlap. The hub VNet uses 10.40.0.0/16, which includes the spoke's 10.40.1.0/24 range. Overlapping address spaces prevent successful peering because Azure cannot route traffic correctly between overlapping IP ranges. Therefore, the spoke VNet address space must be changed to a non-overlapping range before peering can succeed.
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 route table on the spoke subnet before adding the peering.
Why it's wrong here
A user-defined route table can steer outbound traffic from a subnet to a virtual appliance or hub, but it operates only after a VNet peering already exists and only for networks that are routable. Azure validates address space non-overlap at peering time, and a route table cannot alter that underlying address space definition or mask the fact that the spoke's /24 is inside the hub's /16. Even with a route table in place, peering creation still fails because overlapping address spaces are a fundamental design violation, not a routing problem.
When this WOULD be correct
In a scenario where VNet peering is already established but traffic between subnets in different VNets is not flowing correctly due to asymmetric routing, creating a route table with a user-defined route on the spoke subnet can force traffic to go through the hub or a network virtual appliance.
- ✓
Change the spoke VNet address space to a range that does not overlap the hub.
Why this is correct
Azure virtual network peering requires non-overlapping IP address spaces on both sides. Because the spoke is using 10.40.1.0/24, which sits inside the hub's 10.40.0.0/16 range, peering cannot be created successfully. The administrator must renumber the spoke to a unique range before attempting the peering, then update any dependent subnet and DNS settings as needed.
- ✗
Enable gateway transit on the hub peering to permit overlapping spaces.
Why it's wrong here
Enabling gateway transit on a hub peering only allows a spoke to use the hub's VPN/ExpressRoute gateway—it is a connectivity feature that relies on a functioning peering, not a replacement for address-space validation. Azure requires that peered VNets have unique, non-overlapping address ranges; transit settings are irrelevant to that requirement. Because the spoke's 10.40.1.0/24 is a subset of the hub's 10.40.0.0/16, overlapping address spaces make routing ambiguous, and the peering cannot be established even if gateway transit is switched on.
When this WOULD be correct
In a scenario where a spoke VNet needs to access on-premises resources through the hub's VPN gateway, enabling gateway transit on the hub peering and using the spoke's remote gateways setting would be correct, provided address spaces do not overlap.
- ✗
Add an NSG rule that allows traffic between the hub and spoke address spaces.
Why it's wrong here
Network security groups (NSGs) filter traffic at layers 3/4 based on the 5-tuple, but they have no effect on how Azure validates VNet peering prerequisites. During peering creation, Azure inspects the address spaces of both VNets and rejects the request if any CIDR ranges overlap—this check happens before any NSG policy is ever evaluated. Adding an NSG rule that allows traffic still leaves the overlapping 10.40.1.0/24 inside the hub's 10.40.0.0/16, so the peering object is never established.
When this WOULD be correct
An NSG rule allowing traffic between hub and spoke would be correct if the question were about enabling communication after peering is established, but the VNets had overlapping address spaces resolved by using network virtual appliances or NAT.
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 to a range that does not overlap the hub.Correct answer▾
Why this is correct
Azure virtual network peering requires non-overlapping IP address spaces on both sides. Because the spoke is using 10.40.1.0/24, which sits inside the hub's 10.40.0.0/16 range, peering cannot be created successfully. The administrator must renumber the spoke to a unique range before attempting the peering, then update any dependent subnet and DNS settings as needed.
✗Create a route table on the spoke subnet before adding the peering.Wrong answer — click to see why▾
Why this is wrong here
VNet peering does not require route tables; overlapping address spaces prevent peering from being established at all, so a route table cannot resolve the conflict.
★ When this WOULD be the correct answer
In a scenario where VNet peering is already established but traffic between subnets in different VNets is not flowing correctly due to asymmetric routing, creating a route table with a user-defined route on the spoke subnet can force traffic to go through the hub or a network virtual appliance.
Why candidates choose this
Candidates may confuse VNet peering with hub-and-spoke topologies that require route tables for traffic redirection, or they may think that a route table can override the address space overlap restriction.
✗Enable gateway transit on the hub peering to permit overlapping spaces.Wrong answer — click to see why▾
Why this is wrong here
Gateway transit is used to allow a peered VNet to use the hub's VPN/ExpressRoute gateway, not to permit overlapping address spaces. Overlapping address spaces are not allowed in VNet peering regardless of gateway transit settings.
★ When this WOULD be the correct answer
In a scenario where a spoke VNet needs to access on-premises resources through the hub's VPN gateway, enabling gateway transit on the hub peering and using the spoke's remote gateways setting would be correct, provided address spaces do not overlap.
Why candidates choose this
Candidates may confuse gateway transit with a feature that resolves address overlap, or think that enabling transit somehow overrides the non-overlap requirement for peering.
✗Add an NSG rule that allows traffic between the hub and spoke address spaces.Wrong answer — click to see why▾
Why this is wrong here
NSG rules control traffic filtering, not address space overlap. Peering requires non-overlapping address spaces; NSGs cannot resolve the fundamental conflict of overlapping IP ranges.
★ When this WOULD be the correct answer
An NSG rule allowing traffic between hub and spoke would be correct if the question were about enabling communication after peering is established, but the VNets had overlapping address spaces resolved by using network virtual appliances or NAT.
Why candidates choose this
Candidates often confuse NSGs as a solution for connectivity issues, thinking that allowing traffic with an NSG rule can overcome address space overlap, which is a routing problem, not a filtering one.
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
Route
A route is a path that data takes through a network from one device or network to another, determined by routing protocols and configured rules.
Key term
Azure Virtual Network
Azure Virtual Network is a cloud service that lets you create a private, isolated network in the Microsoft Azure cloud, allowing your virtual machines and other resources to communicate securely with each other, the internet, and your on-premises 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 →
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.