Only the staging overlay must change a Deployment’s readinessProbe path. Which Kustomize mechanism makes that surgical edit?
Select an answer to reveal the explanation.
Short Explanation
A patch is a sticky note on one paragraph of the city form—not a rewrite of the whole binder. Overlays pin a readinessProbe tweak to the right Deployment and leave the base alone.
Full Explanation
When only the staging overlay must change a Deployment’s readinessProbe path, use a strategic merge patch or JSON patch in the overlay that targets the Deployment and readinessProbe fields. Patches provide surgical, environment-scoped edits so municipal staging can experiment with health endpoints without polluting the shared base or misusing label/name transformers as if they could rewrite probe handlers.
Why the other options fail by concept: commonLabels alone stamps labels; it cannot rewrite probe HTTP paths by implication. nameSuffix alone rewrites resource names, not probe handler configuration. helm uninstall executed from inside kustomization.yaml is not a Kustomize mechanism for editing readiness probes.
Exam caveat: Patch targets must match kind, name, and group/version correctly or the patch silently no-ops—verify with kubectl kustomize every time. Strategic merge versus JSON6902 patch syntax differs for list edits; choose the type that matches how you need to change the probe structure. Keep the production overlay free of staging-only probe experiments.
Operational check: Add a patch rewriting readinessProbe.httpGet.path in staging, run kubectl kustomize overlays/staging | grep -A8 readinessProbe, confirm the path, apply -k, then kubectl describe pod and read the live probe configuration before relying on staging traffic tests.