CKA Workloads and Scheduling Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Adding a taint with effect NoSchedule to a node

  Why this is correct

  A NoSchedule taint on a node instructs the Kubernetes scheduler to exclude any Pod that does not have a matching toleration from being placed onto that node. It is a hard scheduling constraint: the scheduler will not assign new Pods to that node unless the Pod's toleration matches the taint's key, value, and effect. However, Pods already running on the node are not evicted by this effect, so it is useful for cordoning off nodes for maintenance without disrupting workloads.

• ✗

  Adding a toleration to a pod to prevent it from being scheduled on certain nodes

  Why it's wrong here

  Tolerations are a permissive scheduling mechanism; when a Pod has a toleration for a taint, it merely becomes eligible to be scheduled onto a tainted node, but it does not block scheduling onto any node. Adding a toleration to a Pod cannot prevent that Pod from landing on certain nodes, because tolerations never create a negative constraint — to force a Pod away from specific nodes, you would need nodeSelector or node affinity rules with requiredDuringSchedulingIgnoredDuringExecution semantics. Confusing tolerations with anti-affinity is common, but they work in opposite directions: tolerations open doors, they do not close them.

• ✓

  Adding a taint with effect PreferNoSchedule to a node

  Why this is correct

  A PreferNoSchedule taint is a soft version of NoSchedule; the scheduler attempts to avoid placing Pods that lack a matching toleration onto that node, but it treats that as a preference rather than a hard guarantee. If the cluster is under resource constraints and no other suitable node has capacity, the scheduler is allowed to place a non-tolerating Pod onto the tainted node. This effect is often used for cost optimization or to nudge workloads toward dedicated node pools without making it impossible to schedule elsewhere.

• ✗

  Applying a nodeSelector to a pod to match node labels

  Why it's wrong here

  A nodeSelector is a Pod-level label-based restriction that constrains which nodes the scheduler may consider; the Pod is only scheduled on nodes whose labels match those specified in the nodeSelector. It is a form of node affinity and, unlike taints and tolerations, it is selective only about node labels, not about administratively marking a node as 'tainted.' While it does restrict scheduling, it is not a taint/toleration mechanism and therefore does not answer a question about using taints to control scheduling; the correct three answers are taint effects.

• ✓

  Adding a taint with effect NoExecute to a node

  Why this is correct

  A NoExecute taint is the most aggressive effect: it both prevents any new Pods that do not tolerate it from being scheduled onto the node and evicts any otherwise-running Pods on the node that lack a matching toleration. Because of this eviction action, it is typically used for node failures or sudden maintenance where you need to clear a node immediately. Pods that do tolerate the taint may include a tolerationSeconds field to control how long they can remain on the node before being evicted, allowing graceful drain behavior.

Go deeper

Related to this question