A Helm chart treats ConfigMaps as immutable and templates a new ConfigMap name when values change on upgrade. What side effect should the developer expect?
Select an answer to reveal the explanation.
Short Explanation
Immutable ConfigMaps are like sealed envelopes with a new barcode each rewrite—you do not erase the old seal; you issue a new envelope and point the app at it. Upgrades can leave old objects around until Pods reference the new name.
Full Explanation
When a Helm chart treats ConfigMaps as immutable and templates a new ConfigMap name when values change on upgrade, the upgrade may create new ConfigMap resources and require Pods to reference the new name so configuration actually applies. Content-hash or versioned names force a Pod template change (often via checksum annotations or updated volume references), which is how many municipal charts ensure config updates roll workloads instead of leaving mounts stale.
Why the other options fail by concept: Kubernetes does not merge all historical ConfigMap names into one object with no restart. Helm does not delete every Secret in the namespace whenever a ConfigMap name changes. Image digests in the registry are not rewritten to match ConfigMap hashes.
Exam caveat: Orphaned old ConfigMaps can accumulate if the chart does not clean them—watch namespace object growth. If the Deployment template does not reference the new name or a checksum, Pods may keep old config despite new ConfigMaps existing. Immutable ConfigMaps cannot be kubectl edited in place—name changes are intentional.
Operational check: After helm upgrade with changed values, kubectl get cm -n <ns> and note new hashed names; kubectl get deploy -o yaml and confirm volume/env references and that a rollout occurred. Exec or hit a config-exposed endpoint to verify the city app sees new settings.