CKA Practice Question 4: ConfigMap Change Rollout
Certified Kubernetes Administrator (CKA) · Test 1 · question 4 of 10
A Deployment's containers read their configuration from a ConfigMap using envFrom.configMapRef. An operator edits the ConfigMap with kubectl edit and confirms the new value is stored, but the running pods continue to serve the old value ten minutes later. The Deployment is healthy and no pods have restarted.
What explains this, and what is the correct way to apply the change?
Show answer and explanation
Answer:
How a ConfigMap is consumed determines whether updates propagate. A ConfigMap mounted as a volume is refreshed in place by the kubelet, so files inside the container eventually change. A ConfigMap consumed as environment variables, via envFrom or env.valueFrom.configMapKeyRef, is read once when the container process is created; the environment of a running process cannot be rewritten from outside. The only way to pick up the new value is to start new containers, which kubectl rollout restart does gracefully by rolling the pods.
Option A describes the volume-mount behaviour and applies it to the wrong consumption method. No amount of waiting will update an environment variable in a running container.
Option B changes the resourceVersion, but the problem is not that the kubelet failed to notice the update; it is that environment variables are fixed at container start. Deleting the ConfigMap also risks pods failing to start in the window before it is recreated.
Option C confuses update strategy with configuration propagation. Recreate only changes how pods are replaced during a rollout; editing a ConfigMap does not trigger a rollout under either strategy, because the Deployment's own pod template is unchanged.
Reference: ConfigMaps