A policy rule can run in audit, warn or enforce mode - what does each do, and who does it reach?
answer
- same rule, three consequences
- the decision text never changes
- who has to go looking
- report, message, rejection
- a gate cannot see what already exists
basics
~20 sAudit, warn and enforce are the same rule with different consequences: audit records the violation in a report for later review, warn returns a message to the requester but allows the change, enforce rejects the change outright.
solid answer
~50 sThe rule's logic is identical in all three; only the consequence attached at deployment time differs. Take a rule that every namespace must carry a default-deny ingress `NetworkPolicy`. In **audit** mode the engine evaluates and writes the violation to a report - nothing happens to the request, and the finding reaches a person only if someone goes and reads it. In **warn** mode the change is allowed and a message rides back to whoever made the request, so it arrives at the moment and place of the change. In **enforce** mode the request is rejected and the non-compliant namespace never exists, so there is nothing to read afterwards. The reach differs in one more way that catches people out: audit can be run as a sweep over resources that already exist, while warn and enforce only ever see a request passing through the gate.
go deeper
Be ready to name the three modes and say, in one sentence each, what happens to the request: recorded, allowed with a message, rejected. Naming the consequence precisely matters more than any vocabulary about engines.
You are expected to explain that the decision is unchanged and only the consequence is configured, and to spot that a gate mode cannot see resources that already exist while a sweep can.
Show that you pick a mode by asking who receives the output and what they are expected to do with it, and that you can say what a mode costs whom - a blocked engineer, a report reader, or nobody.
Own the argument that mode belongs in deployment configuration rather than rule text, so the organisation can change how hard a rule bites without reopening reviewed logic, and so one rule can bite differently in different parts of the estate.
## One decision, three consequences A policy rule is really two things that people habitually merge into one. There is the **decision** - does this object satisfy the rule, yes or no - and there is the **consequence** - what happens to the request because of that answer. The decision lives in the rule text. The consequence is chosen when the rule is deployed. Audit, warn and enforce are three consequences bolted onto one unchanged decision. Make it concrete with a rule you can picture: *every namespace must carry a `NetworkPolicy` that denies ingress by default*. The logic - find the namespace, look for a NetworkPolicy whose podSelector matches everything and whose ingress rules are empty, report a violation if there is none - is written once. It is the same text in every mode. ### Audit (record-only) The engine evaluates and writes the result somewhere: a report, a findings record, a log line. The request is untouched and the resource is created exactly as submitted. The output is *addressed to nobody in particular* - it reaches a human only when a human goes and looks at it. That is audit's defining property, and both its strength and its weakness. The strength: it is the only mode that can be pointed at the resources that **already exist**, because it does not need a request to evaluate. You can sweep four hundred existing namespaces and get four hundred rows. The weakness: an output with no reader is just disk usage. ### Warn The engine evaluates, the request is **allowed**, and a message is attached to the response the requester gets back. The change lands. What warn buys over audit is *proximity*: the message arrives at the moment of the change, on the response to the change, in front of whatever made it - so if a person is on the other end, the person who caused the violation learns about it while they still have the context to fix it. What warn does not buy is any guarantee that the message is read; a message is emitted, not necessarily received. ### Enforce (deny/block) The engine evaluates and the request is **rejected**. The non-compliant namespace never comes into being. Nobody reads a report about it afterwards, because there is nothing to report - the failure is delivered as an error to the actor, and the fix has to happen before the change can land at all. Enforce is the only mode that changes the state of the world; the other two describe it. ## Who each mode actually reaches | Mode | Reaches | When | | --- | --- | --- | | Audit | whoever reads the report | later, if ever | | Warn | the client that made the request | at request time | | Enforce | the actor, as a rejection | at request time, and the change does not happen | The honest summary of the third row is that enforce reaches *nobody after the fact*, because there is no violating resource left to talk about. ## The reach asymmetry that trips people up Warn and enforce are **gate** modes. They sit on a request path and can only judge what passes through them. Audit run as a sweep is a **population** mode: it looks at the resources that exist right now, regardless of when or how they got there. So switching a rule to enforce does not repair anything. Turn on blocking for the NetworkPolicy rule in a cluster with four hundred non-compliant namespaces and you have four hundred non-compliant namespaces *plus* a gate. New violations stop; old ones are frozen exactly as they were. Conversely, an audit sweep will keep reporting those four hundred forever, whether or not the gate is on, because the sweep is describing state, not requests. ## Mode is deployment configuration, not rule text Because the decision is unchanged, three things follow that are worth saying out loud in an interview: 1. **The rule's tests are identical across modes.** You test the decision - this input is a violation, that one is not. Nothing in the test suite knows or cares what happens to the request afterwards. 2. **One rule can run in different modes in different places at the same time** - recording in one scope while blocking in another - because the mode is a property of the binding, not of the logic. 3. **Changing the consequence should not be a change to reviewed logic.** If the action is baked into the rule body, every adjustment to how hard a rule bites becomes an edit to the rule itself, with a re-review, a new version and a fresh chance to break the decision. Keeping them separate is what makes the mode a dial rather than a rewrite. ## The failure mode to name The common failure is not choosing the wrong mode; it is choosing audit and then never choosing again. Audit is comfortable because it costs nobody anything today, and that is precisely why it becomes permanent. A rule sitting in audit with a growing, unread finding count is not a control - it is a report generator that gives the team the feeling of coverage without any of its effects.
- If the rule text is identical in all three modes, what actually changes when you switch modes?Only the deployment configuration that binds the rule to a scope and names the action. The decision, the inputs it reads and its test suite are untouched, which is why a mode change is a configuration change rather than a rule change - and why you should be suspicious of any design where changing the consequence forces you to edit and re-review the logic.
- Which of the three modes can tell you about a namespace created before the rule existed?Only audit, and only when it is run as a sweep over current state rather than on the request path. Warn and enforce sit on a gate: no request, no evaluation. A namespace that was created last year issues no request today, so a gate mode is structurally blind to it however strict you set it.
- Can one rule run in different modes in different scopes at once?Yes, and it is common. Because the mode lives in the binding, the same rule can block in the scopes that are already clean and merely record in the ones carrying a backlog. The decision stays identical everywhere, so findings from the recording scopes are directly comparable with the rejections from the blocking ones.
Audit is a speed camera whose photographs go in a box; warn is the roadside sign that flashes your speed as you pass; enforce is the barrier that does not lift.
saying these in an interview costs you the question
- Says the rule logic differs between audit and enforce
- Thinks enforce mode also fixes resources that already exist
- Assumes an audit report is read because it is generated
- Believes a warning prevents the change from landing
- Treats warn as simply a weaker form of blocking