AZ-305 Design infrastructure solutions Practice Question
A company is designing a hub-spoke network topology across multiple Azure regions. They plan to deploy a third-party network virtual appliance (NVA) in the hub for traffic inspection. They require that all traffic between spokes in different regions must be routed through the hub NVA, and they want to minimize the number of peered connections. Which solution should they implement?
⚠ Common exam trap
Many exam-takers assume Virtual WAN (Option B) is the only way to simplify hub-spoke routing, but it does not support custom third-party NVAs for traffic inspection without complex workarounds, making VNet peering with UDRs the correct choice for this specific requirement.
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
✓
VNet peering with user-defined routes (UDRs) in each spoke pointing to the NVA IP in the hub
VNet peering combined with user-defined routes (UDRs) allows traffic between spokes in different regions to be forced through the NVA in the hub for inspection. By configuring UDRs in each spoke with the next hop set to the NVA's private IP, you ensure inter-spoke traffic traverses the hub without requiring a full mesh of peering connections. This minimizes the number of peered connections (only hub-to-spoke peering is needed) while meeting the routing requirement.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
VNet peering with user-defined routes (UDRs) in each spoke pointing to the NVA IP in the hub
Why this is correct
VNet peering with UDRs is the correct approach because Azure VNet peering is non-transitive, so spokes cannot reach each other through the hub unless traffic is explicitly directed to the NVA. You associate a route table with each spoke subnet, adding a UDR with next hop type 'Virtual Appliance' and the NVA's private IP, and you must enable IP forwarding on the NVA's NIC. This enforces all inter-spoke traffic through the NVA while maintaining only one peering connection per spoke, which is the minimal, cost-effective hub-and-spoke design for a third-party firewall or router.
- ✗
Azure Virtual WAN with a secured hub using Azure Firewall
Why it's wrong here
Azure Virtual WAN with a secured hub using Azure Firewall is wrong because the requirement specifically asks for a third-party network virtual appliance (NVA), but the Virtual WAN secured hub is a Microsoft-managed Azure Firewall deployment managed via Azure Firewall Manager. You cannot install a custom third-party NVA inside the Virtual WAN hub itself, and the architecture of Virtual WAN (with its own routing constructs like routing intent) is fundamentally different from a classic hub-spoke with user-defined routes. This option also forces you to change your deployment model, which is unnecessary and misaligned with the stated NVA requirement.
- ✗
Azure VNet-to-VNet VPN gateways between all spokes
Why it's wrong here
Azure VNet-to-VNet VPN gateways between all spokes is wrong because it creates a full-mesh topology requiring O(n²) VPN gateways and connections, which dramatically increases cost, operational overhead, and configuration complexity. Additionally, VPN gateway routing is based on the gateway's BGP and route table, not on the hub NVA, so inter-spoke traffic would traverse the IPsec tunnels directly between spoke gateways and bypass the NVA entirely, breaking the requirement for centralized inspection and control through the hub appliance.
- ✗
Azure ExpressRoute with private peering
Why it's wrong here
Azure ExpressRoute with private peering is wrong because ExpressRoute is designed for private, high-bandwidth connectivity between an on-premises network and Azure, not for routing traffic between Azure VNets. Using ExpressRoute for inter-spoke traffic would force traffic to hairpin through your on-premises routers, adding significant latency and requiring on-premises infrastructure to handle Azure-to-Azure traffic, and it still would not route traffic through the hub NVA. It also incurs unnecessary egress costs and complexity, making it an inappropriate choice for this hub-spoke scenario.
Go deeper
Related to this question
About these practice questions
One of 795 original AZ-305 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-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.