In a Kyverno mutate rule, what does the +() add-if-not-present anchor do?

## What a mutate rule is doing Kyverno is a Kubernetes policy engine whose rules run as admission plugins: when someone submits a Pod, Deployment or PersistentVolumeClaim, Kyverno sees the object before it is persisted. A `validate` rule answers yes or no. A **`mutate` rule rewrites the object** — the thing stored in etcd is not quite the thing the author submitted. The most common way to express that rewrite is `mutate.patchStrategicMerge`, which is a *partial object*: you write the shape of the fields you care about and Kyverno merges it into the incoming object. Nothing you leave out is touched. ## Plain key versus anchor A plain key in a strategic-merge patch is an assignment. ``` spec: automountServiceAccountToken: false ``` This sets the field to `false` on every matching Pod, including the one whose author deliberately wrote `true` because their workload calls the API server. The team's value disappears, and unless someone reads the mutation record on the object, nobody notices until the pod fails. Wrapping the key in `+()` changes the semantics to **add if not present**: ``` spec: +(automountServiceAccountToken): false ``` Now the patch applies only where the field is absent. A Pod that already says `true` keeps `true`; a Pod that says `false` keeps `false`; a Pod that says nothing gets `false`. This is the correct spelling of a *default*. ## The anchor is not the match block Anchors are a feature of the patch (and, in validate rules, of the pattern) — they are not selectors. Deciding *which* objects a rule applies to is the job of `match` and `exclude`. Deciding *what happens to a particular field within* an object that already matched is the job of the anchor. Candidates who put the anchor logic in `match` end up with a rule that skips whole objects when they only meant to skip one field. ## The other anchor you will be asked to distinguish The conditional anchor `()` writes nothing. It says: if the value at this key matches what I wrote, apply the sibling keys in this map; otherwise skip this subtree. It is how you express "for containers whose name is X, set Y", and inside lists it is also how you address elements at all — for example a `(name): "*"` conditional anchor inside the containers list applies the sibling keys to every container. Confusing `()` with `+()` is the classic mix-up: one is a guard, the other is a write that yields to an existing value. ## Why interviewers care The `+()` anchor is where a policy team's posture becomes visible in one character. `+(...)` says "I am filling a gap you left". A plain key says "I am overriding you". Both are legitimate — a security baseline sometimes must win — but they have very different consequences for the workload owner who later diffs the running object against the manifest in their repository and finds a field they never typed. If you take the overwrite path, you owe that owner an obvious trail: Kyverno records what it changed in the `policies.kyverno.io/last-applied-patches` annotation on the mutated object, and emits events and policy report entries naming the policy and rule. ## Practical notes - `+()` composes with nesting: you can anchor a leaf several levels down, and the parent path is created if the merge needs it. - A default expressed with `+()` is stable if the same rule sees the object again — it has nothing to add the second time. - Setting a boolean to `false` with `+()` is a common source of confusion because `false` looks like "unset"; it is not. An absent field and an explicit `false` are different states, and only the absent one is patched. - If you find yourself wanting `+()` *and* a hard guarantee that the value is `false`, you want two rules: a mutate that defaults it and a validate that rejects an explicit `true`. Mutation alone is never a guarantee, because the author can always set the value themselves.