What happens when you set a Kubernetes ConfigMap as 'immutable'?

What happens when you set a Kubernetes ConfigMap as 'immutable'?

• A. It can't be changed once set
• B. It becomes a Secret automatically
• C. It is deleted when the namespace is deleted
• D. It is copied to every node

Answer: (A)

Immutability makes a ConfigMap read-only once it’s created. With this setting, the data in the ConfigMap cannot be updated; any attempt to change it via the API will be rejected. If you need to apply a new configuration, you create a new ConfigMap (typically with a different name) and then update the workloads to refer to that new ConfigMap, often triggering a rollout so the new data is mounted. This provides stability for critical configuration because accidental or unintended edits won’t affect the running system. It doesn’t automatically convert to a Secret, it isn’t deleted just because the namespace is deleted, and it isn’t copied to every node by virtue of being immutable. If you try to modify an immutable ConfigMap, the API server will reject the update.

Immutability makes a ConfigMap read-only once it’s created. With this setting, the data in the ConfigMap cannot be updated; any attempt to change it via the API will be rejected. If you need to apply a new configuration, you create a new ConfigMap (typically with a different name) and then update the workloads to refer to that new ConfigMap, often triggering a rollout so the new data is mounted. This provides stability for critical configuration because accidental or unintended edits won’t affect the running system. It doesn’t automatically convert to a Secret, it isn’t deleted just because the namespace is deleted, and it isn’t copied to every node by virtue of being immutable. If you try to modify an immutable ConfigMap, the API server will reject the update.