CKA Storage Practice Question
A pod is configured to use a PersistentVolumeClaim (PVC). The PVC is bound to a PersistentVolume (PV) that uses a cloud disk. The pod fails to start with the error 'MountVolume.SetUp failed for volume ... mount failed: exit status 32'. What is the most likely cause?
⚠ Common exam trap
Many exam-takers assume the error is due to a missing PV or unbound PVC, but the specific 'exit status 32' points to a low-level mount failure, typically caused by the disk still being attached to a previous node.
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
✓
The underlying storage device is still attached to a previous node
The error 'MountVolume.SetUp failed for volume ... mount failed: exit status 32' typically indicates a filesystem-level mount failure. When a cloud disk (e.g., AWS EBS, GCE PD) is still attached to a previous node, the new node cannot mount it because the disk is already in use or has a stale filesystem lock. Kubernetes requires the disk to be detached from the old node before it can be attached and mounted on the new node.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The PV's access mode is ReadOnlyMany
Why it's wrong here
A ReadOnlyMany access mode does not block a volume from being mounted; it merely restricts the mounted volume to read-only access for multiple nodes. If the PV were ReadOnlyMany and compatible with the PVC's requested access mode, the kubelet would still perform the attach/mount operation successfully and the pod would run with a read-only filesystem. The error in question is a mount-stage failure, which is independent of access-mode permissions; an incompatible access mode would instead prevent the PVC from binding in the first place, not fail during mounting.
- ✗
The PV is not created
Why it's wrong here
If the PV were not created, the PVC could never bind, and the pod would be stuck in Pending at scheduling time with an event like '0/1 nodes are available: 1 persistentvolumeclaim ... is unbound' or 'no persistent volumes available for this claim'. The pod would never reach the container-starting phase, so it would not trigger a storage device mount attempt. Since the observed failure is specifically a mount failure that happens after the pod has been scheduled to a node, it proves the PV exists and is already bound to the PVC.
- ✗
The PVC is unbound
Why it's wrong here
An unbound PVC causes the scheduler to leave the pod unscheduled because the volume cannot be resolved before placement; Kubernetes would report a FailedBinding event or 'pod has unbound immediate PersistentVolumeClaims' rather than attempting to mount anything. The PVC status must be Bound for the kubelet to receive the volume's device path and call mount operations. Because the failure occurs during the mount phase, the PVC has necessarily already been bound to the PV and the pod has been scheduled to a node.
- ✓
The underlying storage device is still attached to a previous node
Why this is correct
Cloud provider disks, such as AWS EBS, GCE Persistent Disk, and Azure Managed Disk, are typically block devices that can be attached to only one node at a time. When a pod using such a PVC is rescheduled or evicted from a previous node, the old kubelet must detach the volume, and Kubernetes' attach/detach controller must mark it as unattached before the new node can attach it. If that detach is still in progress or failed, the new kubelet's mount attempt fails with an error such as 'Multi-Attach error for volume' or 'volume is still attached to node'. This is a transient but common cause of mount failures in environments using ReadWriteOnce volumes, and it is distinct from access-mode or binding problems.
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
Persistent Volumes
A Persistent Volume is a piece of storage in a Kubernetes cluster that has been provisioned by an administrator and exists independently of any single pod that uses it.
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.