AZ-305
Deep Dive
Network topology is the foundation of every landing zone. The AZ-305 evaluates hub-spoke design, when to scale to Virtual WAN, and how routing (UDRs) forces traffic through the central firewall.
Contents
Design rules
Segmentation by subnet
VNet peering connects two VNets over the Microsoft backbone: minimal latency, no gateways or extra encryption needed. Global peering = across regions. Not transitive: A↔B and B↔C does not imply A↔C — the reason the hub with a shared firewall/gateway exists.
🌐Árbol de decisión — Topología de red
Single VNet · Hub-Spoke · Virtual WAN · Mesh
Pregunta 1
¿La arquitectura necesita más de una VNet (múltiples equipos, workloads o suscripciones aislados)?
💡 Señal single VNet: organización pequeña, un solo workload, subnets por tiers (web/app/db), sin requisito de aislamiento fuerte entre equipos
| Topology | When |
|---|---|
| Single VNet with subnets | Small organization, one workload, one region |
| Hub-Spoke | The enterprise standard: centralized shared services, per-workload isolation |
| Virtual WAN (managed hub) | Many regions + many branches: Microsoft manages the hub and routing |
| Mesh (full peering) | A few VNets that all talk to each other; automated with Virtual Network Manager |
🏛️Why use Hub-Spoke?
The Hub-Spoke pattern centralizes Firewall, VPN Gateway, Bastion, and DNS in one hub VNet. Each team has its own isolated spoke (VNet). All traffic between spokes passes through the Firewall — centralized control without duplicating infrastructure.
🛡️ Centralized security
Azure Firewall in the hub inspects all traffic between spokes. There is no direct spoke-to-spoke communication without going through the Firewall.
🔒 Secure admin access
Azure Bastion enables RDP/SSH to VMs in any spoke straight from the browser, without exposing public IPs on any VM.
📡 Shared DNS
A single private DNS zone in the hub resolves internal names for every VNet with no extra per-spoke configuration.
The HUB contains (shared services)
The SPOKES contain
Benefits the exam expects you to cite
A single shared gateway and firewall (cost), isolation between workloads (security), centralized management of north-south and east-west traffic (governance), and growth by adding spokes without touching the hub (scale).
Manual Hub-Spoke
Virtual WAN
User-Defined Routes
Related cases
| Requirement | Design |
|---|---|
| Isolated workloads sharing a firewall and gateway | Hub-spoke |
| Spokes use the hub's gateway | Gateway transit + use remote gateways |
| All outbound traffic from spokes inspected | UDR 0.0.0.0/0 → Azure Firewall |
| Spoke A talks to spoke B in a controlled way | UDRs via the hub firewall (non-transitive peering) |
| 40 branches + 5 regions + automatic routing | Virtual WAN (secured hubs) |
| VM internet traffic must exit through the on-prem datacenter | Forced tunneling |
| Predictable outbound IPs for a partner's whitelist | NAT Gateway on the subnet |
| Connect VNets across different regions | Global VNet peering (or vWAN) |
| Manage topology/security for 100 VNets at scale | Azure Virtual Network Manager |
Did you get this topic?
Test what you just learned
A company has 12 workload VNets in one region, ExpressRoute connectivity to on-premises, and requires that ALL traffic (spoke-spoke, spoke-internet, spoke-onprem) be inspected by a central firewall while minimizing gateway cost. What design do you propose?
Put what you learned to the test with original AZ-305 exam questions.
Start AZ-305 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.