KCNA Kubernetes Fundamentals Practice Question
A cluster administrator wants to ensure that a specific pod only runs on nodes that have an SSD for local storage. The nodes with SSDs have the label 'disk-type: ssd'. How should the administrator configure the pod to enforce this constraint?
⚠ Common exam trap
Many exam-takers confuse tolerations (for taints) with node selectors (for labels), or think annotations or probes can influence scheduling, when only `nodeSelector` or node affinity directly control node placement based on 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 a nodeSelector with 'disk-type: ssd' to the pod spec
The `nodeSelector` field in a Pod spec is the standard Kubernetes mechanism for constraining a Pod to run only on nodes that match specific labels. By setting `nodeSelector: { disk-type: ssd }`, the scheduler will ensure the Pod is placed exclusively on nodes with that label, enforcing the administrator's requirement.
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 a toleration for node.kubernetes.io/disk-type: ssd
Why it's wrong here
Tolerations only permit a pod to schedule onto nodes already tainted; they do not select nodes by label, so this cannot enforce SSD placement. It is tempting because tolerations and node selection are both scheduling controls, and a toleration would be correct to allow scheduling onto a tainted SSD node.
- ✓
Add a nodeSelector with 'disk-type: ssd' to the pod spec
Why this is correct
A nodeSelector with `disk-type: ssd` in the pod spec makes the scheduler place the pod only on nodes carrying that exact label, directly satisfying the SSD constraint. Unlike taints, tolerations or affinity, nodeSelector is a hard requirement evaluated at scheduling time, so pods stay Pending rather than landing on non-SSD nodes.
- ✗
Use a readiness probe to check for SSD
Why it's wrong here
A readiness probe only gates traffic to a running container; it cannot influence which node the scheduler picks, so the pod may still land on non-SSD nodes. It is tempting because probes verify node capabilities, and a probe would be correct to confirm an SSD is mounted before serving traffic.
- ✗
Add an annotation 'disk-type: ssd' to the pod
Why it's wrong here
Annotations are metadata for tooling and are ignored by the scheduler, so they cannot constrain pod placement to SSD nodes. It is tempting because labels and annotations look similar, and an annotation would be correct for recording non-identifying information such as a build reference.
Go deeper
Related to this question
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 by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.