AZ-104 Implement and Manage Virtual Networking Practice Question
A company has a hub VNet and two peered spoke VNets, AppSpoke and DataSpoke. Both spokes can reach on-premises networks through the hub gateway. The app VM in AppSpoke must connect privately to the data VM in DataSpoke without using the internet or sending traffic on-premises first. What should the administrator do?
⚠ Common exam trap
Test-takers frequently assume gateway transit (Option B) enables direct spoke-to-spoke communication, but it only allows spokes to use the hub’s gateway for on-premises connectivity, not for inter-spoke traffic without going through the hub.
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
✓
Create a direct VNet peering between AppSpoke and DataSpoke.
A direct VNet peering between AppSpoke and DataSpoke establishes a private, low-latency connection between the two VNets without routing traffic through the hub gateway or on-premises networks. This satisfies the requirement for a private connection that does not use the internet or traverse on-premises, as VNet peering uses the Microsoft backbone infrastructure.
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 an NSG rule that allows traffic from AppSpoke to DataSpoke.
Why it's wrong here
An NSG only filters traffic at a subnet or NIC based on allow/deny rules; it has no ability to create a logical network path. For any traffic between AppSpoke and DataSpoke to be evaluated by an NSG, a viable route must already exist, and none does without a peering or a transitive device. Adding an allow rule therefore has no effect because packets never arrive at the NSG in the first place.
When this WOULD be correct
An NSG rule would be correct if the question asked how to block or allow specific traffic between subnets within the same VNet, or between VNets already connected via peering, where routing is already in place.
- ✗
Enable gateway transit on both spoke peerings.
Why it's wrong here
Gateway transit lets a spoke use the hub's VPN or ExpressRoute gateway to reach external on-premises networks, but it does not turn the hub into a router that connects two spokes. Even when both spoke peerings have gateway transit enabled and the hub has 'allow gateway transit', the hub gateway still does not forward traffic between the peered spokes because Azure's peering model is inherently non-transitive. Spoke-to-spoke communication requires either a direct VNet peering or a hub NVA configured with forwarding.
When this WOULD be correct
In a scenario where a spoke VNet needs to reach an on-premises network through the hub VPN gateway, enabling gateway transit on the spoke-to-hub peering is correct. For example, if AppSpoke must connect to an on-premises database via the hub gateway, enabling gateway transit on AppSpoke's peering with the hub is required.
- ✓
Create a direct VNet peering between AppSpoke and DataSpoke.
Why this is correct
Azure VNet peering is not transitive. If two spoke VNets must communicate directly, they need a direct peering between them or another routing design such as an appliance. Because the requirement is simply private connectivity between the app and data VNets, direct peering is the simplest and correct fix. The existing hub peering does not provide that spoke-to-spoke path.
- ✗
Add a user-defined route in AppSpoke pointing DataSpoke traffic to the hub gateway.
Why it's wrong here
A UDR on AppSpoke can send packets destined for DataSpoke's address space to the hub gateway, but routing alone cannot create a transitive peering path. VNet peering is non-transitive, so the hub gateway does not forward traffic between the two spokes, and DataSpoke has no corresponding route to return traffic to AppSpoke. Even with a UDR, the packet is dropped at the hub unless the hub is an NVA or direct peering exists.
When this WOULD be correct
This would be correct if the requirement was to route traffic through the hub for inspection or filtering, and the hub had a direct connection to DataSpoke (e.g., via a network virtual appliance) without going on-premises.
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.
✓Create a direct VNet peering between AppSpoke and DataSpoke.Correct answer▾
Why this is correct
Azure VNet peering is not transitive. If two spoke VNets must communicate directly, they need a direct peering between them or another routing design such as an appliance. Because the requirement is simply private connectivity between the app and data VNets, direct peering is the simplest and correct fix. The existing hub peering does not provide that spoke-to-spoke path.
✗Add an NSG rule that allows traffic from AppSpoke to DataSpoke.Wrong answer — click to see why▾
Why this is wrong here
NSG rules control traffic filtering, not routing. They cannot establish a direct path between VNets; traffic would still flow through the hub, potentially using on-premises connectivity.
★ When this WOULD be the correct answer
An NSG rule would be correct if the question asked how to block or allow specific traffic between subnets within the same VNet, or between VNets already connected via peering, where routing is already in place.
Why candidates choose this
Candidates may confuse NSGs with routing, thinking that allowing traffic in a firewall-like rule is sufficient to enable connectivity, overlooking the need for a network path.
✗Enable gateway transit on both spoke peerings.Wrong answer — click to see why▾
Why this is wrong here
Gateway transit allows spoke VNets to use the hub VPN gateway to reach on-premises networks, but it does not enable direct private connectivity between spokes. Traffic between AppSpoke and DataSpoke would still be routed through the hub, potentially going on-premises if the hub gateway is involved.
★ When this WOULD be the correct answer
In a scenario where a spoke VNet needs to reach an on-premises network through the hub VPN gateway, enabling gateway transit on the spoke-to-hub peering is correct. For example, if AppSpoke must connect to an on-premises database via the hub gateway, enabling gateway transit on AppSpoke's peering with the hub is required.
Why candidates choose this
Candidates may confuse gateway transit with enabling direct communication between spokes, thinking that enabling it on both peerings allows spokes to talk directly through the hub without additional configuration.
✗Add a user-defined route in AppSpoke pointing DataSpoke traffic to the hub gateway.Wrong answer — click to see why▾
Why this is wrong here
Adding a user-defined route in AppSpoke pointing DataSpoke traffic to the hub gateway would force traffic through the hub, which then routes to on-premises if no direct peering exists, violating the requirement to avoid sending traffic on-premises first.
★ When this WOULD be the correct answer
This would be correct if the requirement was to route traffic through the hub for inspection or filtering, and the hub had a direct connection to DataSpoke (e.g., via a network virtual appliance) without going on-premises.
Why candidates choose this
Candidates may think that routing through the hub is always the correct way to connect spokes, not realizing that hub routing can inadvertently send traffic on-premises if the hub's default route points there.
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
VNet
A virtual private network inside a cloud provider that lets you securely connect and isolate your cloud resources.
About these practice questions
Courseiva writes every AZ-104 question from scratch — 1,049 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.