A developer creates a Deployment with 3 replicas that uses a ConfigMap mounted as a volume. After updating the ConfigMap, the developer expects the pods to pick up the new configuration immediately, but the old configuration is still in use. What is the most likely reason?
The kubelet periodically syncs ConfigMap data; changes may take up to the sync period to appear.
Why this answer
When a ConfigMap is mounted as a volume, updates to the ConfigMap are eventually propagated to the pods, but not instantly. The kubelet periodically syncs mounted ConfigMaps (default interval is 60 seconds), so there is a delay before pods see the new configuration. This is the most likely reason the old configuration is still in use.
Exam trap
The trap here is that candidates often assume ConfigMap updates are either instant or require pod recreation, but the CKAD exam tests the nuance that mounted volumes are updated with a kubelet sync delay, while environment variables are not updated at all.
How to eliminate wrong answers
Option A is wrong because ConfigMap updates are propagated to mounted volumes — the kubelet does update the files in the volume, but with a sync delay. Option C is wrong because pods do not need to be recreated; the mounted volume is updated in-place by the kubelet, though some applications may require a restart to reload the configuration. Option D is wrong because ConfigMaps are not immutable by default; they can be updated unless explicitly created with the `immutable: true` field.