AZ-104 Implement and Manage Virtual Networking Practice Question
A team is creating a new spoke VNet that will later be peered to an existing hub VNet and connected to on-premises networks. The proposed address space for the spoke is 10.60.1.0/24. The hub already uses 10.60.0.0/16. What should the administrator do before deploying the spoke?
⚠ Common exam trap
The trap here is that candidates mistakenly think a smaller subnet within a larger address space is acceptable for VNet peering, but Azure requires completely non-overlapping address spaces to avoid routing ambiguity.
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, such as 10.61.1.0/24.
VNet address spaces must not overlap when peered or connected via VPN/ExpressRoute. The proposed spoke address 10.60.1.0/24 falls within the hub's 10.60.0.0/16 range, creating an overlap that would prevent successful peering and routing. A non-overlapping address space like 10.61.1.0/24 ensures unique IP ranges, allowing proper route propagation and 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.
- ✗
Use the proposed address space because the spoke subnet is smaller than the hub address space.
Why it's wrong here
This reasoning incorrectly assumes that a smaller subnet can fit inside a larger range without causing a conflict. In Azure, VNet peering requires the entire address spaces of the two VNets to be non-overlapping; it is not about individual subnet sizes. The proposed spoke range 10.61.1.0/24 falls entirely within the hub's 10.60.0.0/16, so the two VNets' address spaces overlap at the VNet level. Even though the subnet is small, the VNet address space is still a subset of the hub's, which makes peering impossible.
When this WOULD be correct
If the hub address space were a different range (e.g., 10.50.0.0/16) and the spoke subnet 10.60.1.0/24 did not overlap, then using the proposed space would be correct.
- ✓
Choose a non-overlapping address space for the spoke, such as 10.61.1.0/24.
Why this is correct
VNet peering requires non-overlapping address spaces. Because 10.60.1.0/24 is contained inside the hub's 10.60.0.0/16 range, the spoke cannot be safely peered as proposed. The correct fix is to pick a different CIDR block that does not overlap with the hub or any other connected network, such as 10.61.1.0/24.
- ✗
Create a private endpoint in the spoke to separate its routing table from the hub.
Why it's wrong here
A private endpoint is used to privately connect to PaaS services (like Azure SQL Database or Storage) by assigning a private IP address from your VNet to the service. Configuring a private endpoint in the spoke has no effect on VNet address space or address conflict detection. It does not alter routing tables, and it cannot remove the overlap between the hub and spoke ranges. The overlap remains, so the peering attempt will still fail because Azure enforces non-overlapping address spaces at the VNet level.
When this WOULD be correct
This option would be correct in a scenario where an administrator needs to securely access an Azure PaaS service (e.g., Azure Storage) from a spoke VNet without traversing the public internet, and the hub VNet already has a private endpoint for that service. The private endpoint in the spoke would provide isolated, private connectivity.
- ✗
Enable gateway transit on the hub peering before creating the spoke.
Why it's wrong here
Gateway transit is a feature that allows a spoke VNet to use a VPN or ExpressRoute gateway in the hub VNet to communicate with on-premises networks. However, it is entirely unrelated to IP address overlap. VNet peering fails at the creation step if the address spaces overlap, regardless of any gateway configuration. Also, gateway transit is configured on the peering link after the peering is established, so it cannot be enabled 'before creating the spoke' and would not repair an invalid address space.
When this WOULD be correct
This option would be correct if the question asked: 'After peering a spoke VNet to a hub VNet that has a VPN gateway, what should the administrator enable to allow the spoke to access on-premises networks through the hub?' In that scenario, enabling gateway transit on the hub peering is the required 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, such as 10.61.1.0/24.Correct answer▾
Why this is correct
VNet peering requires non-overlapping address spaces. Because 10.60.1.0/24 is contained inside the hub's 10.60.0.0/16 range, the spoke cannot be safely peered as proposed. The correct fix is to pick a different CIDR block that does not overlap with the hub or any other connected network, such as 10.61.1.0/24.
✗Use the proposed address space because the spoke subnet is smaller than the hub address space.Wrong answer — click to see why▾
Why this is wrong here
The proposed spoke address space 10.60.1.0/24 overlaps with the hub's 10.60.0.0/16, causing IP conflicts when peered. Azure requires non-overlapping VNet address spaces for peering.
★ When this WOULD be the correct answer
If the hub address space were a different range (e.g., 10.50.0.0/16) and the spoke subnet 10.60.1.0/24 did not overlap, then using the proposed space would be correct.
Why candidates choose this
Candidates may think that a smaller subnet within a larger address space is acceptable, not realizing that VNet address spaces must be completely non-overlapping for peering.
✗Create a private endpoint in the spoke to separate its routing table from the hub.Wrong answer — click to see why▾
Why this is wrong here
Creating a private endpoint does not separate routing tables; it provides private connectivity to Azure PaaS services. The issue here is overlapping IP address spaces between hub and spoke, which would prevent VNet peering, not routing separation.
★ When this WOULD be the correct answer
This option would be correct in a scenario where an administrator needs to securely access an Azure PaaS service (e.g., Azure Storage) from a spoke VNet without traversing the public internet, and the hub VNet already has a private endpoint for that service. The private endpoint in the spoke would provide isolated, private connectivity.
Why candidates choose this
Candidates may confuse private endpoints with network segmentation or think that creating a private endpoint can resolve IP address conflicts by isolating routing, not realizing that private endpoints are for service access, not address space management.
✗Enable gateway transit on the hub peering before creating the spoke.Wrong answer — click to see why▾
Why this is wrong here
Gateway transit is configured on the hub peering to allow the spoke to use the hub's VPN gateway for on-premises connectivity, but it is not a prerequisite for creating the spoke VNet. The spoke must be created first, then peered, and gateway transit can be enabled afterward.
★ When this WOULD be the correct answer
This option would be correct if the question asked: 'After peering a spoke VNet to a hub VNet that has a VPN gateway, what should the administrator enable to allow the spoke to access on-premises networks through the hub?' In that scenario, enabling gateway transit on the hub peering is the required step.
Why candidates choose this
Candidates may confuse the order of operations, thinking that gateway transit must be set up before the spoke is created, or they may overestimate the complexity of hub-spoke connectivity and assume a prerequisite step is needed.
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
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.
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
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.