AZ-104 Implement and Manage Virtual Networking Practice Question
Exhibit
Existing address spaces: - Hub virtual network: 10.50.0.0/16 - On-premises network: 10.51.0.0/16 New spoke virtual network requirements: - Must be peered to the hub - May later connect to on-premises through VPN - Must not overlap with any existing network range
Based on the exhibit, which address space can you assign to the new spoke virtual network so it can be peered to the hub and later connected to on-premises without an IP overlap?
⚠ Common exam trap
Test-takers frequently assume any address outside the hub's exact /16 is safe, forgetting to check the on-premises range (10.51.0.0/16), leading them to pick option B, which overlaps with on-premises and would break hybrid connectivity.
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
✓
10.52.0.0/16
(10.52.0.0/16) is correct because it does not overlap with the hub virtual network's address space (10.50.0.0/16) or the on-premises network (10.51.0.0/16). This allows the spoke VNet to be peered to the hub and later connected to on-premises via a gateway in the hub without IP address conflicts, which is a requirement for successful VNet peering and VPN/ExpressRoute connectivity.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
10.50.128.0/17
Why it's wrong here
10.50.128.0/17 lies entirely inside the hub VNet's 10.50.0.0/16 prefix, so it is not an independent range at all. Assigning it to another VNet would cause overlapping routes during peering, and Azure would never accept the new VNet's address space as unique since it is simply a subset of the hub. You could only use this block if you were subdividing the hub itself, not when adding a peer or a hybrid-connected network.
When this WOULD be correct
This option would be correct if the hub's address space were 10.50.0.0/17 (instead of /16), leaving 10.50.128.0/17 as a non-overlapping range for the spoke.
- ✗
10.51.0.0/16
Why it's wrong here
10.51.0.0/16 collides with the on-premises network shown in the exhibit, and that overlap is fatal for hybrid connectivity. VPN or ExpressRoute route-based gateways would be unable to advertise a network that also exists on-premises, preventing any future site-to-site tunnel from being established. Even without an active hybrid link now, assigning this range would make later on-premises connectivity impossible without reconfiguring the VNet.
When this WOULD be correct
If the hub's address space were 10.50.0.0/16 and the on-premises network used 10.52.0.0/16, then 10.51.0.0/16 would be a non-overlapping address space for the spoke.
- ✓
10.52.0.0/16
Why this is correct
10.52.0.0/16 is the only proposed range that is disjoint from both the existing hub VNet (10.50.0.0/16) and the on-premises address space (10.51.0.0/16). Because Azure VNet peering and hybrid VPN/ExpressRoute connections require non-overlapping address spaces, assigning this range to the new spoke VNet is safe and will allow route exchange without ambiguity. It also leaves ample room for subnet segmentation and future growth.
- ✗
10.50.0.0/24
Why it's wrong here
10.50.0.0/24 is a subnet of the hub VNet's /16, and the /24 is completely contained within 10.50.0.0/16. Even though the /24 is smaller, address overlap is not about comparing prefix lengths; any conflicting address range in a peering relationship creates duplicate route prefixes. This block would directly conflict with the hub's routes for 10.50.0.0 through 10.50.0.255, so it cannot be used for a new spoke VNet.
When this WOULD be correct
This option would be correct if the hub's address space were 10.51.0.0/16 and the on-premises network used 10.52.0.0/16, and the question required a small subnet for a spoke with minimal hosts, such as a test environment with fewer than 256 IPs.
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.
✓10.52.0.0/16Correct answer▾
Why this is correct
10.52.0.0/16 is the only proposed range that is disjoint from both the existing hub VNet (10.50.0.0/16) and the on-premises address space (10.51.0.0/16). Because Azure VNet peering and hybrid VPN/ExpressRoute connections require non-overlapping address spaces, assigning this range to the new spoke VNet is safe and will allow route exchange without ambiguity. It also leaves ample room for subnet segmentation and future growth.
✗10.50.128.0/17Wrong answer — click to see why▾
Why this is wrong here
Option A (10.50.128.0/17) overlaps with the hub's address space 10.50.0.0/16, which would prevent successful peering and cause IP conflicts with on-premises connections.
★ When this WOULD be the correct answer
This option would be correct if the hub's address space were 10.50.0.0/17 (instead of /16), leaving 10.50.128.0/17 as a non-overlapping range for the spoke.
Why candidates choose this
Candidates may think a /17 subnet is large enough and assume it's within a different range, but they overlook that it is a subset of the hub's /16, causing overlap.
✗10.51.0.0/16Wrong answer — click to see why▾
Why this is wrong here
Option B (10.51.0.0/16) overlaps with the hub's address space 10.51.0.0/16 shown in the exhibit, preventing successful peering and connection to on-premises without IP overlap.
★ When this WOULD be the correct answer
If the hub's address space were 10.50.0.0/16 and the on-premises network used 10.52.0.0/16, then 10.51.0.0/16 would be a non-overlapping address space for the spoke.
Why candidates choose this
Candidates may assume any /16 subnet not explicitly listed in the hub is safe, overlooking that the hub's address space includes 10.51.0.0/16 as shown in the exhibit.
✗10.50.0.0/24Wrong answer — click to see why▾
Why this is wrong here
Option D (10.50.0.0/24) is a subset of the hub's address space 10.50.0.0/16, which would cause an IP overlap when peering, violating the requirement for no overlap.
★ When this WOULD be the correct answer
This option would be correct if the hub's address space were 10.51.0.0/16 and the on-premises network used 10.52.0.0/16, and the question required a small subnet for a spoke with minimal hosts, such as a test environment with fewer than 256 IPs.
Why candidates choose this
Candidates may see that /24 is a common subnet size and assume it's safe, overlooking that it falls within the hub's larger /16 range, or they may misread the exhibit and think the hub uses a different address space.
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
VPN Gateway and ExpressRoute
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
ExpressRoute
ExpressRoute is a cloud service that creates a private, dedicated network connection between your on-premises infrastructure and Microsoft Azure, bypassing the public internet for faster, more reliable data transfer.
About these practice questions
This AZ-104 question is part of Courseiva's 1,049-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. 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.