CKA Workloads and Scheduling Practice Question
Which TWO of the following are valid ways to inject configuration data into a pod? (Select TWO.)
⚠ Common exam trap
Kubernetes often tests the distinction between valid configuration injection methods (ConfigMaps as volumes or env vars) and invalid ones like direct Pod spec edits or using PersistentVolumes, which are not designed for configuration data.
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
✓
Mounting a ConfigMap as a volume
Option C is correct because a ConfigMap can be mounted as a volume into a pod, causing each key in the ConfigMap to appear as a file in the mounted directory, which is a standard Kubernetes mechanism for injecting configuration data. Option D is also correct because a ConfigMap's keys can be exposed as environment variables inside containers via envFrom or valueFrom.configMapKeyRef, directly injecting configuration values into the container's environment. Option A is not a valid injection method because kubectl edit modifies the pod's specification itself (and most pod fields are immutable after creation), not the configuration data consumed by the application. Option B is not a native configuration-injection mechanism; a sidecar fetching config from a remote API is an application-level pattern, not a Kubernetes-provided way to inject config into a pod. Option E is incorrect because a PersistentVolume provides storage, not a mechanism for injecting configuration data into a pod.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Editing the pod's spec directly via kubectl edit
Why it's wrong here
Running kubectl edit on a running Pod's spec directly modifies the live object definition, but this is not a configuration-injection mechanism—it is an imperative change to the Pod manifest. Any values you hard-code this way are coupled to the Pod template and will be lost when the Pod is recreated from a Deployment, so it fails the test of injecting external configuration.
- ✗
Using a Sidecar container to fetch config from a remote API
Why it's wrong here
A sidecar container that pulls settings from a remote API is an application-level bootstrap pattern, not a built-in Kubernetes configuration-injection feature. Kubernetes itself does not provide any API or controller for that sidecar to populate the main container's configuration; it requires you to write code, handle retries, and manage mutual awareness inside the pod. It is a possible pattern, but it is not one of the standard, declarative mechanisms the question asks for.
- ✓
Mounting a ConfigMap as a volume
Why this is correct
Mounting a ConfigMap as a volume is a native injection method: you declare the ConfigMap in the pod's volumes list and reference it in a volumeMount, causing Kubernetes to expose each key as a file in the container's filesystem. This approach is ideal for large or structured configurations, and when the ConfigMap is updated, kubelet periodically syncs the mounted files so running applications can observe changes without a restart (depending on the app).
- ✓
Injecting a ConfigMap as environment variables
Why this is correct
Injecting a ConfigMap as environment variables uses the envFrom or valueFrom fields of a container spec to load key-value pairs directly into the process environment at container startup. This is a standard method, but environment variables are immutable after the container starts—if the ConfigMap changes, running containers keep the old values until they are restarted—making it best for relatively static settings.
- ✗
Storing config in a PersistentVolume
Why it's wrong here
Using a PersistentVolume to hold configuration is a misuse of the storage abstraction, because PersistentVolumes are designed to provide durable, stateful storage across pod restarts, not to deliver configuration payloads. While you could technically write config files into a PV and mount it, Kubernetes offers no built-in mechanism to keep that data synchronized with a ConfigMap or Secret, and it would require manual provisioning and cleanup, making it an inappropriate injection method.
Go deeper
Related to this question
Learn chapter
Troubleshooting Storage Persistence
Key term
Volumes
In Kubernetes, a volume is a storage resource that outlives the pod it belongs to, enabling data to persist across container restarts and be shared between containers in the same pod.
Key term
Network Policies
A Kubernetes resource that controls how pods communicate with each other and with other network endpoints, acting as a firewall for pod-to-pod traffic.
About these practice questions
This CKA question is part of Courseiva's 726-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 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.