KCNA Container Orchestration Practice Question
A developer wants to ensure that a pod runs only on nodes with SSDs. Which mechanism should be used?
⚠ Common exam trap
Test-takers frequently confuse taints/tolerations with node selection, thinking they can be used to force pods onto specific hardware, when in fact taints repel pods and tolerations allow exceptions, whereas `nodeSelector` or `nodeAffinity` are the correct tools for positive selection.
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 disktype: ssd
`nodeSelector` is a simple and direct mechanism in Kubernetes to constrain a pod to run only on nodes that have a specific label, such as `disktype=ssd`. By labeling nodes with SSDs and adding the corresponding `nodeSelector` in the pod spec, the scheduler ensures the pod is placed exclusively on those nodes. This approach is straightforward and does not require complex scheduling constraints or resource management.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Apply a taint to nodes without SSDs and add tolerations to the pod
Why it's wrong here
Taints repel pods from nodes lacking SSDs, but tolerations merely permit scheduling onto tainted nodes; they do not attract the pod to SSD nodes. The pod could still land on any untainted node. Node affinity selecting the SSD label is the mechanism that actually constrains placement to those nodes.
- ✗
Use pod anti-affinity
Why it's wrong here
Pod anti-affinity repels a pod from nodes already running pods matching a label selector; it expresses separation between pods, not a requirement for node hardware attributes. It cannot select SSD-equipped nodes. Node affinity, matching a node label such as disktype=ssd, is the mechanism that binds the pod to SSD nodes.
- ✓
Add a nodeSelector with disktype: ssd
Why this is correct
A nodeSelector matches pod scheduling to node labels, so labelling SSD nodes with disktype: ssd and declaring that selector in the pod spec confines the workload to those nodes. This directly satisfies the stem's requirement that the pod run only on SSD-backed nodes, using Kubernetes' built-in label-based scheduling constraint.
- ✗
Define a ResourceQuota
Why it's wrong here
ResourceQuota caps aggregate namespace consumption of CPU, memory, storage and object counts; it never influences which node a pod schedules onto. It is tempting because quotas relate to resources, but they govern quantity limits, not placement. Node affinity on an SSD label is what constrains scheduling to SSD nodes.
Go deeper
Related to this question
About these practice questions
This KCNA question is part of Courseiva's 930-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.