AZ-305 Design infrastructure solutions Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Implement VNet peering with user-defined routes (UDRs) to force traffic through the NVA

  Why it's wrong here

  VNet peering is non-transitive, so using UDRs to force traffic through an NVA means every spoke VNet needs its own explicit route table pointing to the NVA, and the NVA must also have return routes to every spoke—this quickly becomes a complex, manually managed mesh as the number of VNets grows. Additionally, UDRs on one peering do not propagate to other peered VNets, so any new VNet or IP range change requires updating multiple route tables, and you also have to configure IP forwarding and high availability for the NVA itself, making this approach operationally heavy and error-prone rather than a scalable centralized inspection solution.

• ✗

  Use Azure Firewall in each VNet to inspect traffic locally

  Why it's wrong here

  Placing an Azure Firewall inside each VNet distributes inspection to every spoke, which means you lose a single central point of management for security policies and must configure, monitor, and maintain separate firewall rules per VNet, increasing both cost and administrative overhead. It also fails to meet the requirement for centralized inspection because each firewall only sees traffic to and from its own VNet; traffic flowing between two spoke VNets is inspected by two different firewalls (or may bypass inspection if you try to peer directly), resulting in inconsistent policy enforcement and no unified security posture across the multi-region environment.

• ✓

  Deploy an Azure Virtual WAN with a secured hub (Azure Firewall) and route traffic through it

  Why this is correct

  Azure Virtual WAN with a secured hub (Azure Firewall) is the correct choice because it provides automatic transitive routing between all connected VNets across regions, so you don't need to manage UDRs or individual peerings. The Azure Firewall in the secured hub centrally inspects all traffic—both VNet-to-VNet and branch-to-VNet—and routing intent can be configured to ensure that traffic is always forced through the firewall for inspection. This architecture scales naturally to many VNets and regions, integrates with ExpressRoute for hybrid connectivity, and centralizes security policy management, satisfying every stated requirement.

• ✗

  Use Azure Route Server to propagate routes to all VNets

  Why it's wrong here

  Azure Route Server only exchanges routes between your virtual network and network virtual appliances (NVAs) via BGP; it does not force traffic through any security appliance or perform packet inspection itself. While Route Server can simplify dynamic route propagation, it lacks the ability to define a centralized inspection point, so it cannot ensure that traffic is routed through the firewall as required. Without an additional mechanism (such as UDRs or Virtual WAN routing intent) it provides no security enforcement, and even then, managing inspection centrally across many VNets would still rely on the same transitive routing limitations that plague VNet peering.

Go deeper

Related to this question