In Rego, what does the walk built-in produce as it traverses a nested document?

## The problem `walk` solves Most Rego rules address a known path: `input.spec.containers[_].image`. That works when you know the shape of what you are handed. It stops working the moment the thing you care about can appear at a depth you did not enumerate — a manifest bundle where one document is a list wrapping other objects, a custom resource that embeds a full object under one of its fields, a template block nested inside another template block. A fixed-path rule silently finds nothing there, and finding nothing in Rego does not look like a failure. `walk` removes the need to know the depth. ## What it actually does `walk(x, [path, value])` is a *relation*: rather than returning a single result, it produces many, and the rule body is evaluated once per result. Written out: ``` some path, value walk(input, [path, value]) ``` Each evaluation binds: - `path` — an array of steps from the root of `x` down to this node. Object keys appear as strings, array indexes as integers, so a path can be mixed: `[0, "spec", "template", "metadata"]`. - `value` — the subtree at that path. It may be an object, an array, or a scalar. The traversal includes the root: the first pair you get is `[]` paired with the entire document. It also includes every intermediate container, not just leaves. So over `{"a": {"b": 1}}` you get three pairs: `[]` with the whole object, `["a"]` with `{"b": 1}`, and `["a", "b"]` with `1`. ## Filtering the stream Because you see everything, a `walk`-based rule is mostly a filter. Two habits matter: 1. **Guard the shape.** `is_object(value)` (or `is_array`, `is_string`) narrows the stream before you look at fields. Strictly this is optional — referencing a field on a scalar is *undefined* in Rego, not a type error, so the iteration just yields nothing — but the guard makes the intent readable. 2. **Let undefined do the work.** `value.apiVersion` on a node with no `apiVersion` is undefined, so that iteration produces no result and evaluation moves on to the next node. You do not need an existence check before the comparison. ## Paths are data, and that is the point The reason `walk` beats a hand-rolled recursive helper for reporting is the `path` half of the pair. A message can name exactly where the offending value lives — `"at [3, \"spec\", \"template\", \"spec\"]"` — which turns a bare "this repo has a problem" into an actionable list a team can work through. If you want a dotted string rather than an array, build one with a comprehension that converts each step with `sprintf("%v", [step])` before `concat`, because `concat` needs strings and array indexes are integers. Do not depend on the order pairs arrive in. Collect results into a set (a partial rule that `contains` messages) and `sort` them if you need stable output for a diff or a report. ## Where `walk` is the wrong reach `walk` visits every node in the document. When the path is known and fixed, a direct reference is shorter, self-documenting, and does far less work — `input.spec.containers[_].image` says what it means in a way `walk` plus three guards never will. Reserve `walk` for the case it exists for: the field can be anywhere, and you would otherwise be writing one rule per level and still missing one. One blind spot to keep in mind: `walk` descends through the *parsed* document only. If a node's value is a string that happens to contain an embedded JSON or YAML document, `walk` sees a string and stops. Decoding that string first is a separate step. ## What an interviewer is checking That you know `walk` gives you both halves — the location and the value — that the root is included, that the stream contains containers as well as leaves, and that you reach for it because the depth is unknown rather than as a default way to read input.