AZ-104 Implement and Manage Virtual Networking Practice Question
An administrator creates a new spoke virtual network with address space 10.100.1.0/24 and tries to peer it to an existing hub virtual network that already uses 10.100.0.0/16. The peering fails. The business wants private connectivity between the hub and spoke. What action should the administrator take first?
⚠ Common exam trap
Candidates often assume routing or DNS configuration can fix peering failures, overlooking the fundamental requirement that VNet address spaces must not overlap.
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 to a non-overlapping address range before attempting peering again.
VNet peering requires that the address spaces of the peered virtual networks do not overlap. The hub already uses 10.100.0.0/16, which includes the spoke's 10.100.1.0/24 range, causing a conflict. Changing the spoke to a non-overlapping address range, such as 10.200.1.0/24, resolves this and allows the peering to 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.
- ✗
Add a route table to the spoke and point the default route to the hub.
Why it's wrong here
A route table with a default route pointing to the hub cannot establish peering because peering is a separate connection that must be created first. Azure's peering validation explicitly rejects overlapping address spaces before any route table is evaluated, so the spoke's subnets inside 10.100.0.0/16 block the peering entirely. Even if the route table were somehow attached, without peering or a gateway there is no valid next hop to the hub, and routing cannot override the fundamental address space collision. In short, route tables govern traffic after connectivity exists, not the address-space validation that prevents the peering itself.
When this WOULD be correct
In a scenario where a spoke VNet needs to force traffic to an on-premises network through a hub VNet that has a VPN gateway, and the spoke VNet has no overlapping address space, adding a route table with a default route (0.0.0.0/0) to the hub's virtual appliance or gateway would be correct.
- ✓
Change the spoke VNet to a non-overlapping address range before attempting peering again.
Why this is correct
Azure virtual network peering requires non-overlapping address spaces. The spoke currently sits inside the hub's 10.100.0.0/16 range, so the overlap must be removed first. After the address space is changed to a unique range, peering can succeed and private connectivity can be established.
- ✗
Enable gateway transit on the hub and use the remote gateway from the spoke.
Why it's wrong here
Gateway transit requires an existing, successfully established VNet peering to configure, because the 'Use the remote gateway' setting is part of the peering properties. Since the spoke's address range overlaps the hub's 10.100.0.0/16, the peering attempt fails during validation, leaving no peering connection on which to enable transit. Additionally, gateway transit only lets the spoke reach on-premises networks through the hub's VPN/ExpressRoute gateway; it does not remove or reconcile overlapping VNet address spaces. The only viable fix is to change the spoke to a unique, non-overlapping address range and then re-establish peering before enabling any transit feature.
When this WOULD be correct
In a scenario where a hub VNet has a VPN gateway and a spoke VNet needs to connect to on-premises networks through that gateway, enabling gateway transit on the hub and using the remote gateway from the spoke would be the correct first step.
- ✗
Deploy a private DNS zone and link it to both VNets.
Why it's wrong here
A private DNS zone and its VNet links would solve name resolution, but the peering failure is caused by overlapping IP address ranges, not by a lack of DNS records. Even if the spoke's VMs correctly resolved hub hostnames, their resolved IP addresses would still reside within the hub's 10.100.0.0/16 range, creating ambiguous routing that Azure forbids for peered VNets. DNS only maps names to addresses; it does not change or renumber the overlapping address space. Therefore, this option addresses a different layer and cannot fix the underlying peering validation failure.
When this WOULD be correct
In a scenario where two VNets are successfully peered but need name resolution across the peering, deploying a private DNS zone linked to both VNets would enable DNS-based communication.
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 to a non-overlapping address range before attempting peering again.Correct answer▾
Why this is correct
Azure virtual network peering requires non-overlapping address spaces. The spoke currently sits inside the hub's 10.100.0.0/16 range, so the overlap must be removed first. After the address space is changed to a unique range, peering can succeed and private connectivity can be established.
✗Add a route table to the spoke and point the default route to the hub.Wrong answer — click to see why▾
Why this is wrong here
VNet peering does not require route tables; overlapping address spaces cause the peering to fail regardless of routing. Adding a route table cannot resolve the address space conflict.
★ When this WOULD be the correct answer
In a scenario where a spoke VNet needs to force traffic to an on-premises network through a hub VNet that has a VPN gateway, and the spoke VNet has no overlapping address space, adding a route table with a default route (0.0.0.0/0) to the hub's virtual appliance or gateway would be correct.
Why candidates choose this
Candidates may think routing is the issue because peering is established but traffic doesn't flow, but here the peering itself fails due to overlapping IPs, not routing.
✗Enable gateway transit on the hub and use the remote gateway from the spoke.Wrong answer — click to see why▾
Why this is wrong here
Gateway transit is used to allow a spoke VNet to use the hub's VPN/ExpressRoute gateway for connectivity to on-premises, not to resolve overlapping address spaces. The peering failure is due to overlapping IP ranges, which gateway transit cannot fix.
★ When this WOULD be the correct answer
In a scenario where a hub VNet has a VPN gateway and a spoke VNet needs to connect to on-premises networks through that gateway, enabling gateway transit on the hub and using the remote gateway from the spoke would be the correct first step.
Why candidates choose this
Candidates may confuse gateway transit as a solution for general connectivity issues between peered VNets, especially when they think the hub can act as a router for the spoke, not realizing that overlapping addresses must be resolved first.
✗Deploy a private DNS zone and link it to both VNets.Wrong answer — click to see why▾
Why this is wrong here
VNet peering does not require DNS resolution to establish connectivity; the failure is due to overlapping address spaces, not DNS configuration.
★ When this WOULD be the correct answer
In a scenario where two VNets are successfully peered but need name resolution across the peering, deploying a private DNS zone linked to both VNets would enable DNS-based communication.
Why candidates choose this
Candidates may confuse connectivity issues with name resolution, assuming DNS is needed for private connectivity, or they may think DNS zones are required for VNet peering to work.
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?”
Visual reference
Go deeper
Related to this question
Learn chapter
Azure Virtual Machine Deployment
Key term
Virtual network
A virtual network is a software-based network that connects computers, servers, and devices over the internet or within a cloud environment, simulating a physical network without requiring dedicated hardware.
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
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.