CKA Storage Practice Question
A developer wants to mount a ConfigMap as a volume in a pod. However, the pod should only see specific keys from the ConfigMap, not all keys. What is the best approach?
⚠ Common exam trap
Candidates often confuse the `items` field with the `optional` field or assume that mounting a ConfigMap always exposes all keys, leading them to choose the wasteful approach of creating a new ConfigMap (Option D) instead of using the built-in selective projection mechanism.
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
✓
Use the 'items' field in the ConfigMap volume definition to specify which keys to include.
The `items` field in a ConfigMap volume definition allows you to selectively project only specific keys from the ConfigMap into the pod's filesystem. This is the native Kubernetes mechanism for controlling which keys appear as files, avoiding the need to mount the entire ConfigMap or create a separate ConfigMap.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use the ConfigMap to set environment variables instead of a volume mount.
Why it's wrong here
While ConfigMaps can inject data as environment variables using `envFrom` or `env` fields, the question explicitly requires mounting it as a volume. Environment variables are typically for single, scalar values, whereas volume mounts provide files within the container's filesystem, which is suitable for multi-line configuration files or multiple related files. Therefore, using environment variables does not fulfill the specific requirement of a volume mount, which places files at a designated path.
- ✓
Use the 'items' field in the ConfigMap volume definition to specify which keys to include.
Why this is correct
The `items` field within a ConfigMap volume definition is the precise and recommended method for selectively exposing specific keys as files inside a container. By specifying `key` and `path` for each desired entry, only the relevant data from the ConfigMap is mounted into the pod's filesystem, preventing unnecessary data exposure. This approach ensures minimal resource usage and adheres to the principle of least privilege by only providing what is strictly required. For example, `items: [{key: "app-config.yaml", path: "config.yaml"}]` mounts only the `app-config.yaml` key as `config.yaml`.
- ✗
Mount the entire ConfigMap and use a startup script to remove unwanted files.
Why it's wrong here
Mounting the entire ConfigMap and then relying on a startup script to remove unwanted files is highly inefficient and introduces unnecessary complexity. This method consumes more resources by mounting irrelevant data into the container and adds a fragile dependency on a script that must execute correctly every time. It also deviates from Kubernetes best practices, which advocate for declarative configurations and leveraging native features like the `items` field for precise control over mounted data. Such manual cleanup is error-prone and difficult to manage at scale.
- ✗
Create a new ConfigMap with only the needed keys.
Why it's wrong here
Creating a new ConfigMap containing only the needed keys is a technically feasible but suboptimal approach. This method leads to data duplication, as the same configuration data might exist across multiple ConfigMaps, increasing management overhead and potential for inconsistencies. The `items` field offers superior flexibility by allowing a single, comprehensive ConfigMap to serve various pods with different subsets of its data, avoiding the proliferation of specialized ConfigMaps. It's less efficient and harder to maintain than using selective mounting.
Go deeper
Related to this question
Learn chapter
Kubernetes Architecture Overview
Key term
ConfigMaps
A ConfigMap is a Kubernetes object that lets you store configuration data separately from your application code, so you can change settings without rebuilding or redeploying your container images.
Key term
Ingress Resources
Ingress Resources are Kubernetes API objects that manage external access to services inside a cluster, typically HTTP and HTTPS traffic, by defining rules for routing requests based on hostnames and paths.
About these practice questions
Courseiva writes every CKA question from scratch — 302 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 CKA 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 CKA exam.