Clerk-VLAN devices should reach the records API but must not open lateral admin ports on neighboring systems. Which ACL intent matches that goal?
Select an answer to reveal the explanation.
Short Explanation
Think of the clerk VLAN as a hallway with a badge reader only for the records desk—not master keys to every server closet. ACL intent should allow the API and deny admin lateral moves. Any-any is the opposite of least privilege.
Full Explanation
Clerk-VLAN devices should reach the records API but must not open lateral admin ports on neighboring systems. Matching ACL intent allows records API access (destination/service specific) from the clerk VLAN while denying lateral administrative protocols such as unrestricted RDP, SMB admin shares, SSH to arbitrary hosts, or management ports on neighboring servers. That is least privilege at the network layer for municipal records workflows.
Permitting any any between the clerk VLAN and the entire data center collapses segmentation and enables ransomware-style lateral movement after a single clerk workstation compromise. Blocking the records API while allowing unrestricted RDP inverts business need and security need simultaneously. Removing all ACLs so troubleshooting never hits a deny rule recreates a flat network and abandons documented intent.
Exam caveat: “allow API, deny lateral admin” still requires precise objects—API VIP/port, clerk source subnets, and explicit deny or default-deny with limited permits. Logging denies helps operations without opening ports. Temporary any-any for troubleshooting must be time-boxed and ticketed; exam answers that normalize any-any are wrong even when they sound convenient.
Operational check: from a clerk-VLAN test host, verify the records API succeeds on the approved port; verify RDP/SSH/admin ports to a neighboring system are denied and logged; review the ACL counter hits after a simulated scan; and ensure change control captures the ACL as code in the network IaC repo.