CKA Storage Practice Question
Which THREE of the following are correct about using a hostPath volume in Kubernetes? (Select THREE)
⚠ Common exam trap
A common mix-up: candidates confuse hostPath with network-attached storage (like NFS or CSI drivers) that support multi-node access, or assume that local node storage is inherently production-ready without considering pod rescheduling and node failures.
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
✓
It is recommended for testing and development only
Option E is correct because a hostPath volume mounts a file or directory directly from the host node's filesystem into the pod, which is its defining behavior. Option A is correct because hostPath volumes are explicitly recommended for testing and development only, since they tie pods to specific nodes and introduce security and portability risks. Option B is correct because a common use case is mounting the Docker socket (e.g., /var/run/docker.sock) from the host into a pod so the pod can interact with the container runtime. Option C is incorrect because hostPath volumes are node-local and cannot provide ReadWriteMany access across multiple nodes. Option D is incorrect because hostPath is not suitable for production workloads needing persistence across nodes, as data is tied to a single node and not replicated or portable.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
It is recommended for testing and development only
Why this is correct
The official Kubernetes documentation steers users away from hostPath for production because it breaks the abstraction of node-independent pods and poses security risks if the path is sensitive. It is commonly used in development clusters for quick local testing, or for system-level agents that really do need host filesystem access, like a log collector reading /var/log. However, for persistent application data that must survive pod rescheduling or cluster upgrades, a PersistentVolumeClaim backed by remote storage is the correct, recommended approach.
- ✓
It can be used to access the Docker socket from a pod
Why this is correct
Mounting the Docker socket, typically located at /var/run/docker.sock on the host, into a pod via a hostPath volume gives the pod direct control over the host's Docker daemon. This enables the pod to create, start, stop, and inspect containers as if it were the local Docker CLI. While powerful for tools like Docker-in-Docker CI runners, this access is a severe security risk because any code running in the pod effectively gains root-equivalent privileges on the host.
- ✗
It supports ReadWriteMany access mode across multiple nodes
Why it's wrong here
hostPath volumes are inherently node-specific, which means they are bound to the directory path on a single node. ReadWriteMany (RWX) access mode implies that multiple pods scheduled on different nodes can concurrently mount and write to the same volume, a capability that only network-attached storage like NFS or CephFS can offer. Even if a hostPath directory exists identically on multiple nodes, those are separate physical directories, not a shared namespace, so RWX semantics cannot be honored across nodes.
- ✗
It is suitable for production workloads that require persistence across nodes
Why it's wrong here
A hostPath volume's data lives entirely on the node where the pod is currently running. If the pod gets rescheduled to a different node due to a node failure, upgrade, or autoscaling, the new node will not have the same hostPath contents, leading to data loss or inconsistent application state. Production-grade persistence requires either a replicated distributed storage system or Kubernetes persistent volumes with a StorageClass that provides node-independent access, making hostPath acceptable only for short-lived, node-locked workloads.
- ✓
It mounts a file or directory from the host node's filesystem
Why this is correct
A hostPath volume directly maps a file or directory from the host node's filesystem into a pod, using a path like /var/lib/foo and a type such as DirectoryOrCreate. This is the fundamental definition of hostPath: the pod sees and writes to the host's actual disk, not a virtualized or network-backed volume. Because the path resides on the node's local storage, no network filesystem or shared storage provider is involved, which is why this volume type is fast but tied to a single machine.
Go deeper
Related to this question
Learn chapter
Troubleshooting Cluster and Node Issues
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.
Key term
Container Runtime
A container runtime is software that runs containers by using the host operating system's kernel to isolate processes, manage filesystem layers, and handle networking.
About these practice questions
One of 726 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 →
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.