AZ-104 Implement and Manage Virtual Networking Practice Question
A company is building a hub-and-spoke Azure network. The hub VNet already uses 10.50.0.0/16. A new spoke VNet will later be peered to the hub and connected to on-premises through VPN. What is the most important planning step before creating the peering?
⚠ Common exam trap
Candidates often think reusing the same address space simplifies routing (Option A), but Azure explicitly forbids overlapping address spaces for VNet peering, making non-overlapping address planning the critical first step.
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
✓
Choose a non-overlapping address space for the spoke and reserve room for future subnets.
Azure VNet peering requires non-overlapping address spaces to establish connectivity. If the spoke uses the same address space as the hub (10.50.0.0/16), routing conflicts will occur, and the peering will fail or cause unpredictable traffic behavior. Additionally, reserving room for future subnets ensures the spoke can scale without needing to re-architect the network.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Reuse 10.50.0.0/16 in the spoke so routing to the hub is simpler.
Why it's wrong here
Reusing 10.50.0.0/16 in the spoke creates an overlapping address space with the hub, and Azure VNet peering cannot be established between VNets with overlapping ranges. Even if the peering were forced, traffic would be ambiguous because the hub would have two separate destinations with the same prefix, so routing could not be deterministic. 'Simpler routing' is not a valid trade-off because peering does not require identical prefixes; in fact, it requires the opposite. The only correct overlap resolution is to renumber the spoke or the hub to a distinct block.
When this WOULD be correct
In a scenario where the spoke VNet is isolated and does not require connectivity to the hub or on-premises, and the goal is to simplify management by using the same address space, reusing the hub's CIDR could be acceptable.
- ✓
Choose a non-overlapping address space for the spoke and reserve room for future subnets.
Why this is correct
A peered VNet must have an address space that does not overlap the hub or any other VNet in the mesh, because Azure uses the destination prefix to select the correct next hop. Using a unique range like 10.x.x.x (or whatever is free) avoids ambiguous routing and lets peering exchange routes automatically. Reserving room for future subnets means you define a larger /16 or /20 now, so when you need to add application tiers or integration subnets later you won't have to rearchitect the address plan. This is the accepted Azure design pattern for hub-spoke scalability.
- ✗
Create a route table first so peering can learn the spoke routes.
Why it's wrong here
A route table (user-defined route) is used to override Azure's system routes for specific subnets, but it does not enable or control route learning during VNet peering. When you peer two VNets, Azure automatically propagates routes from each VNets' address space to the other via the peering connection; no UDR is required. The fundamental problem in this scenario is overlapping address ranges, which no route table can fix because the hub and spoke would both own the same prefix. You must first design non-overlapping address spaces and then optionally add UDRs for filtering or forcing traffic through a firewall/NVA.
When this WOULD be correct
In a scenario where you need to force-tunnel traffic from the spoke to on-premises via the hub, you would create a route table with a default route (0.0.0.0/0) pointing to the hub's VPN gateway, and associate it with the spoke subnets before or after peering.
- ✗
Enable a service endpoint to allow the spoke to communicate with the hub.
Why it's wrong here
Service endpoints are a feature that provides secure, direct connectivity from a VNet's subnet to specific Azure PaaS services such as Azure Storage, Azure SQL, or Azure Key Vault over the Microsoft backbone. They do not establish or replace VNet-to-VNet peering and have no effect on how the hub and spoke exchange traffic. If you need the spoke to communicate with the hub you must create a peering relationship or use a VPN gateway, not a service endpoint. Additionally, service endpoints do not solve address overlap; their routing is per-service, not per-network, so they are irrelevant to this design decision.
When this WOULD be correct
In a scenario where a spoke VNet needs to securely access an Azure PaaS service (like Azure Storage) without using a public IP, enabling a service endpoint on the spoke subnet would be the correct step.
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.
✓Choose a non-overlapping address space for the spoke and reserve room for future subnets.Correct answer▾
Why this is correct
A peered VNet must have an address space that does not overlap the hub or any other VNet in the mesh, because Azure uses the destination prefix to select the correct next hop. Using a unique range like 10.x.x.x (or whatever is free) avoids ambiguous routing and lets peering exchange routes automatically. Reserving room for future subnets means you define a larger /16 or /20 now, so when you need to add application tiers or integration subnets later you won't have to rearchitect the address plan. This is the accepted Azure design pattern for hub-spoke scalability.
✗Reuse 10.50.0.0/16 in the spoke so routing to the hub is simpler.Wrong answer — click to see why▾
Why this is wrong here
Reusing 10.50.0.0/16 in the spoke would cause an IP address overlap with the hub, preventing successful VNet peering and VPN connectivity to on-premises due to routing conflicts.
★ When this WOULD be the correct answer
In a scenario where the spoke VNet is isolated and does not require connectivity to the hub or on-premises, and the goal is to simplify management by using the same address space, reusing the hub's CIDR could be acceptable.
Why candidates choose this
Candidates may think reusing the same address space simplifies routing and configuration, overlooking the fundamental requirement for non-overlapping IP ranges in peered VNets.
✗Create a route table first so peering can learn the spoke routes.Wrong answer — click to see why▾
Why this is wrong here
Route tables are not required for peering to learn spoke routes; Azure VNet peering automatically exchanges routes between peered VNets. Creating a route table first is unnecessary and does not affect peering route learning.
★ When this WOULD be the correct answer
In a scenario where you need to force-tunnel traffic from the spoke to on-premises via the hub, you would create a route table with a default route (0.0.0.0/0) pointing to the hub's VPN gateway, and associate it with the spoke subnets before or after peering.
Why candidates choose this
Candidates may think that explicit route tables are needed to control traffic flow in peered networks, confusing the automatic route exchange of peering with the manual route configuration required for forced tunneling or custom routing.
✗Enable a service endpoint to allow the spoke to communicate with the hub.Wrong answer — click to see why▾
Why this is wrong here
Service endpoints allow private access to Azure services (e.g., storage, SQL) from a VNet, but they do not enable or affect VNet peering communication. Peering relies on direct network connectivity, not service endpoints.
★ When this WOULD be the correct answer
In a scenario where a spoke VNet needs to securely access an Azure PaaS service (like Azure Storage) without using a public IP, enabling a service endpoint on the spoke subnet would be the correct step.
Why candidates choose this
Candidates may confuse service endpoints with VNet peering, thinking both are methods to connect networks, or they may believe service endpoints are required for cross-VNet communication.
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
Managed Identities for Azure Resources
Key term
VNet
A virtual private network inside a cloud provider that lets you securely connect and isolate your cloud 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.
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.