KCNA Kubernetes Fundamentals Practice Question
An application Pod in the `web` namespace must read a configuration value stored in a ConfigMap named `app-config` without restarting when the value changes. The value is consumed as a file inside the container. Which approach meets this requirement?
⚠ Common exam trap
The trap here is believing that envFrom variables refresh automatically, when they are fixed at container start and never update.
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
✓
Mount the ConfigMap as a volume and let the application re-read the file periodically.
Volume-mounted ConfigMaps are periodically refreshed by the kubelet, so an application that re-reads its configuration file can pick up new values without a restart. Environment-variable injection and subPath mounts do not update at runtime, and immutable ConfigMaps cannot change at all, so the volume-mount approach is the only one that satisfies the scenario.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Mount the ConfigMap as a volume and let the application re-read the file periodically.
Why this is correct
ConfigMaps projected as volumes are updated in place by the kubelet after a short sync delay, so a file-reading application that re-reads on its own sees new values without a Pod restart. This is the standard way to get live configuration updates. The application must still poll or watch the file, because the kubelet does not signal the process.
- ✗
Use a subPath volume mount of the ConfigMap key.
Why it's wrong here
Mounting a single key with subPath creates a bind-mount that does not receive ConfigMap updates. The kubelet's atomic symlink swap cannot propagate through a subPath mount, so the file stays frozen at its initial content. This is a frequent source of confusion and fails the live-update requirement.
- ✗
Set the ConfigMap as an immutable object and mount it as a volume.
Why it's wrong here
Marking a ConfigMap immutable prevents any modification to its data once created; the only way to change values is to delete and recreate it. That eliminates in-place updates entirely, so mounted files could never change without recreating the Pod. It is the opposite of what a mutable, live-updated configuration needs.
- ✗
Reference the ConfigMap with envFrom and rely on automatic environment refresh.
Why it's wrong here
Environment variables injected from a ConfigMap are resolved when the container starts and never change afterward. There is no refresh mechanism, so a running process keeps the original values until the container is recreated. This approach directly contradicts the no-restart requirement, making it unsuitable for live configuration.
Go deeper
Related to this question
About these practice questions
One of 930 original KCNA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CNCF exam blueprint
This KCNA 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 KCNA exam.