Question 20
Domain 2: Workloads & SchedulingA Deployment with 3 replicas remains Pending because its container resource requests are too high for the cluster nodes. Which kubectl action best fixes the scheduling issue while keeping the Deployment running?
Correct answer: A
Explanation
A Pod stays Pending when the scheduler cannot place it because its requested CPU and memory exceed available node capacity. Lowering the Deployment’s resource requests changes the scheduling requirements so the existing Deployment can be rescheduled and continue running with 3 replicas.
Why each option is right or wrong
A. Lower the Deployment's CPU and memory requests to fit node capacity, then apply the updated manifest
Under the Kubernetes scheduler rules, a Pod remains Pending when no node can satisfy its requested resources; requests are what the scheduler uses for placement, not actual usage. In this case, the Deployment’s Pod template must be edited to reduce the CPU and memory requests in the manifest and then reapplied with kubectl apply so the ReplicaSet creates Pods that fit within node allocatable capacity, allowing all 3 replicas to schedule without deleting the Deployment.
B. Increase the number of replicas so the scheduler can spread pods across more nodes
C. Change the pods to use node selectors so they bypass resource checks
D. Set the pods' resource requests to zero so they always schedule