CKA Storage Practice Question

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

  Why it's wrong here

  Secret volumes are specifically engineered to carry sensitive material such as passwords, API tokens, or SSH keys, and while Kubernetes does store them as base64-encoded data, the volume itself is memory-backed (tmpfs) whenever possible and can be tightly scoped with permissions like defaultMode: 0400. Because secrets are subject to RBAC, encryption-at-rest policies, and the overall security lifecycle, using them merely to push general configuration settings would both blur the intended separation of concerns and add unnecessary security-related overhead. For a shared configuration file that is not confidential, a ConfigMap is the natural fit; a Secret would be an over-scoped and semantically incorrect volume type.

• ✗

  hostPath

  Why it's wrong here

  A hostPath volume binds a directory or file directly from the kubelet's node into the Pod, which ties the Pod's data to a specific host filesystem and is commonly reserved for node-level system components (e.g., kubelet or legacy logging agents). This tight coupling breaks the scheduler's assumption of pod portability, because the data will not exist on another node unless manually replicated, and it also carries host-security implications since any container with write access can alter node files. Sharing a general configuration file among pods in this way would require manual placement of the config on every possible node, completely defeating the declarative, cluster-wide management that Kubernetes configuration objects are meant to provide.

• ✓

  configMap

  Why this is correct

  ConfigMap volumes are the idiomatic Kubernetes mechanism for delivering non-sensitive configuration data, such as environment variables, command-line arguments, or entire configuration files, to containers. When mounted as a volume, each key in the ConfigMap becomes a file in the target directory and the file's content is the corresponding value, all managed by the kubelet into a local tmpfs that is updated atomically when the ConfigMap changes. This design gives pods a clean, portable way to share the same configuration across replicas or across different workloads, while keeping the config data decoupled from the container image and host filesystem.

• ✗

  emptyDir

  Why it's wrong here

  An emptyDir volume is created as a blank, writable directory the moment a Pod is assigned to a node, and it persists only for that Pod's lifetime on that node, being deleted when the Pod is removed or evicted. Its primary purpose is scratch space for containers, such as temporary sort files, checkpoints, or sharing data between containers in the same pod, and it is explicitly not backed by any durable storage. Using emptyDir to share configuration would be wrong because the data would vanish whenever the pod restarts on another node, providing no source of truth or reusability across pod lifetimes.

Go deeper

Related to this question