A hospital runs clinical VPN 20 and guest VPN 30 on the same WAN Edges but guest kiosks need controlled access to a scheduling server in VPN 20, while all other guest routes must stay isolated. Which route-leaking policy between VPNs grants selective access to the shared service?

The centralized control policy leaking only the scheduling server prefix from VPN 20 into VPN 30 is correct because inter-VPN route leaking is a control-plane function defined centrally and distributed to the WAN Edges. It installs that single route in the guest table while keeping every other clinical prefix hidden, providing controlled shared-service access without breaking isolation. Leaking only the scheduling prefix from VPN 30 into VPN 20 reverses the direction: it imports guest reachability into the clinical VPN but leaves kiosks in VPN 30 without a route to the server. A centralized data policy permitting application traffic from VPN 30 to VPN 20 operates in the wrong plane; data policy can permit, deny, or engineer application forwarding once routing exists, but cannot create or import routes between VPN routing tables, so the kiosks still lack a resolvable next hop. Leaking the whole VPN 20 subnet with the scheduler fails by granularity: although it reaches the server, it also exposes unrelated clinical hosts, violating the requirement to keep all other routes isolated and widening the security boundary. An exam caveat is that selective-leak questions test policy type, exact prefix, and source-to-destination direction together, so check all three rather than choosing a plausible sharing mechanism. As a practical check, confirm the applied controller policy in SD-WAN Manager and inspect the Edge VPN 30 routing table for only the server prefix learned from VPN 20; test kiosk access to the server and verify other clinical addresses remain unreachable. Return traffic from the server also needs guest prefixes leaked back toward VPN 20 using the same mechanism.