A bundled Helm subchart still renders even though you set enabled: false. Where must that value actually live?

### The failure Someone adds `enabled: false`, runs the upgrade, and the bundled component is still there. No error, no warning they noticed, nothing in the output that points at the switch. This is the most common Helm dependency question asked in interviews precisely because the failure is silent: an unresolvable condition path is skipped, and a skipped condition leaves the dependency in its default state, which is enabled. ### Where the lookup happens Before rendering, Helm assembles the values for the release - the parent chart's `values.yaml`, then every `-f`/`--values` file, then `--set` and friends - and evaluates each dependency's `condition` against that single tree, addressed from its root. Everything else is somewhere the lookup does not reach. **Case 1: inside the subchart's own values.yaml.** Editing the vendored chart under `charts/` to say `enabled: false` is the classic mistake. That file supplies defaults for the subchart's own templates; it is not where the parent's dependency switch is read from. It also gets overwritten by the next `helm dependency update`. **Case 2: the wrong key, usually an alias.** When a dependency is declared with `alias: billing-db`, the values namespace that copy reads is `billing-db`, and a chart author will normally point the condition at `billing-db.enabled`. Set `postgresql.enabled: false` instead and you have set a key nothing consults. The rule is simple: the only path that matters is the exact string in the `condition` field of that entry. **Case 3: a grandchild.** In an umbrella chart, a middle chart may itself declare an optional dependency. The values for the whole release are one tree rooted at the top-level chart, so the switch has to be addressed the whole way down: `billing.db.enabled`, not `db.enabled`. Passing the short path from the top leaves it unresolved. **Case 4: types and quoting.** `--set db.enabled="false"` and a quoted `"false"` in YAML are strings. A condition only acts on a real boolean, so a string is ignored - with a warning, which is easy to miss in a busy upgrade log. ### Confirming it, without guessing Rendering locally is the whole answer. Run the chart through the template renderer with the identical values files and `--set` flags and look at what comes out; if the subchart's objects are still there, the switch did not take effect and you can iterate in seconds rather than per deploy. Two more things help: - read the entry in `Chart.yaml` and copy the condition string verbatim - do not infer it from the chart's name; - for a release that already exists, ask Helm what values it was actually given, which distinguishes "my file is wrong" from "my file never reached the release". A rendered diff between the current values and the proposed ones is the fastest way to see both that the subchart disappears and that nothing else moved. ### Why Helm behaves this way The silence is deliberate, not an oversight. A condition may name several paths, and most of them are expected to be missing - that is how a chart offers a specific key with a shared fallback. A missing path therefore cannot be an error; it just means "no opinion here, try the next one". The cost of that design is exactly the failure above, and the mitigation is on the author's side: name the switch clearly, give it a default in the parent's `values.yaml` so it appears in the file everyone reads, and document it. A chart whose optional components are only discoverable by reading `Chart.yaml` is a chart whose consumers will file this bug. ### The neighbouring confusion One more distinction is worth stating plainly, because it produces the same symptom. Setting a value that the subchart's *templates* read - a replica count, an image tag - has nothing to do with enablement; it configures a subchart that is rendering. Enablement is decided before rendering starts, from the condition path alone. Two different mechanisms, one values file, and mixing them up is why people report that "values do not work" when the truth is that one specific path was never set.