KCNA Kubernetes Fundamentals Practice Question
A company wants to ensure that a database pod runs on a node with SSD storage. How should this be achieved?
⚠ Common exam trap
The KCNA exam often tests the distinction between scheduling constraints (nodeSelector/node affinity) and repulsion mechanisms (taints/tolerations), trapping candidates who confuse tolerations as a way to select nodes rather than as a way to bypass node restrictions.
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
✓
Label SSD nodes with 'disk=ssd' and add a nodeSelector to the pod
NodeSelector is a field in the Pod spec that constrains which nodes the Pod can be scheduled on, based on node labels. By labeling nodes with SSD storage as 'disk=ssd' and adding a nodeSelector with that label to the Pod, Kubernetes will only schedule the Pod on nodes that have the matching label, ensuring it runs on SSD storage.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Label SSD nodes with 'disk=ssd' and add a nodeSelector to the pod
Why this is correct
Labelling SSD nodes with `disk=ssd` and adding a matching `nodeSelector` to the pod spec forces the Kubernetes scheduler to bind the database pod only to nodes carrying that label, directly satisfying the SSD-storage placement constraint. Node affinity would also work, but nodeSelector is the simplest mechanism for this exact requirement.
- ✗
Set a resource request for local SSD storage in the pod spec
Why it's wrong here
A resource request declares how much local SSD storage the container needs; the scheduler does not match requests against node hardware attributes, so the pod may still land on a non-SSD node. Requests suit capacity guarantees, not hardware selection, which node affinity or nodeSelector handles.
- ✗
Use pod anti-affinity to avoid non-SSD nodes
Why it's wrong here
Pod anti-affinity only prevents co-location with pods matching a label selector; it cannot detect or exclude nodes lacking SSD hardware. It is tempting because anti-affinity does steer scheduling away from certain targets, and would be correct if the requirement were spreading replicas rather than selecting storage hardware.
- ✗
Add a taint to nodes without SSDs and a toleration to the pod
Why it's wrong here
Taints repel pods unless tolerated, but a toleration only permits scheduling on tainted nodes; it does not require the pod to land on SSD nodes, and untainted non-SSD nodes remain eligible. Taints suit dedicated-node scenarios, such as reserving hardware for a specific workload.
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.