What setting allows a ConfigMap to be prevented from being modified after creation?

What setting allows a ConfigMap to be prevented from being modified after creation?

• A. Versioning on the ConfigMap
• B. Immutability flag on the ConfigMap
• C. Namespace quota
• D. Pod security policy

Answer: (B)

Setting the ConfigMap to be immutable prevents any updates after it’s created. When the immutability flag is true, the API server rejects changes to that ConfigMap, so its data cannot be modified in place. If you need to change the configuration, you must create a new ConfigMap (often with a new name or version) and update the dependent resources to reference the new one. The other options don’t provide this post-creation protection: there isn’t built-in versioning for ConfigMaps, quotas control resource limits, and pod security policies govern security constraints, not immutability of config data.

Setting the ConfigMap to be immutable prevents any updates after it’s created. When the immutability flag is true, the API server rejects changes to that ConfigMap, so its data cannot be modified in place. If you need to change the configuration, you must create a new ConfigMap (often with a new name or version) and update the dependent resources to reference the new one. The other options don’t provide this post-creation protection: there isn’t built-in versioning for ConfigMaps, quotas control resource limits, and pod security policies govern security constraints, not immutability of config data.