KCNA Kubernetes Fundamentals Practice Question
A cluster administrator runs `kubectl taint nodes node1 dedicated=gpu:NoSchedule` and then creates a Pod with toleration `dedicated=gpu:NoSchedule` but no node affinity. What is the resulting behavior?
⚠ Common exam trap
The trap here is treating a toleration as if it pinned the Pod to the tainted node, when it only lifts the repulsion.
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
✓
The Pod can be scheduled on node1, but it may also be scheduled on any other node that passes the scheduler's filters.
Taints repel and tolerations merely permit; a tolerating Pod is eligible for the tainted node but is not drawn to it. The scheduler still scores every feasible node, so without node affinity or a node selector the Pod can land anywhere that passes filters, which is why dedicated-node designs pair taints with attracting constraints.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The taint is removed from node1 automatically once a Pod with the matching toleration is scheduled there.
Why it's wrong here
Taints are persistent node properties managed explicitly by administrators or node controllers; scheduling a tolerating Pod does not mutate the node's taints. The taint continues to repel all Pods without matching tolerations, which is the intended isolation behavior. Only an explicit kubectl taint removal or a controller action changes it. Automatic removal would defeat the purpose of dedicating a node to specific workloads.
- ✗
The Pod is guaranteed to run on node1 because the toleration matches the taint.
Why it's wrong here
A toleration only permits scheduling onto a tainted node; it does not attract the Pod there. The scheduler still evaluates all nodes and may place the Pod on an untainted node, since tolerations are permissive rather than selective. Guaranteeing placement on node1 requires node affinity or nodeName in addition to the toleration. This distinction between repelling and attracting is the core of taint and toleration semantics.
- ✗
The Pod remains Pending because tolerations must be paired with node affinity to be valid.
Why it's wrong here
Tolerations are valid on their own and take effect without any affinity. The scheduler will consider node1 feasible for this Pod, and untainted nodes remain feasible as well, so a Pending state would only arise if no node passed filters for other reasons such as insufficient resources. The pairing with affinity is a best practice for dedicated workloads, not a schema or scheduling requirement.
- ✓
The Pod can be scheduled on node1, but it may also be scheduled on any other node that passes the scheduler's filters.
Why this is correct
Taints repel Pods that lack matching tolerations, and a toleration merely removes that repulsion for the tainted node. The scheduler then scores all feasible nodes, including node1 and any untainted nodes, so placement is not forced. This is why dedicated-node patterns usually combine a taint with node affinity or a node selector to attract the intended workload. Without affinity, the Pod may land elsewhere.
Go deeper
Related to this question
About these practice questions
Courseiva writes every KCNA question from scratch — 930 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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CNCF exam blueprint
This KCNA 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 KCNA exam.