Cascade Regional Airlines peers VNet A (headquarters) with VNet B (an outstation office), and separately peers VNet B with VNet C (a maintenance depot). No peering exists directly between VNet A and VNet C. Can a VM in VNet A reach a VM in VNet C by routing through VNet B?
Select an answer to reveal the explanation.
Short Explanation
Peering isn't like a road network where you can just keep driving through connected towns. It's strictly point-to-point: A can talk to B, and B can talk to C, but that doesn't build a path from A to C. Cascade would need to peer A and C directly for that route to exist.
Full Explanation
Azure VNet peering is explicitly non-transitive: a peering relationship only enables direct connectivity between the two VNets it connects, and does not automatically extend to any third VNet peered to one of them. So even though VNet B has separate peerings to both VNet A and VNet C, VNet A and VNet C are not connected to each other unless an additional peering is created directly between them. The claim that peering chains automatically is the exact misconception the non-transitive rule exists to correct, and it is a common real-world outage cause when teams assume a hub-and-spoke topology grants spoke-to-spoke connectivity for free. Gateway transit is a separate feature that lets a spoke VNet use a hub VNet's VPN or ExpressRoute gateway to reach on-premises networks; it has nothing to do with routing between two spoke VNets, so enabling it does not solve this problem. VNet peering also is not limited to a single region — global VNet peering across regions is fully supported — so the region-based distractor is factually wrong on top of being irrelevant. To connect VNet A and VNet C, Cascade must create a dedicated peering between them, or route through a network virtual appliance or Azure Firewall in VNet B with the correct user-defined routes.