What do PDP, PEP and PIP each do in a policy-as-code gate?
answer
- one decides, one acts, one supplies facts
- which of the three has hands
- the answer is only a message
- facts the change does not carry
- roles, not necessarily three services
basics
~20 sA policy decision point evaluates the rule and returns an answer. A policy enforcement point sits in the change's path, gathers the input, asks, and acts on the reply. A policy information point supplies facts the change itself does not carry.
solid answer
~50 sThey are three jobs, not three products. The policy decision point (PDP) is the evaluator: hand it an input document and it returns a decision. The policy enforcement point (PEP) is the only part with hands — it sits in the path of the change, assembles the input, calls the decider, and acts on what comes back. The policy information point (PIP) is whatever supplies facts the change under evaluation does not include. Concretely: a deploy tool is about to create a load-balancer listener; the org rule is that no listener may accept anything below TLS 1.2. The deploy tool's guard is the PEP, the shared decision service is the PDP, and a certificate and protocol inventory queried for facts about the certificate being attached is the PIP. One process can play all three roles; splitting them is what lets you say which one failed.
go deeper
Be ready to name the three roles and, in one sentence each, say what they do — decide, enforce, supply facts. The single fact to nail is that only the enforcement point can actually stop a change.
Expect to map the roles onto a real gate you have worked on: which code was in the path of the action, what it sent, and where any extra facts came from. Explain why one process can play all three.
An interviewer expects you to use the split as a diagnostic tool: given non-compliant resources in production, say which role you would examine first and what evidence would clear each one.
Own the ownership question. Rules, enforcers and fact sources are usually owned by different teams, and the seams between them are where guardrails quietly stop working. Be ready to say who is accountable for each.
## Three jobs hiding inside one box People usually draw a policy gate as a single box labelled `the policy engine`. It is really three distinct jobs, and the vocabulary for them is borrowed from access-control architecture, where the same split has been standard for decades. Use one concrete guardrail throughout: **no managed load-balancer listener may accept anything below TLS 1.2.** A deploy tool is about to create such a listener. ### PDP — policy decision point The evaluator. It takes an input document (here: the proposed listener — its protocol setting, the certificate reference, the account and environment it lands in) and returns a decision. In this example it is a shared HTTP decision service that several deploy tools call. The defining property of the PDP is that **it has no hands**. It cannot create the listener, refuse to create it, or roll it back. It answers and stops. Everything it produces is a message. ### PEP — policy enforcement point The part in the path of the action. Here it is the guard inside the deploy tool, on the code path that creates listeners. Its duties are three: 1. **Gather** the input — the proposed listener configuration, plus enough surrounding context for the rule to be meaningful. 2. **Ask** the PDP. 3. **Apply** the answer — do not create the listener when the answer is no; apply a corrected value when the answer comes back with one. A PEP is the only role that can change what actually happens. If the decision service says `deny` and the deploy tool creates the listener anyway, the guardrail did not exist that day, no matter how good the rule was. ### PIP — policy information point The source of facts the change under evaluation does not carry. The create call knows which certificate is being attached; it does not know whether that certificate's issuing policy permits older protocol versions, or whether the certificate is on the approved list. Something has to supply that — a certificate and protocol inventory, an internal API, an exported dataset. That something is playing the PIP role. PIP facts are external state, so they carry failure modes the rule does not: they can be stale, partially populated, or unavailable. `The rule is wrong` and `the facts we fed it were a week old` are different bugs with different owners. ### The asymmetries worth remembering - **Only the PEP can stop anything.** A denial is inert until a caller refuses to proceed on it. - **The PEP owns the input.** A decision is only as good as what was gathered; a rule that never sees the protocol field cannot enforce a protocol floor. - **A PIP is a role, not a database.** It can be an HTTP API, a file the enforcer reads, or a control-plane query. What makes it a PIP is that it supplies facts from outside the change. - **These are roles, not deployments.** A single binary can be all three; a library linked into the deploy tool can be the PDP. The split is analytical, and its value is exactly that it lets you localise a failure. ### Why the vocabulary earns its keep It gives you three frames a team actually needs: - **Debugging.** Non-compliant listeners appeared. Was the rule wrong (PDP), was the guard skipped or its answer ignored (PEP), or were the facts stale (PIP)? - **Ownership.** A security team typically owns rules; a platform team owns the enforcers embedded in tools; whoever runs the inventory owns the facts. Three roles, three on-call rotations. - **Evidence.** Showing an auditor the rule proves nothing about enforcement. What proves enforcement is a record that the enforcer ran, on every path, and honoured what it got back. ### Common confusions Calling the rule file `the PDP` (the rule is data; the PDP is what evaluates it). Saying a PDP `blocks` a change (it cannot). Assuming the three must be three services (they need not be). Assuming every rule needs a PIP (many rules are answerable entirely from the change itself, and those are the easiest to reason about).
- Can one process be all three roles at once?Yes, and often is. A deploy tool can embed the evaluator as a library, read facts from a file it ships with, and act on the result itself — one binary, three roles. The split is analytical rather than architectural. Its value is that when non-compliant resources appear you can ask which role failed, even if all three live in the same process.
- Does every rule need a policy information point?No. A rule that only inspects the change under evaluation — is this listener's minimum protocol version at least TLS 1.2 — needs no external facts at all, and is the easier rule to reason about, test and replay. A PIP appears only when the rule depends on something the change does not carry, such as whether the attached certificate is on an approved list.
- Where does the rule itself sit in this picture?The rule is data that the decision point evaluates, not a fourth role. That separation is the point of the model: the same rule can be evaluated by a decision point embedded in a tool, or by a shared service, without rewriting it, and the enforcers calling it do not need to understand its language.
A bouncer, a rulebook lawyer on the phone, and a guest list. The lawyer says no; the guest list says who is expected; only the bouncer can keep anyone out of the room.
saying these in an interview costs you the question
- Says the decision point blocks the change
- Calls the rule file the PDP
- Assumes the three roles must be three separate services
- Thinks every rule needs an external facts source
- Cannot say which role can actually stop a deploy