A team marks a ConfigMap as immutable after validating its data. What is the primary operational effect?
Select an answer to reveal the explanation.
Short Explanation
Immutable means the ConfigMap is freeze-dried — no more in-place edits. Need a change? Ship a new object and point the workload at it. That lock prevents casual overwrites of known-good config.
Full Explanation
Marking a ConfigMap as immutable after validating its data primarily means subsequent data updates are rejected; intentional changes require creating a new ConfigMap and typically rolling consumers to the new object name. Immutability protects municipal configuration from accidental edits and is useful for widely mounted settings that should not drift. It does not relocate readability into kube-system or convert the object into a Secret.
Claiming the ConfigMap becomes readable only from kube-system and cannot be mounted elsewhere fails—immutability concerns data change rejection, not a namespace lockdown. Claiming immutability converts the ConfigMap into a Secret and encrypts it at rest automatically confuses object types with encryption-provider configuration. Claiming Kubernetes deletes the ConfigMap after one hour unless a Pod mounts it invents a TTL behavior immutability does not provide.
Exam caveat: plan blue/green ConfigMap names for changes because data map updates will be rejected once immutable is set. Operational check: set immutable true, attempt a data patch and confirm rejection, create ConfigMap v2 with new data, point the Deployment at v2, and roll out cleanly. In CKAD scenarios involving q199, prefer verifying the live object with kubectl get and describe before changing cluster-wide settings.