Spoke A and spoke B each peer to the hub. A harbor-pilot VM in A cannot reach a water-lab VM in B. What should the security engineer conclude?
Select an answer to reveal the explanation.
Short Explanation
Hub-and-spoke peering isn’t a friendship bracelet—A doesn’t automatically reach B. Hairpin through the hub firewall, mesh with AVNM, or peer the spokes on purpose.
Full Explanation
Azure VNet peering is non-transitive: two spokes peered only to a hub do not gain automatic spoke-to-spoke connectivity through that hub. When spoke A and spoke B each peer to the hub but a harbor-pilot VM in A cannot reach a water-lab VM in B, conclude non-transitivity and use a hub firewall or NVA hop with proper routing, an Azure Virtual Network Manager mesh connectivity configuration, or an intentional spoke-to-spoke peering if policy allows.
Claiming peering already connects every spoke transitively so the failure must be DNS only is false. Requiring overlapping address spaces fails backwards: overlapping spaces prevent peering. Claiming peering encrypts spoke-to-spoke with IPsec automatically invents a feature; peering is not an IPsec overlay.
Exam caveat: hub-spoke designs need explicit inspection and routing for spoke-spoke traffic, or mesh peering when appropriate. Operational check: verify peering links, attempt spoke-spoke connectivity, implement firewall routing or mesh as chosen, and retest while confirming NSGs allow the intended flow. In municipal Azure estates, document the decision in the change record, validate with a nonproduction rehearsal, and confirm monitoring still pages the on-call operator when the control fails closed during an incident drill.