Courseiva
Workloads and SchedulinghardMultiple SelectObjective-mapped

CKA Workloads and Scheduling Practice Question

Which THREE are valid ways to inject configuration data into a pod?

⚠ Common exam trap

Test-takers frequently confuse the declarative nature of Kubernetes configuration injection with imperative commands, and may incorrectly assume a 'kubectl inject' command exists, or they mix up the roles of Secrets and ConfigMaps as data sources for each other.

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 a ConfigMap as a volume.

A ConfigMap can be mounted as a volume in a Pod, allowing files to be created or updated in the container's filesystem with configuration data. This is a standard Kubernetes feature where the ConfigMap's data keys become filenames and values become file contents, and updates to the ConfigMap can be reflected in the mounted volume without restarting the Pod (depending on the mount type).

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 a Secret as a ConfigMap data source.

    Why it's wrong here

    A Secret and a ConfigMap are separate Kubernetes API resources with distinct purposes: Secrets store sensitive data (base64-encoded) while ConfigMaps store plain-text, non-sensitive configuration. There is no API field, controller, or kubectl operation that allows a Secret to be used as the data source for a ConfigMap; each resource must be consumed independently by pods, either as environment variables or mounted volumes, and attempting to reference one as the other will be rejected by the API server.

  • Mount a ConfigMap as a volume.

    Why this is correct

    Mounting a ConfigMap as a volume is a valid and commonly used injection method. When you define a volume of type configMap and mount it into a container, Kubernetes creates a file for each key in the ConfigMap, with the key as the filename and the value as the file's content. This approach is ideal for configuration files (e.g., application .conf or YAML), allows large amounts of data, and supports dynamic updates—changes to the ConfigMap are eventually reflected in the mounted files after the kubelet's sync period, unless the mount uses subPath.

  • Use 'kubectl inject configmap' to inject data at runtime.

    Why it's wrong here

    There is no such command as 'kubectl inject configmap' in the Kubernetes CLI. Configuration injection is a declarative, pod-spec-level operation: you define environment variables or volume mounts referencing a ConfigMap or Secret in the pod's YAML/JSON, and the kubelet applies that spec. The imperative kubectl commands available, such as 'kubectl create configmap', 'kubectl patch', or 'kubectl set env', operate on resources, but none provide a runtime injection subcommand like 'inject configmap'.

  • Set environment variables from a ConfigMap using envFrom or valueFrom.

    Why this is correct

    Setting environment variables from a ConfigMap using envFrom or valueFrom is a standard injection method. With valueFrom, you use a configMapKeyRef to pull a single key's value into one environment variable; with envFrom, you import all key-value pairs from a ConfigMap as environment variables, optionally with a prefix. This works for small config values (e.g., feature flags, database URLs) but is static: changes to the ConfigMap after the pod starts are not automatically propagated to already-running containers, unlike volume-mounted ConfigMaps.

  • Set environment variables from a Secret using envFrom or valueFrom.

    Why this is correct

    Setting environment variables from a Secret using envFrom or valueFrom is equally valid and follows the same pattern as ConfigMaps, but for sensitive data. With valueFrom, a secretKeyRef maps a single secret key to an environment variable; with envFrom, a secretRef imports all secret keys as environment variables, with Kubernetes automatically base64-decoding the values. This is useful for injecting credentials (API tokens, passwords) into containers, but be aware that environment variables may be visible in the pod spec and process listing, so for higher-security use cases a mounted Secret volume is often preferable.

Go deeper

Related to this question

About these practice questions

One of 302 original CKA 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 →

How Courseiva writes practice questions · Editorial policy

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.