CKA Storage Practice Question
A cluster administrator needs to create a PersistentVolume that can be mounted as a block device (not a filesystem) by a Pod. Which field in the PersistentVolume spec must be set to enable this?
⚠ Common exam trap
Many candidates confuse `volumeMode` with `accessModes` or `persistentVolumeReclaimPolicy`, assuming that access modes or reclaim policies control the block device behavior, when in fact only `volumeMode: Block` enables raw block volume mounting.
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
✓
volumeMode: Block
Setting `volumeMode: Block` in the PersistentVolume spec specifies that the volume is to be presented as a raw block device, without a filesystem. This allows a Pod to mount the volume as a block device (e.g., `/dev/sdb`) rather than a mounted directory, which is required for applications that need direct access to the underlying storage, such as databases or custom storage engines.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
persistentVolumeReclaimPolicy: Retain
Why it's wrong here
Setting `persistentVolumeReclaimPolicy: Retain` dictates what happens to the underlying physical storage resource after the PersistentVolumeClaim (PVC) that was bound to it is deleted. While 'Retain' ensures the volume is preserved for manual recovery or inspection, it solely governs the lifecycle management of the PV post-PVC deletion. This parameter has no influence whatsoever on whether the volume is presented as a raw block device or a formatted filesystem to a consuming pod.
- ✗
volumeMode: Filesystem
Why it's wrong here
Specifying `volumeMode: Filesystem` configures the PersistentVolume to be consumed as a traditional mounted filesystem within a pod. This is the default behavior for most storage types, where Kubernetes will typically format the underlying block device with a filesystem (e.g., ext4, xfs) and then mount it at a specified path. While widely used, this option explicitly does *not* make the volume available as a raw block device, which is the specific requirement for direct I/O access.
- ✗
accessModes: ReadWriteOnce
Why it's wrong here
The `accessModes: ReadWriteOnce` setting defines how a PersistentVolume can be mounted and accessed by pods, specifically allowing it to be mounted as read-write by a single node at a time. Access modes like `ReadWriteOnce`, `ReadOnlyMany`, or `ReadWriteMany` govern concurrency and node access patterns for data integrity. However, these modes are entirely orthogonal to the `volumeMode` setting, which determines whether the volume is presented as a raw block device or a formatted filesystem.
- ✓
volumeMode: Block
Why this is correct
Setting `volumeMode: Block` in a PersistentVolume definition instructs Kubernetes to expose the underlying storage resource as a raw block device directly to the consuming pod. This bypasses the traditional filesystem layer, allowing applications to perform direct I/O operations on the unformatted volume. This capability is crucial for high-performance applications like databases or custom storage engines that require fine-grained control over storage, making it the correct choice for providing a raw block device.
Go deeper
Related to this question
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.