A national retailer uses VPN 10 for stores that must send all traffic through regional hubs and VPN 20 for distribution centers that need direct site-to-site exchange. Both VPNs run across the same SD-WAN fabric with two SD-WAN Controllers. Which control-policy topology configuration delivers segmentation using different topologies per VPN?
Select an answer to reveal the explanation.
Short Explanation
You nailed the tricky part — different VPNs can ride one fabric with different shapes. Centralized control on the SD-WAN Controller (formerly vSmart) shapes routes per VPN before they spread, with topology as your shaping tool.
Full Explanation
Centralized control policy on SD-WAN Controller, formerly vSmart, controls OMP route advertisement per VPN, so one policy can declare hub-and-spoke for VPN 10 while declaring mesh for VPN 20 and both intents coexist with full segmentation intact because OMP only installs the permitted topology per VPN identifier. A centralized data policy fails by concept because data policy acts on traffic forwarding after routes exist and cannot change which OMP routes are advertised to build hub-and-spoke versus mesh reachability. A localized control policy fails by concept because local policy affects only the individual router BGP or OSPF interaction and cannot orchestrate fabric-wide hub and spoke roles across all sites. An app-aware policy fails by concept because application-aware routing selects paths based on SLA for existing routes rather than defining the underlying route topology per VPN. Exam caveat is to associate topology keywords hub-and-spoke and mesh strictly with centralized control policy, not data or localized policy. Practical check is to verify in SD-WAN Manager, formerly vManage, that the policy site lists and VPN lists match the intended stores and distribution centers before activation.