hardMultiple Choice
CV0-004 Practice Question: A DevOps engineer is deploying an application on…
Exhibit
Refer to the exhibit. ``` $ kubectl get pods -n production NAME READY STATUS RESTARTS AGE frontend-5d8f4d9c7-cm2xr 0/1 Pending 0 10m backend-6b9f7d5e4-lp9qz 1/1 Running 0 15m $ kubectl describe pod frontend-5d8f4d9c7-cm2xr -n production ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 10m default-scheduler 0/3 nodes are available: 1 Insufficient cpu, 2 Insufficient memory. ```
A DevOps engineer is deploying an application on Kubernetes. The exhibit shows the status of pods and a describe output. The frontend pod is stuck in Pending state. Which action should the engineer take to resolve the issue?
⚠ Common exam trap
CompTIA often tests the misconception that changing service types or image pull policies can resolve scheduling failures, when the root cause is almost always resource insufficiency or taints/tolerations.
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
✓
Reduce the resource requests in the frontend deployment manifest.
The frontend pod is stuck in Pending state because the cluster nodes lack sufficient resources (CPU or memory) to satisfy the pod's resource requests. Reducing the resource requests in the deployment manifest lowers the scheduling threshold, allowing the pod to fit on an available node. This directly addresses the most common cause of Pending pods: insufficient allocatable resources on any 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.
- ✓
Reduce the resource requests in the frontend deployment manifest.
Why this is correct
A pod stuck in Pending with insufficient-resource events means no node satisfies its CPU or memory requests. Lowering those requests lets the scheduler place the pod on existing nodes, resolving the constraint without adding capacity.
- ✗
Add a node affinity rule to schedule on nodes with more memory.
Why it's wrong here
Node affinity constrains scheduling to nodes matching labels, but the describe output shows insufficient CPU or an unbound PVC, not a memory shortfall, so the pod remains Pending. Node affinity is the right tool when you deliberately need to pin workloads to particular labelled nodes.
- ✗
Change the service type from ClusterIP to NodePort.
Why it's wrong here
Service type controls how traffic reaches already-running pods; a Pending pod has no endpoint to route to, so changing ClusterIP to NodePort changes nothing. NodePort is correct when external clients must reach a healthy workload without a cloud load balancer.
- ✗
Modify the image pull policy to Always.
Why it's wrong here
Image pull policy governs whether the kubelet re-fetches an image already cached on a node; it has no bearing on scheduling, so it cannot clear a Pending pod. It is tempting because image pull errors do surface as pod failures, but those manifest as ImagePullBackOff or ErrImagePull, not Pending.
Visual reference
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 by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.