CKA Storage Practice Question
You have a PVC that is bound to a PV with a filesystem volume mode. You want to use the volume as a block device in a pod. What should you do?
⚠ Common exam trap
Test-takers frequently assume they can simply change the pod spec (e.g., use `volumeDevices`) or modify the PV to convert a filesystem volume into a block device, but Kubernetes requires the volume mode to be set at PV creation and matched in the PVC, making it immutable after binding.
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
✓
Create a new PVC with volumeMode: Block and bind it to a new PV.
A PVC with `volumeMode: Block` must be created and bound to a PV that also has `volumeMode: Block` to use the volume as a block device in a pod. The existing PVC is bound to a PV with `volumeMode: Filesystem`, which cannot be used as a block device without recreating the underlying storage. You cannot change the volume mode of an existing PV or PVC; you must provision new resources with the correct mode.
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 hostPath volume instead.
Why it's wrong here
While a hostPath volume can expose a directory or a block device from the host's node, it is a non-portable workaround that bypasses the Kubernetes storage API. It does not resolve the requirement of provisioning a proper, managed raw block PersistentVolume, and it introduces security risks and node-binding limitations.
- ✗
Set volumeDevices in the pod spec instead of volumeMounts.
Why it's wrong here
Simply changing the Pod specification to use volumeDevices instead of volumeMounts will result in a mounting failure because the underlying PersistentVolume is still formatted with a filesystem. The volume's storage mode must match the consumption method; a Filesystem mode volume cannot be consumed as a raw block device.
- ✓
Create a new PVC with volumeMode: Block and bind it to a new PV.
Why this is correct
To transition to a raw block device, you must define a new PersistentVolumeClaim with volumeMode explicitly set to Block. This PVC must then bind to a newly provisioned PersistentVolume that also supports and specifies volumeMode: Block, ensuring the storage plugin exposes the raw block device directly to the container.
- ✗
Modify the PV's volumeMode to Block.
Why it's wrong here
The volumeMode field of an existing PersistentVolume is immutable after creation and cannot be dynamically updated from Filesystem to Block. Attempting to edit this field in-place on an active PV will be rejected by the Kubernetes API server validation webhook, requiring a complete recreation of the resource.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKA question from scratch — 726 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.