CKA Troubleshooting Practice Question
A pod is in the 'Pending' state for a long time. You run 'kubectl describe pod pending-pod' and see the event: '0/4 nodes are available: 1 node(s) had taint {node.kubernetes.io/not-ready: }, 3 node(s) had taint {node-role.kubernetes.io/control-plane: } that the pod didn't tolerate.' What is the MOST likely solution?
⚠ Common exam trap
Candidates often confuse taints/tolerations with node affinity or resource constraints, leading them to choose resource-related fixes or node modifications instead of adding the correct toleration to the pod spec.
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
✓
Add tolerations to the pod for the control-plane taint
The pod is stuck in 'Pending' because it cannot be scheduled. The event shows that 3 control-plane nodes have the 'node-role.kubernetes.io/control-plane' taint, which by default prevents non-tolerant pods from scheduling on them. Adding the corresponding toleration to the pod's spec allows it to be scheduled on those nodes, resolving the pending state.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Remove the taint from the control-plane nodes
Why it's wrong here
Removing taints from control-plane nodes is strongly discouraged as it compromises cluster stability and security. Control-plane nodes are typically tainted with `node-role.kubernetes.io/control-plane:NoSchedule` to reserve their resources for critical Kubernetes components like the API server and scheduler. Allowing general workloads to run on these nodes without explicit tolerations can lead to resource contention, performance degradation, and potential instability of the entire cluster's control plane.
- ✗
Delete the pod and recreate it
Why it's wrong here
Deleting and recreating the pod will not resolve the underlying scheduling issue if the pod's manifest remains unchanged. The problem stems from the pod's specification lacking the necessary toleration to match the control-plane node's taint. When recreated, the scheduler will attempt to place the identical pod definition, encounter the same taint mismatch, and the pod will again enter a `Pending` state if no other suitable nodes are available.
- ✗
Increase the pod's resource requests
Why it's wrong here
Increasing the pod's resource requests is irrelevant to a pod being in a `Pending` state due to a taint. Taints and tolerations govern where a pod *can* be scheduled based on node policy, not resource availability. A pod pending due to a taint means the scheduler is explicitly prevented from placing it on certain nodes, regardless of whether those nodes have ample CPU or memory. Resource constraints would typically manifest with specific scheduler events indicating insufficient resources, not a taint-related blockage.
- ✓
Add tolerations to the pod for the control-plane taint
Why this is correct
Adding tolerations to the pod's manifest is the correct solution because taints repel pods unless those pods have a matching toleration. Control-plane nodes are typically tainted to prevent general workloads from running on them. By adding a toleration that matches the control-plane node's taint (e.g., `key: node-role.kubernetes.io/control-plane`, `operator: Exists`, `effect: NoSchedule`), the pod explicitly signals to the scheduler that it is permitted to be scheduled on such nodes, resolving the `Pending` state.
Visual reference
Go deeper
Related to this question
Learn chapter
Kubernetes Architecture Overview
Key term
Ingress Resources
Ingress Resources are Kubernetes API objects that manage external access to services inside a cluster, typically HTTP and HTTPS traffic, by defining rules for routing requests based on hostnames and paths.
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.
About these practice questions
This CKA question is part of Courseiva's 302-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.