A Kustomize patch is meant to update a Deployment named inspections-api, but the patch target lists the wrong kind or name and the change never appears in the build. What is the most likely cause?
Select an answer to reveal the explanation.
Short Explanation
If the sticky note has the wrong locker number, it never sticks to the right form. Patch targets must match kind and name (and other selectors)—a mismatch means your edit never lands.
Full Explanation
If a Kustomize patch is meant to update Deployment inspections-api but the change never appears in the build, the most likely cause is that the patch target selector does not match the intended resource’s kind and name (and apiVersion/group as required), so the patch does not apply. Silent no-ops from mismatched targets are a classic municipal overlay debugging issue when names gain prefixes or kinds are mistyped.
Why the other options fail by concept: Kubernetes does not silently disable all patches when a cluster has more than one namespace. commonLabels do not always override and erase every strategic merge patch. kubectl apply -k does not require .ini extensions for patches.
Exam caveat: namePrefix/nameSuffix in the same overlay can change the name the target must match depending on ordering—know whether targets see original or transformed names for your Kustomize version. JSON6902 patches fail differently than strategic merge; read build error output carefully. Always verify with kubectl kustomize, not only apply.
Operational check: Print the build, confirm the Deployment’s actual name/kind, fix the patch target to match, re-run kubectl kustomize | grep -A20 inspections, and only then apply. Add a CI check that greps for the patched field so mismatches fail the pipeline.