A retailer runs POS in VPN 30 and staff devices in VPN 40 on the same WAN Edge and needs POS to reach a shared printer in VPN 40 without merging routing tables. Shared services must stay controlled and leak only specific prefixes. Which route-leaking design provides selective end-to-end segmentation with controlled sharing?
Select an answer to reveal the explanation.
Short Explanation
You nailed it if you leaked just the printer, not the whole table. A control policy with export-to shares exactly one prefix and keeps POS otherwise isolated.
Full Explanation
The correct design uses a centralized control policy, which acts on OMP routes at the SD-WAN Controller: a route match on the printer prefix in VPN 40, with an accept action that uses export-to the POS VPN, causes the Controller to install and re-advertise only that prefix into VPN 30, so both VPNs keep separate routing tables and the leak stays at prefix level. Leaking every route in both directions fails on selectivity because it exchanges entire tables, which violates controlled sharing, expands the attack surface and route state, and contradicts least privilege for a single shared printer. Merging the VPNs fails on segmentation because the stem requires separate routing tables; one VPN with an ACL removes the isolation boundary and relies on filtering alone. The centralized data policy fails by plane because a data policy can permit, drop, or steer forwarding for matched traffic once routes exist, but it has no action that leaks routes between VPN route tables, so POS would still lack a route to the printer prefix. Exam caveat: inter-VPN route leaking is configured with export-to in a centralized control policy (a control policy has no next-hop set action and data policy has no route-leak action), and it applies to service VPNs rather than VPN 0 or VPN 512. Practical check: confirm the policy is applied to the right site list and direction, verify only the printer prefix appears in the VPN 30 table, and test POS to printer connectivity.