A municipal payment VRF that handles PCI cardholder traffic must never reach the guest Wi-Fi VRF. Which approach best preserves strict Layer 3 isolation?
Select an answer to reveal the explanation.
Short Explanation
PCI and guest Wi-Fi should be neighbors that never share a hallway. No common routes, no shared RTs, no firewall pinholes unless compliance explicitly blesses them—and guest Wi-Fi almost never qualifies. Stuffing them together or bridging SSIDs into the payment VLAN is how audits become incident reports.
Full Explanation
A municipal payment VRF that handles PCI cardholder traffic must stay strictly isolated from guest Wi-Fi at Layer 3. The approach that preserves that isolation is to keep disjoint route targets and omit routes or firewall paths between the PCI and guest VRFs so guests never learn payment prefixes and payment never learns guest exits. Civic compliance expects that separation to be structural, not merely hopeful.
Placing both VRFs in the same routing instance and filtering with local DNS only collapses the L3 boundary into one table and treats DNS as if it were a firewall—conceptually wrong for PCI isolation. Advertising the PCI default route into guest Wi-Fi so guests use the “secure” path actually couples guests into the payment routing domain. Bridging guest SSIDs into the PCI VLAN so authentication can be centralized recreates a shared L2 domain and is the opposite of isolation.
Exam caveat: “more secure path” language is a common distractor; pulling untrusted tenants into a PCI VRF or VLAN fails both design and compliance framing.
Operational check: verify PCI and guest use separate RTs with no mutual imports, confirm no firewall pinholes or IRB bridges between them, and test that a guest client cannot install or reach PCI prefixes from its VRF.