CKA Workloads and Scheduling Practice Question
A pod with priorityClassName: high is pending. You describe the pod and see the event: '0/3 nodes are available: 3 node(s) didn't match pod affinity/anti-affinity, 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate.' The pod has required anti-affinity to avoid co-location with pods from the same app. How can you get the pod scheduled?
⚠ Common exam trap
The trap here is that candidates focus on the taint error (which is only one node) and mistakenly think adding a toleration will solve the problem, ignoring the more fundamental anti-affinity constraint that affects all three nodes.
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
✓
Change the anti-affinity rule from requiredDuringSchedulingIgnoredDuringExecution to preferredDuringSchedulingIgnoredDuringExecution.
The pod is pending because its required anti-affinity rule cannot be satisfied on any node: all 3 nodes either have a control-plane taint (which the pod doesn't tolerate) or already host pods from the same app, violating the anti-affinity. Changing the rule from requiredDuringSchedulingIgnoredDuringExecution to preferredDuringSchedulingIgnoredDuringExecution makes the anti-affinity a soft constraint, allowing the scheduler to place the pod on a node even if it means co-locating with same-app pods, thus resolving the scheduling conflict.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Add a toleration for the control-plane taint.
Why it's wrong here
While a control-plane taint would prevent a pod from scheduling on the master node, the problem description indicates that three nodes did not match anti-affinity rules. Adding a toleration would only address the single control-plane node, which is typically reserved for cluster operations and not application workloads. This action would not resolve the broader anti-affinity constraint preventing the pod from being scheduled on multiple worker nodes.
- ✗
Increase the number of replicas of the app to spread the pods.
Why it's wrong here
Increasing the number of replicas would actually worsen the scheduling problem, not solve it. Pod anti-affinity rules are designed to ensure that pods of the same application are spread across different nodes or topology domains. Adding more replicas would introduce more pods that need to satisfy this `requiredDuringScheduling` anti-affinity constraint, making it even harder for the Kubernetes scheduler to find suitable, distinct nodes for all of them.
- ✗
Delete the existing pods of the same app to free up nodes.
Why it's wrong here
Deleting existing pods of the same application would indeed free up nodes, potentially allowing the pending pod to schedule. However, this is a destructive action that would reduce the availability of the running application and disrupt services for users. It directly contradicts the principles of high availability and resilience that Kubernetes aims to provide, making it an unacceptable operational solution for a scheduling issue.
- ✓
Change the anti-affinity rule from requiredDuringSchedulingIgnoredDuringExecution to preferredDuringSchedulingIgnoredDuringExecution.
Why this is correct
Changing the anti-affinity rule from `requiredDuringSchedulingIgnoredDuringExecution` to `preferredDuringSchedulingIgnoredDuringExecution` transforms a hard constraint into a soft preference. With a `required` rule, the scheduler *must* satisfy the anti-affinity; otherwise, the pod remains pending. By making it `preferred`, the scheduler will *attempt* to satisfy the rule but will still schedule the pod on an available node even if the preference cannot be met, thus 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
One of 302 original CKA 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 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.