CKA Workloads and Scheduling Practice Question
You need to schedule a pod on a node with label 'disktype=ssd'. Which field should you add to the pod spec?
⚠ Common exam trap
A common mix-up: candidates confuse `nodeSelector` with `nodeAffinity` or `tolerations`, thinking that `nodeAffinity` is always required for label-based scheduling, or that `tolerations` can select nodes by labels, when in fact `nodeSelector` is the simplest and correct field for a single label match.
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
✓
nodeSelector
The `nodeSelector` field in a Pod spec is the simplest and most direct way to constrain a Pod to nodes that have a specific label. By setting `nodeSelector` with `disktype: ssd`, the scheduler will only consider nodes that have the label `disktype=ssd` for placement. This is a hard constraint that does not require any additional configuration on the nodes.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
nodeSelector
Why this is correct
The nodeSelector field is the simplest and most direct mechanism to constrain a Pod to run on nodes with specific labels. By specifying the key-value pair disktype: ssd under this field in the Pod specification, the Kubernetes scheduler filters out any nodes lacking this exact label, ensuring the Pod is only placed on a matching SSD-backed node.
- ✗
tolerations
Why it's wrong here
Tolerations are applied to Pods to allow them to schedule onto nodes with matching taints, which are designed to repel Pods rather than attract them. They do not select nodes based on standard node labels like disktype=ssd, and using them alone will not force a Pod onto a specific labeled node.
- ✗
nodeName
Why it's wrong here
The nodeName field bypasses the Kubernetes scheduler entirely to bind a Pod directly to a single, specific node identified by its unique hostname. This hardcoded approach does not evaluate node labels and is highly discouraged in production because it breaks if the specific node becomes unavailable or is recreated with a different name.
- ✗
affinity.nodeAffinity
Why it's wrong here
`affinity.nodeAffinity` is incorrect because `nodeSelector` is the direct and simplest field for mandatorily scheduling a pod onto nodes matching a specific, simple label key-value pair. While `nodeAffinity` also uses node labels for scheduling, it is designed for more advanced or flexible requirements, such as expressing soft preferences via `preferredDuringSchedulingIgnoredDuringExecution`, or complex mandatory rules using operators like `In` or `Exists` within `requiredDuringSchedulingIgnoredDuringExecution`. It would be the correct choice for such sophisticated node selection logic.
Go deeper
Related to this question
About these practice questions
One of 726 original CKA 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 CKA 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 CKA exam.