Azure VNet Peering and Hub-Spoke Topology for AZ-700

What is this page about?

A focused study guide to how the AZ-700 Azure Network Engineer exam tests hub-spoke topology and VNet peering, the Microsoft-recommended landing-zone design where a central hub hosts shared firewalls, gateways, and DNS for peripheral spokes. It drills the most-tested concepts, non-transitive peering, gateway transit, user-defined routes and forced tunneling, Azure Route Server, and Azure Firewall policy hierarchy, plus ExpressRoute and VPN coexistence, NSG and ASG patterns, and private endpoints across the hub, warning candidates who miss these lose roughly a quarter of the exam.

What has been corrected on this page?

Every accepted correction to this page is recorded with the exact change, so readers can see how the page improved over time.

1. 11 July 2026 · corrected by Melik Can Sariyer

   2 flagged issues verified, same recurring unverified-case-study pattern: a 'Heineken global infrastructure team's publicly described Azure landing zone' claim with an unverified specific figure (40+ spokes) had no locatable source and was generalized; a claim attributed to 'Microsoft's principal program manager Anavi Nahar... published guidance' (Nahar is a real co-author of the AZ-700 Exam Ref book, but this specific guidance claim was unverifiable and future-dated to 2026 as if settled) was de-attributed to Microsoft's general documentation.

   Before

   The Heineken global infrastructure team's publicly described Azure landing zone uses gateway transit from a single hub to over forty spokes across regions, with Azure Route Server dynamically propagating routes from on-premises to spokes. This pattern appears nearly verbatim in MeasureUp AZ-700 practice questions. [...] Microsoft's principal program manager Anavi Nahar has published guidance comparing Route Server with traditional UDR-based hub-spoke. The Microsoft-recommended pattern in 2026 is Route Server for any deployment beyond a handful of spokes.

   After

   A common enterprise landing-zone pattern uses gateway transit from a single hub to many spokes across regions, with Azure Route Server dynamically propagating routes from on-premises to spokes. This pattern appears nearly verbatim in MeasureUp AZ-700 practice questions. [...] Microsoft's general documentation compares Route Server with traditional UDR-based hub-spoke. The Microsoft-recommended pattern is Route Server for any deployment beyond a handful of spokes.

   Why: Removed unverified Heineken company-specific claim with an unverified '40+ spokes' figure (no locatable source, inconsistent with sibling article), generalized to an unnamed pattern. De-attributed an unverifiable, future-dated guidance claim previously attributed by name to Anavi Nahar (a real AZ-700 Exam Ref co-author, but this specific claim had no locatable source) to Microsoft's general documentation instead. Live post id 639.

   View the full record →

Who checked this page?

1 contributor has checked "Azure VNet Peering and Hub-Spoke Topology for AZ-700" on Pass4Sure. Each name below links to that person's public CitePep profile, where every contribution they have made is listed with the exact change they proposed.