AZ-104 Practice Question 8: Vnet Peering Transitivity
Microsoft Azure Administrator Associate (AZ-104) · Test 1 · question 8 of 10
Your hub-and-spoke topology in East US contains VNet-Hub, VNet-Spoke1, and VNet-Spoke2, with non-overlapping address spaces. VNet-Hub is peered to each spoke, and both peerings are in the Connected state. VMs in each spoke can reach a jump box in the hub.
Developers report that a VM in VNet-Spoke1 cannot reach a VM in VNet-Spoke2 on any port. You must enable connectivity between the two spokes with the fewest changes and without deploying any new resources. What should you do?
Show answer and explanation
Answer:
Virtual network peering is not transitive. Spoke1 <-> Hub and Hub <-> Spoke2 do not combine into Spoke1 <-> Spoke2; each spoke's effective routes contain a Virtual network peering route only for the hub's address space. With no new resources allowed, the only way to give the spokes a direct data path is a peering between them, after which each side gets the peering route automatically and traffic stays on the Microsoft backbone.
Option B configures the wrong kind of transit. Gateway transit lets a spoke use the hub's VPN or ExpressRoute gateway to reach on-premises networks; it does not route spoke-to-spoke traffic, and a spoke using a remote gateway cannot have a gateway of its own.
Option C is necessary but not sufficient. Allow forwarded traffic permits a peered network to accept traffic that did not originate in it, the setting you need when a network virtual appliance or Azure Firewall in the hub forwards between spokes. Without that appliance (and the user-defined routes pointing at it), there is nothing in the hub to do the forwarding, and deploying one is excluded by the stem.
Option D has nothing to route through. Peering does allow a user-defined route's next hop to be a VPN gateway in the peered hub, a documented service-chaining pattern, although an ExpressRoute gateway is not supported as a next hop for routing between virtual networks. But this topology has no gateway of any kind in VNet-Hub, and deploying one is exactly the new resource the stem forbids, so a route aimed at a virtual network gateway has no target.
Reference: Azure Virtual Network peering