AZ-305 Practice Question 19: Central Egress Inspection
Microsoft Azure Solutions Architect Expert (AZ-305) · Test 2 · question 9 of 10
A manufacturer is consolidating 30 workload virtual networks, each in its own subscription, onto a single network design. Security requires that every packet leaving a workload for the internet, and every packet travelling between two workload virtual networks, be inspected and logged by one central firewall. The workloads also need to reach the on-premises datacenter over the company's existing ExpressRoute circuit, and the network team refuses a design in which adding a workload requires touching the other 29.
Which design should you recommend?
Show answer and explanation
Answer:
This is the hub-spoke topology the Cloud Adoption Framework recommends, and the routing half of it is what makes the inspection requirement actually enforceable. Peering alone is not enough: virtual network peering is non-transitive, and a spoke's default route still sends internet-bound traffic straight out. Microsoft's guidance is to use user-defined routes to force spoke traffic to Azure Firewall or another appliance acting as a router in the hub, which both enables spoke-to-spoke connectivity through the firewall and makes the hub the single egress point. The shared ExpressRoute gateway lives in the hub with gateway transit enabled, so spokes reach on-premises without their own gateways, and onboarding workload 31 is one peering plus one route table, no change to the others.
Option A scales badly and inspects nothing. A full mesh of 30 virtual networks is 435 peerings and runs into the per-virtual-network peering limit, while network security groups filter on five-tuples and service tags; they cannot perform the application-level inspection and logging the requirement describes.
Option B gets the topology right and the routing wrong, the most common version of this mistake. Network security groups permit or deny traffic; they never change the next hop. Without route tables, spoke traffic to the internet leaves directly through Azure's default outbound path and spoke-to-spoke traffic simply has no path at all, so the firewall sees neither flow.
Option D gives up the "one central firewall" requirement and multiplies cost by 30. Firewall Manager would centralize the policy, but each spoke would still enforce and log locally, and a shared firewall in a hub is the pattern Microsoft positions as the significant cost saving over per-network appliances.
Reference: Hub-spoke network topology in Azure