A retailer runs workloads in AWS and Azure, needs consistent segmentation from branches to VPCs/VNets, and wants automated connectivity without manual IPSec to each cloud. Which integration approach should the architect propose for multicloud and cloud interconnect with the SD-WAN fabric?

The correct approach extends the SD-WAN overlay into both clouds by instantiating virtual WAN Edge routers inside AWS and Azure and attaching them to high-throughput cloud interconnect exchanges, allowing OMP to carry branch VPN segments to those gateways while Cloud OnRamp automation maps them to VPC and VNet routing, which preserves end-to-end segmentation, centralized policy, and zero-touch provisioning without per-VPC tunnel operations. The AWS Transit Gateway design fails on scope because Transit Gateway attachment with OMP exchange automates only the AWS side and leaves Azure VNets outside the fabric, violating the explicitly multicloud requirement even though segmentation and automation within AWS are sound and widely deployed. The backbone-peering design fails on control plane because it provides automated multicloud reachability but defers forwarding and isolation to native cloud constructs rather than extending SD-WAN VPNs via OMP, so branch-to-cloud segmentation is no longer consistent end to end. The individually provisioned tunnel design fails on operations because each VPC and VNet still requires separate tunnel lifecycle, routing, and key handling, which does not meet the automated interconnect requirement despite supporting both clouds with SD-WAN gateways. Exam caveat: distinguish automated interconnect attachment from merely hosting a virtual appliance in cloud, since both place gateways in cloud but only interconnect integration removes per-tunnel setup. Practical check: validate in the controller that cloud gateways appear as OMP peers carrying the branch VPN identifiers and that newly added VPCs and VNets are learned via the interconnect attachment rather than additional tunnel configuration.