Expert
AZ-305AZ-305 Walkthrough: Designing a Hub-and-Spoke Virtual Network Architecture
Hub-and-spoke network design is one of the most frequently tested AZ-305 scenario types. This walkthrough covers a representative question and the reasoning framework that applies across variations.
The question
A company has three Azure subscriptions: Production, Development, and Shared Services. All subscriptions must share a centralised network virtual appliance (NVA) for traffic inspection and a centralised Azure Bastion instance for secure VM access. Spoke virtual networks must not be able to communicate with each other directly. Which network topology meets these requirements? A. Peer all VNets in all three subscriptions to each other (full mesh). Deploy the NVA and Bastion in the Production subscription. B. Create a hub VNet in the Shared Services subscription. Peer the Production and Development VNets to the hub. Deploy the NVA and Bastion in the hub VNet. Disable VNet peering's "Allow gateway transit" in spoke VNets. C. Create a hub VNet in the Shared Services subscription. Use Azure Virtual WAN to connect all spoke VNets to the hub. Deploy the NVA and Bastion in each spoke VNet. D. Create an Azure Virtual WAN hub in each subscription. Connect all VNets to their local Virtual WAN hub and configure hub-to-hub routing.
[2 marks]
Correct answer: B
Why B is right
This is the textbook hub-and-spoke topology for AZ-305. The hub VNet lives in the Shared Services subscription and hosts centralised resources: the NVA for traffic inspection and Azure Bastion for secure RDP/SSH access. The Production and Development VNets peer to the hub — but VNet peering is not transitive by default. Spoke A cannot reach Spoke B through the hub unless explicitly configured. Since the requirement says spokes must not communicate directly with each other, this default non-transitivity is exactly what you want. Traffic from either spoke that needs to reach the other must route through the NVA, where it can be inspected or blocked.
Why A is wrong
Full mesh peering violates the requirement that spokes cannot communicate directly. In a full mesh, Production and Development are peered to each other — direct communication is possible and the NVA is bypassed. It also fails to centralise the NVA: deploying it in the Production subscription means Development traffic does not route through it unless routing tables are manually configured.
Why C is wrong
Deploying the NVA and Bastion in each spoke VNet defeats the purpose of centralisation. The question explicitly requires a single centralised NVA and a single Bastion instance. Duplicate deployments increase cost and create management inconsistency.
Why D is wrong
Multiple Virtual WAN hubs in each subscription is the wrong topology for this scenario. Virtual WAN is designed for large-scale branch-to-Azure or multi-region connectivity — it introduces complexity and cost that is unnecessary when the requirement is three VNets with a simple hub. It also puts hubs in Production and Development rather than Shared Services, which breaks the centralisation model.
The hub-and-spoke decision framework
Centralised shared services = hub VNet in a dedicated subscription
Hub VNets belong in a Shared Services or Connectivity subscription, not in Production. This separation of concerns is a core Azure landing zone pattern and appears repeatedly in AZ-305 scenarios.
VNet peering is not transitive — use this to your advantage
Spokes cannot reach each other through the hub unless you add User Defined Routes (UDRs) forcing traffic through the NVA. The default non-transitivity is often the correct security posture — do not add transitivity unless the scenario requires it.
Azure Bastion and NVA belong in the hub
Both Bastion (secure VM access) and NVAs (firewalls, traffic inspection) are centralised services. In hub-and-spoke, they live in the hub VNet so all spokes use the same instance. Putting them in spokes duplicates cost and breaks the model.
Practice AZ-305
Exam simulation, graded results, and detailed guidance on every question.