KCNA Kubernetes Fundamentals Practice Question
You are reviewing the manifest for a Pod that must only run on nodes with the label `disktype=ssd`. The manifest includes the following snippet:
```yaml nodeSelector: disktype: ssd ```
After applying the manifest, the Pod remains in Pending state indefinitely. `kubectl get nodes --show-labels` shows no node has the `disktype=ssd` label. Which action will allow the Pod to be scheduled without modifying the Pod's nodeSelector?
⚠ Common exam trap
Test-takers frequently confuse taints, annotations, or empty selectors with labels, when nodeSelector strictly matches node labels.
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
✓
Add the label `disktype=ssd` to at least one node using `kubectl label nodes <node-name> disktype=ssd`.
A Pod with nodeSelector only lands on nodes whose labels match every specified key-value pair. Because no node currently has `disktype=ssd`, the scheduler cannot find a feasible node and the Pod stays Pending. Labeling an appropriate node with that exact pair makes it feasible, allowing scheduling without altering the Pod manifest. The other actions either use the wrong metadata type or change the Pod spec.
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 an annotation `disktype=ssd` to a node with `kubectl annotate nodes <node-name> disktype=ssd`.
Why it's wrong here
Annotations are non-identifying metadata and are not considered by the scheduler when evaluating nodeSelector. Only labels participate in node selection. Adding an annotation with the same key-value pair will not make the node eligible, so the Pod would remain Pending. The correct mechanism is to apply a label, not an annotation.
- ✗
Edit the Pod's nodeSelector to an empty map so it matches any node, then reapply the manifest.
Why it's wrong here
Removing the nodeSelector would indeed allow scheduling on any node, but the scenario explicitly asks for an action that does not modify the Pod's nodeSelector. This option requires changing the Pod spec, so it fails the stated constraint. It also abandons the intended placement on SSD nodes rather than satisfying it.
- ✗
Create a taint on a node with `kubectl taint nodes <node-name> disktype=ssd:NoSchedule` so the scheduler treats it as matching.
Why it's wrong here
Taints are used to repel Pods, not to satisfy nodeSelector requirements. Adding a taint with NoSchedule would make the node less available to Pods and would not cause the scheduler to match `disktype=ssd`. This action would worsen the scheduling problem and never place the Pod on that node based on the selector.
- ✓
Add the label `disktype=ssd` to at least one node using `kubectl label nodes <node-name> disktype=ssd`.
Why this is correct
The scheduler filters nodes using the Pod's nodeSelector, and no node currently carries the `disktype=ssd` label, so the Pod stays Pending. Labeling a suitable node with that exact key and value makes it eligible, and the scheduler will bind the Pod there without editing the Pod spec. This is the intended way to satisfy a nodeSelector requirement.
About these practice questions
One of 930 original KCNA 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 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.