CKA Troubleshooting 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.

• ✗

  Increase the pod's resource requests

  Why it's wrong here

  Increasing the pod's resource requests is incorrect because the underlying issue is a taint/toleration mismatch, not resource pressure. A lack of resources would generate a different event such as 'Insufficient cpu' or 'Insufficient memory' on the specific node, whereas here the scheduler reports that all nodes have untolerated taints. Raising resource requests would actually make scheduling harder, since it increases the pod's demand on scarce resources without addressing the taint that prevents placement on those nodes.

• ✗

  Remove the taint from the control-plane node

  Why it's wrong here

  Removing the taint from the control-plane node would technically allow the pod to schedule, but it is an antipattern and weakens cluster security. The default control-plane taint (node-role.kubernetes.io/control-plane) exists to keep business workloads off control-plane nodes, and removing it indiscriminately exposes critical cluster infrastructure to arbitrary pods. The preferred and safe approach is to add a toleration to the pod spec so only that pod is explicitly allowed to run on the tainted node, preserving the taint for all other workloads.

• ✗

  Use a different namespace

  Why it's wrong here

  Choosing a different namespace has no effect on taint/toleration behavior because these mechanisms operate at the node and pod level, not the namespace level. Namespaces are logical boundaries for API objects, but the scheduler evaluates node taints against the tolerations present in each Pod's spec; a pod in any namespace is still subject to the same taint unless it carries a matching toleration. Therefore, changing the namespace neither removes the taint nor provides a workaround for the scheduling failure.

• ✓

  Add a toleration to the pod spec matching the taint

  Why this is correct

  Adding a toleration to the pod spec that matches the node's taint is the correct solution because tolerations explicitly opt a pod into scheduling on tainted nodes. The taint on the node uses key, value, and effect (e.g., node-role.kubernetes.io/control-plane:NoSchedule), and the toleration must mirror that key, value, and effect before the scheduler will place the pod there. This is the standard, least-privilege way to run a specific workload on a dedicated or control-plane node without weakening cluster-wide policies.

Go deeper

Related to this question