AZ-104 Implement and Manage Virtual Networking Practice Question
A hub VNet is peered to two spoke VNets. The spokes can reach the hub, but they cannot communicate with each other through the hub. The administrator wants centralized inspection in the hub. What should be deployed and configured?
⚠ Common exam trap
A common mix-up: candidates assume VNet peering is transitive by default, similar to a router, but Azure explicitly requires UDRs and a forwarding device to enable spoke-to-spoke communication through a 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
✓
An Azure Firewall or other NVA in the hub, plus user-defined routes and forwarding support.
Azure Firewall or an NVA in the hub can inspect traffic between spokes, but by default, Azure routing does not forward spoke-to-spoke traffic through the hub. To force this traffic through the firewall, you must configure user-defined routes (UDRs) on the spoke subnets with a next hop of the firewall's private IP, and enable IP forwarding on the NVA. This setup enables centralized inspection and transitive routing through the hub.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
An Azure Firewall or other NVA in the hub, plus user-defined routes and forwarding support.
Why this is correct
VNet peering is non-transitive, so for spoke VNets to communicate through the hub, you must insert a routing element. Deploying Azure Firewall (or an NVA with IP forwarding enabled) in the hub, then configuring user-defined routes (UDRs) on each spoke subnet with the firewall/NVA's private IP as the next hop, forces spoke-to-spoke traffic to transit the hub. The NVA must also have IP forwarding enabled and be able to route between the spoke address spaces; Azure Firewall does this natively. This setup provides the centralized inspection and connectivity the scenario requires.
- ✗
Only additional peering links between the hub and both spokes.
Why it's wrong here
Creating additional VNet peerings between the hub and both spokes—whether re-establishing or adding more peering links—does nothing to make traffic traverse the hub. Azure VNet peering is fundamentally non-transitive: a packet from spoke1 to spoke2 will only propagate along the peered edge if there is an explicit route and a forwarding device at the hub to relay it. Without a next-hop appliance and associated user-defined routes, the hub simply drops traffic it has no route for, or the spokes cannot reach each other. Adding more hub peering links changes none of this; the limitation is architectural, not a matter of link count.
When this WOULD be correct
In a scenario where the requirement is simply to enable connectivity between spokes and the hub (not spoke-to-spoke through the hub), and no centralized inspection is needed, adding peering links would suffice.
- ✗
A private endpoint in the hub for each spoke subnet.
Why it's wrong here
Private endpoints are point-in-time connections that expose a specific Azure service (e.g., a storage account, SQL database) on a private IP inside a VNet; they are not routing devices and do not forward traffic between VNets. Placing a private endpoint in the hub for each spoke subnet is conceptually wrong because private endpoints attach to a service, not to a subnet, and they don't create any route between the spoke address spaces. Even if you created private endpoints for services in the hub, spoke-to-spoke traffic would still have no next hop, and the endpoints would only service individual PaaS connections. This option fails to provide the required inter-spoke connectivity or inspection.
When this WOULD be correct
In a scenario where spokes need secure, private access to an Azure PaaS service (e.g., Azure Storage or SQL Database) deployed in the hub VNet, without traversing the public internet, deploying a private endpoint in the hub for that service would be correct.
- ✗
A service endpoint on each spoke subnet to the hub VNet.
Why it's wrong here
Configuring service endpoints on each spoke subnet to the hub VNet is an incorrect fix because service endpoints are designed to secure access from a subnet to a specific Azure PaaS service (like Storage or SQL) over the Microsoft backbone, not to provide layer-3 connectivity between virtual networks. A service endpoint creates a route to the PaaS service's public IP range, but it has no effect on routing between VNet address spaces. Spoke VNets still do not learn a route to each other, and the hub cannot forward traffic without an NVA or firewall. Thus, this solution neither enables transit nor adds any inspection capability.
When this WOULD be correct
In a scenario where a VNet needs secure, private access to an Azure PaaS service (e.g., Azure Storage, SQL Database) located in another VNet, deploying a service endpoint on the spoke subnet to the hub VNet would allow the spoke to access that PaaS service privately via the hub.
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.
✓An Azure Firewall or other NVA in the hub, plus user-defined routes and forwarding support.Correct answer▾
Why this is correct
VNet peering is non-transitive, so for spoke VNets to communicate through the hub, you must insert a routing element. Deploying Azure Firewall (or an NVA with IP forwarding enabled) in the hub, then configuring user-defined routes (UDRs) on each spoke subnet with the firewall/NVA's private IP as the next hop, forces spoke-to-spoke traffic to transit the hub. The NVA must also have IP forwarding enabled and be able to route between the spoke address spaces; Azure Firewall does this natively. This setup provides the centralized inspection and connectivity the scenario requires.
✗Only additional peering links between the hub and both spokes.Wrong answer — click to see why▾
Why this is wrong here
Additional peering links between the hub and both spokes do not enable spoke-to-spoke communication through the hub; they only create direct peering, which still requires routing configuration (like UDRs) to forward traffic through the hub for centralized inspection.
★ When this WOULD be the correct answer
In a scenario where the requirement is simply to enable connectivity between spokes and the hub (not spoke-to-spoke through the hub), and no centralized inspection is needed, adding peering links would suffice.
Why candidates choose this
Candidates may think that more peering automatically enables transitive routing, but VNet peering is non-transitive by default, so additional peering alone does not solve the problem.
✗A private endpoint in the hub for each spoke subnet.Wrong answer — click to see why▾
Why this is wrong here
A private endpoint in the hub allows private connectivity to a specific Azure service (e.g., Azure SQL) from the spokes, but it does not enable inter-spoke routing or centralized inspection of traffic between spokes.
★ When this WOULD be the correct answer
In a scenario where spokes need secure, private access to an Azure PaaS service (e.g., Azure Storage or SQL Database) deployed in the hub VNet, without traversing the public internet, deploying a private endpoint in the hub for that service would be correct.
Why candidates choose this
Candidates may confuse private endpoints with network connectivity solutions, thinking that a private endpoint in the hub can route traffic between spokes, when it only provides private access to a specific service.
✗A service endpoint on each spoke subnet to the hub VNet.Wrong answer — click to see why▾
Why this is wrong here
Service endpoints allow private access from a VNet to Azure PaaS services, not routing traffic between VNets. They do not enable spoke-to-spoke communication through the hub.
★ When this WOULD be the correct answer
In a scenario where a VNet needs secure, private access to an Azure PaaS service (e.g., Azure Storage, SQL Database) located in another VNet, deploying a service endpoint on the spoke subnet to the hub VNet would allow the spoke to access that PaaS service privately via the hub.
Why candidates choose this
Candidates may confuse service endpoints with VNet peering or think they provide a routing path between VNets, misunderstanding that service endpoints only apply to Azure service traffic, not general VNet-to-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
Firewall
A firewall is a network security system that monitors and controls incoming and outgoing traffic based on predetermined security rules to protect trusted internal networks from untrusted external networks.
Key term
Azure Firewall
Azure Firewall is a cloud-based network security service that protects your virtual networks in Microsoft Azure by filtering traffic based on rules you define.
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.