In each of these families the component that made the decision is not the component that reports the outcome. That is the whole reason the symptoms collapse into each other.
Injection is decided by a mutating admission webhook, before the workload exists [1]. So the evidence lives in the webhook configuration and in the injector's own deployment log, which is why the dev.to writeup's first three commands are `kubectl get mutatingwebhookconfiguration vault-agent-injector-cfg -o yaml`, `kubectl get namespace <ns> --show-labels`, and `kubectl -n vault logs deploy/vault-agent-injector-injector` [3][4]. The pod's own events stay clean throughout, so they offer no signal that the webhook actually acted [2]. And because the webhook admits pods, an annotation sitting on a Deployment's metadata is not an annotation the webhook ever sees [5].
Once the sidecar is running, the decision moves to Vault's policy engine and the agent's template renderer, and both of them report into the agent container: `kubectl logs <pod> -c vault-agent` [6]. A typo in an `agent-inject-template` annotation errors clearly there and silently from the app's side [7]. A missing `read` grant looks the same from the app, because the agent authenticates successfully and then takes a 403 on the actual secret read [8].
Authentication has a third location again. Authentication now turns on the token itself: Kubernetes 1.21 and later issue time-bound, audience-scoped service account tokens, so Vault's Kubernetes auth backend has to either validate the issuer the cluster is actually using, confirmed with `kubectl get --raw /.well-known/openid-configuration`, or carry an explicit reviewer JWT and CA cert [10]. When a working setup breaks weeks later, the writeup attributes it to that reviewer JWT having been short-lived, and the check is `vault read auth/kubernetes/config` rather than a diff of your Terraform [11]. Seal state has a fourth: `kubectl exec -it vault-0 -- vault status`, because a sealed Vault answers cleanly and a crashing one never gets that far [15].
Count the causes as listed: three for missing injection, three for the missing secret file, two for auth, two for a sealed restart. Ten candidates over four symptom families [1]. The intro names three outward errors, pod stuck in Init, 502 from the app, permission denied [16], so the mapping from what you see to what broke is not one to one [3]. The symptom only tells you which log to open, not which cause produced it.
Two details are worth separating out as copy-paste hazards rather than failures. KV v2 paths need a `data/` segment, as in `secret/data/myapp/config`, so a template lifted from a v1 setup fails without complaint [9]. And an injector's self-signed cert expiring shows up as TLS errors in the injector log, not anywhere near the pod that lost its sidecar [4].
This is one practitioner's ordering, offered as roughly the order they would check in [17], with no incidence figures attached. For that order to transfer you need the same shape: an in-cluster injector, in-cluster Vault on Raft integrated storage [12], and a cluster on 1.21 or later [10]. Under those conditions the triage ladder is four commands long, one per family, and each one is read-only.
