Contoso Ltd. has a hub-spoke topology in East US: a hub VNet (Hub-VNet) with an NVA and two spoke VNets (Spoke-A and Spoke-B). Spoke-A is peered to Hub-VNet and Spoke-B is peered to Hub-VNet. Engineers notice VMs in Spoke-A cannot reach VMs in Spoke-B over the peering connections. Which explanation best describes why direct spoke-to-spoke traffic does not traverse the hub peering, and what Contoso must do to enable spoke-to-spoke communication without re-architecting all peers?

VNet peering is non-transitive, meaning peered VNets can communicate directly, but cannot use a peered VNet as a transit point to reach other peered VNets. In this scenario, Spoke-A can reach Hub-VNet, and Spoke-B can reach Hub-VNet, but Spoke-A cannot directly reach Spoke-B through Hub-VNet. To enable spoke-to-spoke communication via the hub, you need to configure User Defined Routes (UDRs) on each spoke VNet. These UDRs should direct traffic destined for other spokes to the NVA in the hub VNet as the next hop. The NVA then forwards the traffic to the destination spoke. The other options are incorrect: VNet peering does not block east-west traffic by default; there is no 'Transit Peering' option; NSGs control traffic flow within and between VNets but don't enable transitivity; and Azure's routing behavior is not dependent on subscription boundaries for this type of scenario.