CKA Storage Practice Question
A cluster has a CSI driver installed. A pod using a CSI volume is in CrashLoopBackOff. 'kubectl describe pod' shows: 'failed to mount volume: rpc error: code = DeadlineExceeded desc = context deadline exceeded'. What is the MOST likely cause?
⚠ Common exam trap
Candidates often think 'context deadline exceeded' is a generic network timeout or PVC issue, but in the CSI context it specifically points to the driver's gRPC response timeout, not a binding or installation problem.
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 CSI driver is failing to respond in time.
The error 'context deadline exceeded' indicates that the CSI driver's gRPC call to mount the volume did not complete within the default timeout (typically 30 seconds). This is most commonly caused by the CSI driver being unresponsive due to resource starvation, network issues, or a bug in the driver itself. Since the CSI driver is installed and the pod is attempting to mount, the failure is in the driver's response time, not in the PVC binding or volume 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.
- ✓
The CSI driver is failing to respond in time.
Why this is correct
When the kubelet or volume manager attempts to attach or mount a CSI volume, it communicates with the CSI driver via gRPC. If the driver fails to respond within the designated timeout period, the operation fails with a timeout error in the pod events, indicating the driver is unresponsive or overloaded.
- ✗
The PVC is not bound.
Why it's wrong here
If the PersistentVolumeClaim (PVC) associated with the pod were not bound to a PersistentVolume (PV), the Kubernetes scheduler would be unable to schedule the pod, leaving it stuck in a Pending phase. It would not progress to the container execution phase where mount timeouts or crash loops occur.
- ✗
The CSI driver is not installed.
Why it's wrong here
If the required CSI driver were completely missing from the cluster, the volume controller would fail immediately during the provisioning or attachment phase. This would generate a specific event error such as 'no volume plugin matched' or 'CSIDriver object not found,' rather than a timeout during an active mount operation.
- ✗
The volume mode is Block but the pod expects Filesystem.
Why it's wrong here
A mismatch between the volume mode specified in the PV/PVC (e.g., Block) and the pod's volume mount configuration (which defaults to Filesystem) results in an immediate validation or mounting error. Kubelet would reject the mount with a clear 'cannot mount volume as filesystem' error, rather than waiting for a driver timeout.
Go deeper
Related to this question
Learn chapter
Network Policies and Secure Connectivity
Key term
kubectl Command Reference
kubectl is the command-line tool used to interact with and manage Kubernetes clusters by sending commands to the Kubernetes API.
Key term
Pod Failure Troubleshooting
Pod failure troubleshooting is the process of identifying and resolving issues that cause Kubernetes pods to crash, restart, or become unavailable.
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.