KCNA Kubernetes Fundamentals Practice Question
You need to ensure that a pod runs on a specific node that has an SSD. The node has the label 'disktype=ssd'. How should you configure the pod to target this node?
⚠ Common exam trap
Candidates often confuse `nodeSelector` with `nodeAffinity` or `tolerations`, thinking that tolerations can select nodes, when in fact tolerations only allow scheduling on tainted nodes and do not enforce placement on a specific label.
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
✓
Set spec.nodeSelector with disktype: ssd.
`spec.nodeSelector` is the simplest and most direct way to constrain a Pod to run only on nodes that have a specific label. By setting `disktype: ssd` in the nodeSelector, the scheduler will only consider nodes with that exact label key-value pair, ensuring the Pod lands on an SSD-equipped node.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Set spec.affinity.nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution.
Why it's wrong here
Node affinity with `requiredDuringSchedulingIgnoredDuringExecution` enforces scheduling only on nodes matching the `disktype=ssd` label, but it does not guarantee that the pod runs exclusively on that specific node if multiple nodes share the label. The scenario requires targeting a single node, which demands `nodeName` or a unique label match. This option is tempting because it correctly uses label-based scheduling for pods needing SSD storage, and would be correct if the goal were to schedule onto any node with the label rather than a particular node.
- ✓
Set spec.nodeSelector with disktype: ssd.
Why this is correct
Setting `spec.nodeSelector` with `disktype: ssd` makes the scheduler filter candidate nodes by their existing labels, so the pod lands only on nodes carrying that exact key-value pair. This directly satisfies the stem's requirement to target the SSD-labelled node, since nodeSelector is the native, simplest label-based placement constraint in Kubernetes.
- ✗
Set spec.tolerations with key=disktype, value=ssd.
Why it's wrong here
Tolerations only permit a pod to schedule onto a node already tainted with a matching key, value and effect; they do not select nodes. The node here is labelled, not tainted, so no scheduling constraint is applied. Tolerations would be correct for evicting pods off a tainted node.
- ✗
Set spec.nodeName to the node's name.
Why it's wrong here
nodeName bypasses the scheduler entirely and hard-codes one node, so it cannot follow the disktype=ssd label if nodes are replaced or rescheduled. nodeSelector matches that label and lets the scheduler place the pod. nodeName suits static, single-node test setups only.
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 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.