A police records bureau needs shared directory services reachable from multiple service VPNs at the hub without merging those VRFs site-wide. Which approach fits Cisco SD-WAN intent?
Select an answer to reveal the explanation.
Short Explanation
Think of the hub as a carefully watched door between locked rooms. You don’t knock the walls down—you leak just the shared-services prefixes the rooms actually need. That’s controlled inter-VPN route sharing, not a full merge.
Full Explanation
Cisco SD-WAN supports controlled inter-VPN route leaking so a police records bureau can reach shared directory services from multiple service VPNs without collapsing segmentation site-wide. At the hub, policy advertises only the shared-service prefixes across VPN boundaries, preserving isolation for everything else while allowing intentional extranet-style access to common infrastructure.
Putting every departmental prefix into VPN 0 so all sites share one table destroys transport-versus-service separation and weakens isolation. Disabling OMP on spokes so inter-VPN traffic hairpins through the Internet underlay breaks overlay control and is not a substitute for intentional leak policy. Bridging service VPNs with a Layer 2 VPLS instance across Edges abandons the L3 VPN segmentation model the design assumes.
Exam caveat: leak only what is required—shared DNS, directory, or similar prefixes—using explicit policy; full-mesh VPN merging is a different topology choice, not the default for “shared services at the hub.”
Operational check: define the shared-service prefixes, apply hub leak policy between the relevant service VPNs, verify spokes still cannot see unrelated departmental routes, and document rollback so the records bureau can reverse the leak without touching VPN 0.