KCNA Container Orchestration Practice Question
An application Pod needs to read a database password at runtime. The security team requires that the secret material never be stored in the Pod's container image or in a ConfigMap, and that updates to the secret be reflected in the running container without recreating the Pod. Which approach satisfies these requirements?
⚠ Common exam trap
The trap here is assuming that environment-variable injection from a Secret or ConfigMap updates at runtime, when only volume-mounted Secrets are refreshed periodically by the kubelet.
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
✓
Store the password in a Secret and mount it as a volume in the Pod.
Kubernetes Secrets keep sensitive data out of images and ConfigMaps. Mounting a Secret as a volume presents the value as a file, and the kubelet periodically refreshes projected Secret volumes so changed values appear in the container filesystem without restarting the Pod. The application must re-read the file to pick up changes, but the platform side meets the security and live-update constraints.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Bake the password into a private container image and pull it with an imagePullSecret.
Why it's wrong here
Embedding credentials in a container image violates the explicit requirement that the secret not be stored in the image. Image pull secrets authenticate registry access; they do not protect or rotate application secrets. Any update would require rebuilding and redeploying the image, which also fails the no-recreation requirement.
- ✗
Pass the password as a command-line argument in the Pod specification.
Why it's wrong here
Command-line arguments are visible in the Pod spec and often in process listings, which exposes the secret broadly. They are also fixed at container start and cannot be updated without recreating the Pod. This fails both the confidentiality requirement and the live-update requirement, making it unsuitable for database credentials.
- ✗
Store the password in a ConfigMap and consume it as an environment variable.
Why it's wrong here
ConfigMaps are intended for non-sensitive configuration and are not a secure store for passwords. Environment variables are also injected only at container start, so updates to the ConfigMap would not reach the running process. This approach violates the security requirement and fails the live-update requirement.
- ✓
Store the password in a Secret and mount it as a volume in the Pod.
Why this is correct
A Secret stores sensitive data separately from images and ConfigMaps, and mounting it as a volume projects the value as a file. The kubelet refreshes mounted Secret volumes periodically, so updates to the Secret propagate to the running container without recreating the Pod, provided the application re-reads the file, satisfying both security and live-update requirements.
Go deeper
Related to this question
About these practice questions
This KCNA question is part of Courseiva's 930-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. 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.