Why can a Kyverno policy pass a local kyverno apply run yet decide differently in the cluster?

## The two inputs are not the same object It is tempting to think of `kyverno apply` as "admission, run early". It is not. It is the same rule engine pointed at a different input, and almost every surprise comes from the difference between those inputs. ### Gap 1 — defaulting and mutation change the object When a manifest is submitted, the API server applies defaults for fields you left out, and **mutating admission runs before validating admission** — that ordering is fixed by the API server's request pipeline. So a validating rule in a cluster sees an object that has already been filled in and possibly rewritten, by the API server's own defaulting, by Kyverno's `mutate` rules, and by anybody else's mutating webhooks. The CLI, given a file, sees the file. It will apply `mutate` rules from the policies you handed it, which is useful, but it knows nothing about defaults or about the other webhooks installed in your cluster. This cuts both ways. A rule that requires a field the API server would have defaulted in fails locally and passes in the cluster. A rule that forbids a value that a mutating webhook injects passes locally and fails in the cluster. ### Gap 2 — there is no API server to look things up in Kyverno rules can declare a `context`: a ConfigMap to read, an API call to make, image metadata to fetch. In the cluster those resolve against the live API. Offline there is nothing to resolve against. What you get is usually one of two failure shapes. Either the rule reports **error** because a variable it needs is unresolved, or — worse — a precondition that depends on the lookup evaluates to something you did not intend and the rule quietly **skips**, which reads as "no problem found" if you are only scanning the summary line. The remedy is the values file. It supplies concrete values for the variables the rules reference, labels for the namespaces the rules select on, and stand-ins for the results of context lookups, plus global values shared across policies: ``` kyverno apply policy.yaml --resource deploy.yaml --values-file values.yaml ``` Keeping that file in the repository next to the policy is the practice worth stating in an interview: it is the documented statement of what the rule assumes about the world, and it is reviewable. ### Gap 3 — there is no request Admission gives a rule things that only exist because somebody asked for something: which operation it is (CREATE or UPDATE), who asked (`request.userInfo` — the username and the groups), and on an update the **old object** alongside the new one. A file on disk has none of that. An update-only rule — one that fires when a particular field *changes* — cannot be exercised at all without supplying both versions, and a rule keyed on the requesting identity needs that identity supplied by hand through a user-info file. This gap is worth remembering for a second reason: it is the same gap that stops such rules running in a **background scan**. A scan reads a stored object; there is no request behind it, so the requesting user and the operation are unavailable there too. A rule that depends on them can only ever decide at admission. ## Diagnosing a real mismatch When CI is green and admission rejects the same change, work the gaps in order: 1. Fetch what the cluster actually holds or what the request carried, and diff it against the file. If the offending value is not in your YAML, it came from defaulting or from a mutation, and you are in gap 1. 2. Read the rule for a `context` block or a variable that resolves against cluster state. If there is one, you are in gap 2, and your values file is stubbing something that does not match reality. 3. Check whether the rule reads the operation, the user, or the old object. If it does, gap 3, and the local run never exercised that path. ## The trap in the fix The cheap fix for a red local run is to add another stub to the values file until it goes green. Sometimes that is right — the stub is describing the world honestly. Often it is a signal about the rule itself: a validating rule that only reaches the correct verdict when three cluster lookups line up is a rule that is hard to reason about, hard to test and fragile in production, because each lookup is a way for the decision to change without the policy changing. Where the same guardrail can be expressed against the object alone, that version is both testable offline and stable in the cluster. Stubs are for the assumptions you genuinely need, not a way to make an awkward rule look tested.