In Rego, when does object.get beat a direct lookup of a field that may be missing?

## Undefined is not false This is the single idea the question is testing. Rego has three outcomes for an expression, not two: true, false, and **undefined**. A reference into a key that does not exist — `input.metadata.labels.owner` on an object whose `metadata` has no `labels` — is undefined. It is not an error, it does not throw, and it does not evaluate to false. It simply stops that rule body: the remaining expressions are never reached and the rule produces no result. The consequence is the trap. Consider a rule meant to catch objects with no owner label: ``` unowned if { input.metadata.labels.owner == "" } ``` On an object with `labels: {owner: ""}` it works. On an object with no `labels` key at all — the worst case, the one with the least metadata, the one you most wanted to catch — the reference is undefined, the body dies at line one, and the rule quietly yields nothing. Whatever consumes that rule's result sees an absence, and an absence reads exactly like a clean pass. ## What `object.get` does `object.get(object, key, default)` returns the value at `key` if it is present, and `default` if it is not. The key may be a single key, or an array of keys treated as a path into nested objects. So: ``` object.get(input, ["metadata", "labels", "owner"], "") == "" ``` now evaluates on both shapes. When the path exists, you compare the real value. When any step of the path is missing, `""` is substituted, the comparison runs, and the rule reaches a verdict instead of evaporating. That is the whole benefit: **the body keeps evaluating**. Choose the default deliberately. It should be a value that makes the comparison come out the way you want for the missing case, and it should not collide with a legitimate value. If `""` is a real value someone might set, use a sentinel that cannot occur, or restructure the check. ## The alternatives, and when each is right - **`object.get` with a default** — the field is optional and you want to treat absence as a specific value. This is the workhorse. - **Explicit `not`** — `not input.metadata.labels.owner` succeeds precisely when the reference is undefined. When "the field is missing" *is* the finding, this states it directly and needs no sentinel. Note the subtlety: `not` also succeeds when the value is present but `false`, so it is a poor choice for boolean fields. - **A default rule** — `default owner := "unknown"` gives a complete rule a value when its body is undefined. It defaults *your rule*, not a lookup inside someone else's document, so it does not help with an optional input field directly, but it is how you stop a helper rule from propagating undefinedness to every caller. - **A membership test first** — `"owner" in object.keys(input.metadata.labels)` reads clearly when you want to branch on presence, though it still needs `labels` itself to exist. ## How this bites in practice Optional fields are the norm in the documents policy engines read. Labels and annotations may be absent entirely. Nested spec sections appear only when a feature is used. Resource limits are optional. Every one of those is a place where a direct reference makes a rule silently stop checking, and where the object that triggers it is the sparse, under-specified one your policy exists to catch. The defect is also invisible in the usual test: a policy author writes a fixture that has the field, sets it to a bad value, sees the rule fire, and ships. The fixture that has *no* field is the test that is missing. When you write a rule against an optional field, write the empty-object case as a test at the same time. ## What an interviewer is checking That you can say "undefined is not false" and then explain the operational consequence rather than just the slogan: a body that dies mid-way produces no result, the sparse object escapes, and nothing in the output says anything went wrong. `object.get` is the fix when you want a verdict; explicit `not` is the fix when absence is the verdict.