In Rego, how do you require that every container in a list has CPU and memory limits?

"All elements satisfy X" is the assertion a resource-limits gate actually needs, and it is the one thing Rego's default iteration does not give you. There are two correct spellings and one that does not compile. ## 1. The `every` keyword ``` every c in input.spec.template.spec.containers { c.resources.limits.cpu c.resources.limits.memory } ``` `every x in collection { body }` is defined and true when the body succeeds for every element, and fails when any element makes the body fail or leaves it undefined. The key-and-value form `every k, v in obj { ... }` is available for objects. Inside the braces you write ordinary body expressions — a bare reference such as `c.resources.limits.cpu` succeeds if that path exists and its value is not `false`, which is the idiomatic way to say "this field is present". ## 2. Negate a counterexample Before `every` existed this was the only way, and it is still worth knowing because it is how `every` behaves underneath and because the helper it forces you to write is often useful on its own: ``` unlimited contains c.name if { some c in input.spec.template.spec.containers not c.resources.limits } allow if { count(unlimited) == 0 } ``` The helper uses existential iteration to find offenders; the caller asserts there are none. Note that the set-valued helper is always defined (possibly empty), so `count(...) == 0` is safe, whereas `not unlimited` would be testing a set that is empty-but-defined and would therefore fail. ## 3. The version that does not compile ``` allow if { not input.spec.template.spec.containers[c].resources.limits } ``` OPA rejects this: `var c is unsafe`. Safety in Rego requires every variable in a rule to be bound by a **non-negated** expression somewhere in the body. `not` does not produce bindings — it succeeds when its inner expression is undefined or false, and there is nothing to bind in that case. This is not a linter opinion; the rule would be meaningless without it, because there is no set of bindings to enumerate. The same error appears when a variable occurs only in the rule head, or only inside a `not` over a comprehension. ## The two edge cases that decide whether the gate is real **Empty collection.** `every c in [] { ... }` is **true** — vacuous truth, the same convention as "for all" in logic. A template that renders a workload with an empty container list therefore passes an all-containers check. **Missing collection.** If the reference to the collection is itself undefined — for example the pod spec has no `initContainers` field at all — then the `every` expression is undefined, and a body containing it does not succeed. Whether that reads as pass or fail depends entirely on which side of the rule it sits: in an `allow` rule the allow simply does not fire; in a deny rule written as "deny if not every ..." the deny does fire, which is a very different outcome from the empty-list case. So an honest all-containers rule usually pairs the quantifier with an existence check on the list, and treats regular, init and ephemeral container lists deliberately rather than assuming all three are present. ## Choosing between the two forms `every` reads better and keeps the assertion local, so it is the default for a single check. The counterexample helper wins when you need the **names** of the offenders — for a message, a report, or a payload — because `every` tells you only that something failed, not which element. In practice a mature rule set often has both: a helper set that collects offenders, used for the message, and no `every` at all, since `count(offenders) == 0` already says "all of them are fine" and carries the detail with it. ## What an interviewer is listening for That you know iteration is existential and needs an explicit quantifier; that `not` cannot bind, so the negated form needs a helper; and that vacuous truth on an empty list is a real gap in a gate rather than a language trivia point.