CKA Workloads and Scheduling Practice Question
Which TWO of the following will cause a pod to be rescheduled to a different node? (Select TWO.)
⚠ Common exam trap
It's easy for candidates to confuse NoExecute (which evicts existing pods) with NoSchedule (which only blocks new pods), leading candidates to incorrectly select NoSchedule as a cause for rescheduling.
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
✓
Node has a taint with effect NoExecute
Option A is correct because a taint with effect NoExecute on a node causes the node controller to evict pods that do not tolerate that taint, and the evicted pods are then recreated by their controller (e.g., Deployment/ReplicaSet) and rescheduled onto a different node. Option E is correct because when a higher-priority pod is scheduled and the cluster needs to free resources, the scheduler can preempt (evict) lower-priority pods; those preempted pods are deleted and their controllers recreate them, causing rescheduling to another node. Option B is not correct: increasing a pod's resource requests does not by itself trigger rescheduling — the change is not applied to an existing running pod (pod specs are largely immutable), and even if it were, it would not automatically move the pod to another node. Option C is not correct: updating node affinity on a running pod is not a supported in-place change and does not cause the kubelet/scheduler to relocate the pod; affinity is evaluated at scheduling time. Option D is not correct: a NoSchedule taint only prevents new pods from being scheduled onto the node; it does not evict or reschedule pods already running there.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Node has a taint with effect NoExecute
Why this is correct
A node taint with effect NoExecute triggers immediate eviction of any pod that does not tolerate the taint. The kubelet acts on this taint by evicting the running pod, and since the pod is typically managed by a controller such as a Deployment, its controller recreates the pod on another schedulable node. This eviction and recreation is the mechanism that causes the pod to be rescheduled.
- ✗
The pod's resource requests are increased
Why it's wrong here
Increasing a pod's resource requests does not force the scheduler to move the pod. Resource requests are used by the scheduler at placement time to pick a node, but a running pod's resource usage is unaffected by a spec change until the pod is restarted or recreated. Moreover, resource requests are immutable for existing pods, so an attempted update would be rejected without altering the pod's placement.
- ✗
The pod's node affinity is updated
Why it's wrong here
Updating a pod's node affinity also does not cause rescheduling because the node selector and affinity rules are only evaluated when the pod is initially scheduled. If node affinity is mutable, a change only takes effect when the pod is recreated; otherwise, the running pod stays put even if its affinity now excludes the current node. The scheduler does not continuously re-check affinity constraints against the running pod.
- ✗
Node has a taint with effect NoSchedule
Why it's wrong here
A NoSchedule taint prevents new pods from being scheduled onto the node, but it has no effect on pods already running there. The kubelet will not evict existing pods for this taint, so the current pod continues to run undisturbed. Only when the pod is deleted or the node is drained will it need to be scheduled elsewhere.
- ✓
A higher-priority pod preempts the current pod
Why this is correct
Pod preemption is a scheduling-time action: when a high-priority pod cannot be scheduled due to insufficient capacity, the scheduler identifies lower-priority pods to evict in order to free resources. The evicted pod is terminated and, if it belongs to a controller, the controller will create a replacement pod, which the scheduler then places on another node. This preemption causes the original pod to be rescheduled, effectively.
Go deeper
Related to this question
Learn chapter
Troubleshooting Cluster and Node Issues
Key term
Node Affinity
Node Affinity is a set of rules used by Kubernetes to determine which nodes a pod can be scheduled on, based on labels assigned to the nodes.
Key term
Taints and Tolerations
Taints and tolerations are Kubernetes features that control which pods can be scheduled onto which nodes by marking nodes with a taint and allowing pods to declare a toleration to the taint.
About these practice questions
One of 726 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.