In a zero-trust design discussion, which pairing correctly places the policy decision and the policy enforcement roles?

SY0-701 zero-trust framing distinguishes control-plane decision functions from data-plane enforcement. A policy engine—or policy decision point—evaluates identity, context, and rules to decide whether access should be allowed. A policy enforcement point applies that decision on the data path by allowing, denying, or limiting the session. Correct pairing keeps decision logic separate from the choke point that actually blocks or passes traffic and API calls.

Saying a honeypot decides access while a badge reader encrypts packets on the data path mixes deception technology and physical access gear into roles they do not fill in the zero-trust control/data-plane model. Accounting logs that record activity support accountability but do not replace either the policy engine or the enforcement point. Physical bollards manage vehicle approach at a courthouse or campus; they are not the sole required policy decision point for logical access in a zero-trust architecture discussion.

Exam caveat: you need conceptual depth on PDP/PEP (policy decision versus enforcement), not niche ZTNA product screenshots. Municipal designs still use the same split whether access is to cloud apps, VPN replacements, or internal APIs.

Operational check: when architects discuss county zero trust, identify what component evaluates policy (identity provider plus policy engine, risk engine, or similar) and what component enforces on the path (gateway, agent, firewall, API proxy). Ensure decisions are logged, cached carefully, and fail closed for sensitive civic systems when the decision service is unreachable if that matches risk appetite.