In a Helm chart, how can a wrong `nindent` depth render valid YAML and still produce the wrong object?

## Layout is parentage In a rendered chart the only thing establishing which map a key belongs to is its column. That is the mechanism `nindent` is manipulating, and it is why the number matters more than it looks. A parse error is the friendly outcome: it stops the release. The unfriendly outcome is a document that is entirely valid and describes an object you did not intend. ## The shape of the silent failure Take a chart wrapping a vendor image for a geospatial tile server, rolled out across a 12-namespace fleet, whose pod template splices annotations: ```yaml metadata: labels: app: tile-server annotations: {{- toYaml .Values.podAnnotations | nindent 8 }} ``` Eight is correct here: the emitted keys must sit deeper than `annotations:` at six. Write six instead and the render becomes: ```yaml metadata: labels: app: tile-server annotations: prometheus.io/scrape: "true" ``` That is valid YAML. `annotations:` now has nothing beneath it and holds an empty value, and the annotation key has become a sibling of `labels` and `annotations` inside the pod template's metadata. Helm renders it, the parser accepts it, and the manifest is submitted. From there, the outcome depends entirely on where the keys landed. If they land in a map that accepts arbitrary keys — an annotations or labels map, or the data of a config object — nothing at any layer objects, and the only symptom is that the setting has no effect: nothing scrapes the tile server, in all twelve namespaces, and there is no error anywhere to search for. If they land at a position with a fixed schema, as in the example above, you have a field the API does not recognise, which is either rejected outright or ignored depending on how the request is validated. Rejection is by far the better day, because at least it names something. ## Why some depth mistakes are harmless It is worth knowing the two rules that let sloppy depths survive, because they explain why charts full of inconsistent `nindent` numbers still work. The first is that a nested block only has to be deeper than the key it belongs to, and consistent within itself. Indenting a map ten columns under a key that needed eight changes nothing about the object; the extra depth carries no meaning. Over-indenting is almost always safe. The second is that a block sequence may be written at the same column as the key that owns it. A list of items whose dashes line up with `tolerations:` belongs to `tolerations:` just as much as one indented two further. So a list splice that is two columns short frequently produces exactly the right object, which is why the same mistake bites on maps and not on lists. Put together: too deep is usually fine, too shallow is where the danger lives, and lists forgive more than maps do. ## Finding it The defect is invisible in the template, because the template shows an action and a number, not a tree. It is invisible in a text diff of two renders too, if you are skimming for changed values rather than changed columns. What exposes it is reading the rendered document as a structure and asking which parent each key ended up under — or, more practically, checking the field on the object you meant to configure rather than on the manifest you meant to write. The question `is the annotation on the pod?` is answerable; the question `does this template look right?` is not. ## Preventing it The cheap guard is to make the splice's depth follow one rule everywhere: a leading trim marker, the newline-emitting indent function, and a number equal to the parent key's rendered column plus two. Charts that write splices this way have exactly one thing to check in review. The more durable guard is an assertion in CI over the rendered output for each environment — asserting that a named field exists at a named path, not merely that the chart renders. A chart that only ever proves it parses will keep letting this class of defect through, and it reaches a cluster looking completely healthy. ## Why this is worth an interview minute The instinct being probed is a general one: a document that parses has satisfied a syntax check, not a semantic one. Candidates who have only ever debugged parse failures tend to treat a successful render as proof of correctness, and this is the failure that teaches otherwise.