CKAD Application Design and Build Practice Question
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?
⚠ Common exam trap
A common mix-up: candidates 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.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The kubelet sync interval delays the propagation of ConfigMap changes to pods.
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.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
ConfigMap updates are not propagated to mounted volumes.
Why it's wrong here
This statement is false: when a ConfigMap is consumed through a mounted volume, the kubelet actively watches or periodically refreshes the ConfigMap and rewrites the projected files. A change to the ConfigMap object does eventually appear in the volume, so the problem is only timing, not a lack of propagation. The delay comes from the kubelet's sync loop, not from an immutable design.
- ✓
The kubelet sync interval delays the propagation of ConfigMap changes to pods.
Why this is correct
The correct explanation is that the kubelet runs a periodic sync loop (commonly every 1 minute, configurable via `--sync-frequency`) that refreshes ConfigMap data into mounted volumes. Until that sync cycle runs, pods continue reading the previous version of the ConfigMap, which is why updates appear delayed. After the sync, the files are updated in place and subsequent reads see the new data.
- ✗
The pods must be recreated after a ConfigMap update to see the changes.
Why it's wrong here
This misconception ignores a key Kubernetes behavior: for volume-based ConfigMap usage, the kubelet updates the projected files without restarting or recreating the pod. A restart is only required when the ConfigMap is injected via environment variables, because environment variables are fixed at container start. Therefore, saying pods must be recreated after every update is too broad and false for mounted volumes.
- ✗
ConfigMaps are immutable and cannot be updated.
Why it's wrong here
ConfigMaps are mutable by default; the API accepts updates to their `data` field at any time, and the updated values eventually reach consumers. Immutability is an optional feature enabled by setting `immutable: true` in the ConfigMap spec, after which the object cannot be modified or deleted. The original statement treats an available opt-in as a default behavior, making it incorrect.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKAD question from scratch — 826 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKAD practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKAD exam.