CV0-004 Troubleshooting Practice Question
A cloud administrator is troubleshooting a containerized application deployed on a managed Kubernetes cluster. Pods are failing to start, and the events show 'FailedMount' errors for a persistent volume claim (PVC). The PVC is bound to a persistent volume (PV) that uses a storage class with a reclaim policy of Delete. Which two actions should the administrator take to resolve the issue? (Choose two.)
⚠ Common exam trap
The trap here is focusing on storage size or reclaim policy, which are provisioning concerns, rather than mount-time issues like access modes and permissions.
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
✓
Verify that the PV's storage class supports the access mode requested by the PVC.
FailedMount errors often stem from incompatible access modes or insufficient node permissions. The storage class must support the PVC's access mode, and the node's kubelet needs permissions to attach and mount the volume. Increasing size or changing reclaim policy does not affect mountability. Restarting kubelet is a temporary measure, not a root-cause fix.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Restart the kubelet service on the node to clear stale mount points.
Why it's wrong here
While restarting kubelet can sometimes clear transient issues, it is not a primary fix for FailedMount caused by permission or access mode problems. It may temporarily alleviate symptoms but does not address the root cause. The administrator should first verify access modes and permissions before resorting to restarts.
- ✓
Verify that the PV's storage class supports the access mode requested by the PVC.
Why this is correct
If the PVC requests an access mode (e.g., ReadWriteMany) that the underlying storage class does not support, the mount will fail. Checking compatibility ensures the volume can be attached to the pod. This is a common cause of FailedMount errors, especially with different storage backends like block vs. file storage.
- ✓
Check that the node's kubelet has the necessary permissions to attach and mount the volume.
Why this is correct
The kubelet on each node must have IAM permissions or credentials to attach and mount volumes from the cloud provider. If permissions are missing, the mount operation fails. This is often overlooked in managed clusters where node roles may be restricted. Ensuring the node role has appropriate policies resolves the issue.
- ✗
Change the reclaim policy to Retain to prevent data loss.
Why it's wrong here
The reclaim policy affects what happens when the PVC is deleted, not whether a pod can mount the volume. Changing it to Retain would not resolve a FailedMount error. The issue is with the mount process, not with data retention after deletion. This action is irrelevant to the current problem.
- ✗
Increase the PVC's requested storage size to match the PV's capacity.
Why it's wrong here
The PVC is already bound to a PV, so size mismatch is not the issue. If the PVC requested more than the PV provided, binding would fail initially. Since it is bound, increasing the request would not affect the mount. The error is at mount time, not provisioning.
Visual reference
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
One of 834 original CV0-004 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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CompTIA exam blueprint
This CV0-004 practice question is part of Courseiva's free CompTIA 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 CV0-004 exam.