A hospital group wants branch edges to reach the regional cloud gateway and not to build branch-to-branch data paths. Which policy creates that overlay shape?
Select an answer to reveal the explanation.
Short Explanation
You want every branch road to end at the hub, not at the neighbor's driveway. You permit branch TLOCs only toward the cloud-gateway hub in centralized control policy. A firewall that allows everything does not draw that map, and an SLA does not decide which TLOCs exist.
Full Explanation
Centralized control policy can restrict which TLOCs are advertised to which sites. Permitting branch TLOCs only toward the cloud-gateway hub, and not toward other branches, creates the hub-and-spoke data plane the hospital group described. Branches still reach the cloud gateway. They do not learn each other's TLOCs. A zone-based firewall that allows every VPN does not stop the overlay from building branch-to-branch tunnels. It might drop packets later, which is not the same as not offering the path. An application-aware routing SLA that drops traffic when a branch-to-branch tunnel is up would punish flows instead of preventing the topology. Cloud OnRamp for SaaS does not disable branch TLOCs for private prefixes. It steers enabled SaaS applications. Exam caveat: the hub must actually advertise the routes the branches need. A spoke-to-hub TLOC with no prefixes behind it still leaves the branches unable to reach Azure or AWS. Operational check: show sdwan omp tlocs on a branch should list the cloud gateway and should not list other branches after the policy is activated.