What happens to a chart's helm.sh/hook manifests when a controller applies helm template output?

## What a hook actually is A hook is an ordinary manifest with an annotation on it. `helm.sh/hook` names the event, `helm.sh/hook-weight` gives a sort key within an event, and `helm.sh/hook-delete-policy` says when Helm may delete the object afterwards. Nothing in a Kubernetes cluster understands any of those strings. They are read by Helm's installer, which pulls those documents out of the render, applies them at the right moment, waits for them, and then applies or deletes according to the policy. Remove the installer and you remove the only reader. ## Rendered, not removed The first surprise is that hooks do not vanish from the output. `helm template` prints hook-annotated documents in the same stream as everything else - `--no-hooks` is the flag that omits them. So a controller that applies the render creates the hook objects as plain resources, in whatever order its applier happens to use, at the same time as the workloads. For a telemetry ingest gateway whose chart carries a `pre-upgrade` schema-migration Job, the concrete consequence is that the migration Job and the new gateway pods are created together. The pods start against the old schema, crash-loop or, worse, write records the new code assumes are already converted, until the Job finishes. Nothing failed; the ordering guarantee simply was not there to begin with. ## Delete policies and fixed names The second surprise arrives on the following release. Under Helm, `helm.sh/hook-delete-policy: before-hook-creation` means Helm removes the previous Job before creating the new one, which is what lets a hook keep a stable, predictable name across releases. Under render-and-apply nothing deletes it, so the Job with that name is already there. Re-applying an unchanged document changes nothing and the migration does not re-run. Re-applying one whose pod template changed - a new migration image tag, say - is rejected, because a Job's pod template cannot be edited in place. The pipeline reports a failure on a resource nobody thinks of as a resource. The usual escape is a name that changes when the work changes. Note that `.Release.Revision` is not available for this: an offline render always produces the first-install value, so a Job named after the revision has the same name forever. Use the image tag, `.Chart.Version` or `.Chart.AppVersion` instead - all of which move when you actually ship something new. ## Test hooks Manifests annotated `helm.sh/hook: test` are meant to be created on demand by `helm test` against a running release and then reaped. In a rendered pipeline they are simply part of the manifest set: a Pod that gets created on every apply, runs its assertions against whatever is live at that instant, and then sits in the namespace as a completed or failed Pod that nothing cleans up. And `helm test` itself is unavailable, because it looks up a release record that was never written. Teams usually pass `--no-hooks` at render time to keep test manifests out of the stream entirely, then run the same assertions as a job in the delivery system. ## Events that can never occur Some events have no counterpart at all in a render-and-apply model. `post-delete` and `pre-delete` presuppose an uninstall, and nothing uninstalls a set of applied YAML documents in Helm's sense. If your chart cleans up an external resource - deregistering the gateway from an upstream collector, say - that cleanup silently stops happening the day you switch delivery models, and nobody notices until the external system fills up with stale registrations. ## Designing for the model you are actually in There are three defensible positions. Keep Helm as the installer, and the hooks keep working. Or accept the rendered model and stop using hooks: pass `--no-hooks` so the manifests do not leak into the stream at all, make any setup work idempotent so it is safe to apply repeatedly, and express ordering with whatever primitive the applying system offers rather than with annotations it does not read. Or move the work out of the chart entirely, into a pipeline step that runs before the apply, where its ordering, its logs and its failure handling are all visible in one place. The answer an interviewer is listening for is that hook annotations are not a property of the manifests, they are a contract with Helm's install path - and that changing who applies the YAML silently voids that contract without producing a single error message.