KCNA Kubernetes Fundamentals Practice Question
A developer needs a Pod to read configuration values and credentials separately, where non-sensitive settings should update without restarting the Pod and secrets should be mounted as files. Which pairing of Kubernetes objects best fits this requirement?
⚠ Common exam trap
The trap here is reaching for environment variables, which are frozen at container start and never reflect later ConfigMap or Secret changes.
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
✓
ConfigMap for the non-sensitive settings and Secret for the credentials, both consumed as volumes.
The requirement splits non-sensitive settings that must refresh live from credentials that must be handled securely, and the ConfigMap-plus-Secret pairing consumed as volumes satisfies both. Volume-mounted ConfigMaps update on the kubelet sync interval, while Secret volumes keep credentials out of environment dumps and allow tighter RBAC.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Secret for both the settings and the credentials, consumed via environment variables.
Why it's wrong here
Environment variables are injected only at container start, so updates to the Secret would not reach a running container without a restart, violating the no-restart requirement. Also, using a Secret for ordinary non-sensitive settings misuses the object's purpose and complicates RBAC and audit. Secrets are base64-encoded, not encrypted by default, so storing benign configuration there adds no security benefit while losing the live-update behavior volumes provide.
- ✗
ConfigMap for both, with the credentials stored in a separate key and mounted as a volume.
Why it's wrong here
ConfigMaps are not designed for sensitive data: they are stored unencrypted in etcd by default, readable by anyone with get rights on the namespace, and often surfaced in logs and dashboards. Placing credentials there breaks the security boundary the scenario implies. It also ignores that Secret exists precisely to add RBAC separation and optional encryption-at-rest. The volume mechanics would work, but the object choice is wrong.
- ✓
ConfigMap for the non-sensitive settings and Secret for the credentials, both consumed as volumes.
Why this is correct
ConfigMap holds non-sensitive key-value configuration and Secret holds sensitive data; both can be mounted as volumes so the files refresh when the API objects change, satisfying the no-restart requirement for the non-sensitive settings. Volume-mounted updates propagate to the Pod's filesystem on the kubelet's sync period, though applications must re-read the files. This pairing matches the stated separation of concerns exactly.
- ✗
ConfigMap for the settings and a downward API volume for the credentials.
Why it's wrong here
The downward API exposes Pod and container metadata such as labels, annotations, and resource fields; it cannot reference arbitrary credential data. There is no way to populate it with externally supplied secrets. Using it for credentials would either fail schema validation or require embedding the values as annotations, which is insecure and unmanaged. The downward API is for metadata propagation, not secret storage.
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
About these practice questions
Courseiva writes every KCNA question from scratch — 930 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 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.