AZ-305 Design infrastructure solutions Practice Question
A company has multiple Azure virtual networks (VNets) in different regions and an on-premises data center connected via ExpressRoute. They need to implement a hub-and-spoke topology where a hub VNet hosts shared network virtual appliances (NVAs) for traffic inspection. All traffic between spokes and between spokes and on-premises must be routed through the hub. The company wants to minimize the administrative overhead of configuring and maintaining routing. Which Azure solution should they implement?
⚠ Common exam trap
It's easy for candidates to choose VNet peering with UDRs (Option B) because it is a familiar pattern for hub-and-spoke, but they overlook that Azure Virtual WAN is the managed service designed to eliminate the administrative overhead of manual routing, especially when multiple regions and on-premises connectivity are involved.
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
✓
Use Azure Virtual WAN with a secured virtual hub.
Azure Virtual WAN with a secured virtual hub is the correct choice because it provides a managed hub-and-spoke topology with built-in routing, eliminating the need for manual user-defined routes (UDRs) and route tables. The secured virtual hub includes Azure Firewall for traffic inspection, and all inter-spoke and on-premises traffic is automatically routed through the hub via the Virtual WAN routing engine, which uses the Border Gateway Protocol (BGP) to propagate routes dynamically. This minimizes administrative overhead by centralizing routing and security management.
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 Azure Virtual WAN with a secured virtual hub.
Why this is correct
Azure Virtual WAN provides a managed hub-and-spoke architecture with automatic routing. A secured virtual hub can integrate NVAs or Azure Firewall, and it handles transitive routing between spokes and on-premises without manual route tables or UDRs.
- ✗
Use VNet peering with user-defined routes (UDRs) in each spoke and Azure Route Server.
Why it's wrong here
VNet peering is non-transitive, so a hub-and-spoke design with peerings alone cannot route between spokes or from a spoke to on-premises. UDRs must be manually added to every spoke subnet to force traffic to an NVA, and Azure Route Server only advertises routes learned from its BGP peer (the NVA) to the hub — it does not automatically propagate connectivity to all spokes. As the number of spokes and regions grows, maintaining these UDRs and BGP peering for each NVA becomes a significant administrative burden and is prone to route misconfiguration.
- ✗
Create a single large VNet and use network security groups (NSGs) to isolate traffic.
Why it's wrong here
A single Azure VNet is scoped to one region and cannot span multiple regions, so it cannot directly interconnect spoke networks in different regions as the scenario requires. While NSGs can filter East-West traffic within a VNet, they do not route traffic, integrate with NVAs, or provide connectivity to on-premises sites; you would still need additional VPN/ExpressRoute tunnels and peering to extend outside the VNet. This approach also hits subscription and address space limits and is a poor architectural pattern for regional isolation, redundancy, or management separation.
- ✗
Use Azure Firewall in the hub VNet and configure forced tunneling via custom routes.
Why it's wrong here
Placing Azure Firewall in a conventional hub VNet only works if you manually create UDRs on every spoke subnet to send traffic to the firewall's private IP, and forced tunneling specifically influences internet-bound traffic, not transitive spoke-to-spoke or branch-to-spoke routing. The hub VNet still relies on non-transitive VNet peering and separate VPN/ExpressRoute gateways, so you must continually manage custom routes and ensure the firewall receives traffic from all regions and on-prem sites. Azure Firewall does not automatically exchange routing information between spokes or branches, and this configuration lacks the simplified routing tables and dynamic propagation that a secured Virtual WAN hub provides.
Go deeper
Related to this question
About these practice questions
This AZ-305 question is part of Courseiva's 212-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-305 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-305 exam.