What do Gatekeeper's enforcementAction values deny, dryrun and warn each do to a request?

## The three values, and who each one reaches Every Gatekeeper Constraint carries `spec.enforcementAction`. It takes one of three values, and the distinction interviewers care about is not "strict versus lenient" — it is **who learns about the violation, and when**. ### deny (the default) Omit the field and you get `deny`. The admission request is rejected. The API server returns the rejection to the client, carrying the violation message the rule produced, so the person running `kubectl apply` — or the controller reconciling on their behalf — sees the reason inline and the object never exists. The consequence worth stating out loud: the audience for a `deny` is whoever or whatever submitted the request. If the submitter is a human at a terminal, the message is read. If it is a GitOps controller reconciling a repository, the message lands in that controller's logs or sync status and a person only sees it if they are looking there — which is why the wording of the violation message matters as much as the decision. ### dryrun The request is admitted. The rule is still evaluated, and violations are still recorded — Gatekeeper's periodic audit walks live objects and writes what it finds onto the Constraint's own `status`. But nothing is surfaced at request time at all. The applier gets an ordinary success and has no idea a rule disagreed. So `dryrun` produces a list you have to go and read. It answers the question "if I turned this on, how much would break, and where?" and it answers it after the fact, on the Constraint object, for whoever thinks to look. ### warn The request is also admitted — `warn` blocks nothing. The difference from `dryrun` is that Gatekeeper returns a warning on the admission response, and the API server relays warnings to the client, so `kubectl` prints the message right under the applier's output. The author of the change sees the exact violation text, at the moment they made the change, and is still allowed to proceed. That makes `warn` the only one of the three that reaches the person who can most cheaply fix the problem without stopping them. It is also the value most often misremembered: candidates describe it as "a soft block" or "blocks after a grace period", and it is neither — the object is admitted, unmodified, every time. ### A comparison that fits on one line each | value | request outcome | who sees it, and when | |---|---|---| | `deny` | rejected | the applier, immediately, with the message | | `dryrun` | admitted | whoever reads the Constraint's status later | | `warn` | admitted | the applier, immediately, as a warning | ### Mechanical details that come up as follow-ups **It is per Constraint.** Two Constraints generated from the same ConstraintTemplate can carry different values, because the field lives on the instance. The template has no say in it. **Audit does not care.** Gatekeeper's audit evaluates live objects against Constraints and reports on their status regardless of the enforcement action, so a `deny` Constraint still tells you about objects that were created before it existed — admission only ever sees requests, never the resources already sitting in the cluster. **A warning is not a mutation.** `warn` does not fix, default or annotate anything. The object is stored exactly as submitted. **The message is the product.** Under `warn` and `deny` alike, the only thing the applier receives is the violation text. "Denied by policy" wastes the one channel you have; naming the field, the offending value and what an acceptable value looks like is what makes the action useful. ### The common wrong answers - "`dryrun` logs a warning to the user" — no, that is `warn`; `dryrun` surfaces nothing at request time. - "`warn` blocks unless you add an annotation" — no, `warn` always admits. - "The default is `dryrun`, so it is safe to apply a Constraint and see what happens" — the default is `deny`. Applying a Constraint without setting the field turns on blocking.