A manufacturer extends its fabric to AWS and Azure, hosts workloads in multiple VPCs and VNets, and needs scalable private transit without per-branch IPsec sprawl to each VPC. Which Cloud OnRamp for IaaS connectivity design best meets this cloud transit requirement?
Select an answer to reveal the explanation.
Short Explanation
Cloud gateways become your regional airline hubs for multi-cloud traffic. Aggregation beats a tangle of direct flights from every town. This hub design uses transit routing to reach many VPCs cleanly.
Full Explanation
The correct design is right because Cloud OnRamp for IaaS hosts SD-WAN gateway routers in AWS and Azure to terminate branch tunnels once, then provides transitive peering to multiple VPCs and VNets for private branch-to-cloud and cloud-to-cloud reachability without per-VPC sprawl. The Transit Gateway plus Virtual WAN-only design fails by scope because it interconnects VPCs and VNets natively within each provider but provides no SD-WAN aggregation for branches or unified cross-cloud policy, leaving onboarding unscaled. The colocation hub with ExpressRoute and Direct Connect design fails by architecture because dedicated interconnects are ideal for stable hybrid access but centralizing traffic through one facility reintroduces hairpinning and bottlenecks instead of distributed gateways. The per-VPC gateway for local breakout design fails by routing because it aids Internet egress yet omits transitive peering, so VPCs stay isolated and branches still need many adjacencies. For the exam, do not confuse native intra-cloud transit with SD-WAN-managed multi-cloud transit that must combine branch aggregation, segmentation, and transitive peering. As a practical check, verify in SD-WAN Manager (formerly vManage) that gateways show branch control connections and that AWS and Azure route tables show propagated transit prefixes with traceroutes avoiding headquarters.