A sanitation department needs a shared-services VPN (DNS, logging) reachable from multiple agency VRFs without merging those agencies into one flat table. Which MPLS L3VPN concept applies?

When a sanitation department needs shared services such as DNS and logging reachable from multiple agency VRFs without flattening those agencies into one table, MPLS L3VPN uses selective route-target import/export—controlled leaking. A shared-services VRF exports specific RTs; each agency VRF imports only those shared-service RTs (and exports its own as designed) so clients can reach the shared prefixes while agency tables remain otherwise separate. That is deliberate, policy-driven route leaking—not a merger of all civic VRFs.

Deleting all route targets so every VRF automatically installs every prefix destroys isolation and is not how shared services are offered. Placing shared services only in the global table and disabling VRF on the PE bypasses VPN separation and can expose or mis-route agency traffic outside intended VRFs. Forcing P routers to store full customer VRFs for every agency site is unnecessary for shared services and contradicts the PE-centric VRF model; P cores forward labels without customer tables.

Exam caveat: “extranet” or shared-services VPN patterns are RT policy problems; do not confuse them with VRF-Lite route leaking on a single box unless the stem says so. Operational check: identify the shared-services VRF RT exports, confirm each agency VRF imports only that RT set, verify DNS/logging prefixes appear in agency VRFs without full agency mesh routes appearing unwanted, and test resolution/logging from a CE while ensuring cross-agency routes remain absent unless explicitly imported.