CKA Troubleshooting Practice Question
You have a pod that is stuck in 'Pending' state. Running 'kubectl describe pod' shows the event: '0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 2 node(s) didn't match pod anti-affinity rules.' What is the MOST likely solution?
⚠ Common exam trap
The trap here is that candidates focus on the taint error (because it's a common CKA topic) and overlook the anti-affinity error, which is the actual majority blocker; the CKA exam often tests your ability to prioritize multiple scheduling failures.
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
✓
Remove or modify the pod anti-affinity rules
The pod is unschedulable because two nodes are excluded by pod anti-affinity rules, not because of the master taint (only one node has that taint). The most direct solution is to remove or modify the anti-affinity rules so the pod can be scheduled on those two nodes. Adding a toleration would only address the single master node, leaving the anti-affinity issue unresolved.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Cordon the master node to remove it from scheduling
Why it's wrong here
Cordoning the master node marks it as unschedulable by applying a node.kubernetes.io/unschedulable taint. This action does nothing to resolve the scheduling constraints on the worker nodes and actually reduces the cluster's overall scheduling capacity, making the pending pod situation worse.
- ✓
Remove or modify the pod anti-affinity rules
Why this is correct
Pod anti-affinity rules prevent the scheduler from placing a pod on a node that already hosts a matching pod. By removing or relaxing these rules, such as changing a hard requiredDuringSchedulingIgnoredDuringExecution constraint to a soft preferredDuringSchedulingIgnoredDuringExecution rule, the scheduler can utilize the available worker nodes even if they already run similar pods.
- ✗
Add a toleration for the master taint to the pod spec
Why it's wrong here
While adding a toleration allows the pod to bypass the master node's taint, it does not address the underlying pod anti-affinity constraints. If the anti-affinity rules are defined globally or if a matching pod already exists on the master node, the scheduler will still block placement, leaving the pod in a pending state.
- ✗
Delete and recreate the pod
Why it's wrong here
Deleting and recreating the pod does not alter the pod's specification or the current state of the cluster's nodes. Because the scheduler evaluates the exact same resource requests, taints, and anti-affinity rules against the same node topology, the newly created pod will inevitably get stuck in the Pending state again.
Visual reference
Go deeper
Related to this question
Learn chapter
Troubleshooting Cluster and Node Issues
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
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
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.