County jail needs a shared printer reachable from two VRFs and plans a carefully controlled inter-VRF route exchange. How does that differ from an accidental leak?
Select an answer to reveal the explanation.
Short Explanation
A controlled leak is handing the jail and admin VRFs a photocopied page for the printer subnet only. An accidental leak is dropping the whole binder on the floor so every route spills across. Same mechanism family, very different intent and blast radius.
Full Explanation
When a county jail needs a shared printer reachable from two VRFs, carefully controlled inter-VRF route exchange differs from an accidental leak by intent and scope. Controlled inter-VRF communication intentionally imports only the required prefixes—such as the printer—whereas an accidental leak exposes unintended routes between VRFs and weakens isolation. Both may make a prefix visible in more than one table; only the controlled case is designed, limited, and audited for the jail's shared-service need. Accidental leaks do not encrypt traffic while controlled leaks disable CEF—that pairs unrelated myths and ignores routing policy. Controlled inter-VRF does not always require VXLAN while accidental leaks use only GRE; leaking is a VRF import/export or redistribution behavior independent of those encapsulations. Claiming there is no difference because any route visible in two VRFs is equally intentional by definition erases the operational distinction ENCOR expects between scoped design and misconfiguration. Exam caveat: even intentional printer leaks should be least-privilege—importing entire VRFs when only one host is needed recreates accidental-leak blast radius under a friendly name. Operational check: leak only the printer prefix between the jail VRFs, verify each VRF can reach that host, confirm no other foreign prefixes appear, and review the change against a documented shared-services allow list.