Application Design and Build →mediumMultiple Choice

CKAD Application Design and Build Practice Question

You need to ensure that a Pod always runs on a node with an SSD. Which node selector mechanism should you use?

⚠ Common exam trap

Watch out — candidates often confuse tolerations with node selection, mistakenly thinking tolerations can actively choose nodes, when in fact tolerations only permit scheduling on tainted nodes and do not enforce placement on nodes with specific hardware 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

✓

nodeSelector with a label matching nodes with SSD

`nodeSelector` is the simplest and most direct mechanism for scheduling a Pod onto nodes that possess a specific label, such as `ssd=true`. By labeling nodes that have SSDs and adding the corresponding `nodeSelector` in the Pod spec, Kubernetes ensures the Pod is only scheduled on those nodes. This approach is declarative, requires no additional controllers, and is the recommended method for simple node-level constraints.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Tolerations
Why it's wrong here
Tolerations are applied to pods to allow them to be scheduled onto nodes that have matching taints. They do not express any preference or requirement about node labels or hardware characteristics. A node with an SSD would need a corresponding label and a nodeSelector (or node affinity) to be targeted; a toleration only overrides a taint's restriction, it cannot select a node based on its storage type. Thus, while tolerations might be part of a solution involving tainted nodes, they don't ensure the pod lands on an SSD-equipped node.
✗
Pod affinity
Why it's wrong here
Pod affinity (and anti-affinity) constrain which nodes a pod can be scheduled based on labels of pods already running on those nodes, not based on node labels themselves. It answers questions like "run pods near each other" or "avoid pods from a different team." It cannot directly express "node has SSD" unless you infer that indirectly via other pods, which is unreliable and not the intended mechanism. The correct primitive for node hardware traits is nodeSelector or node affinity with node labels.
✗
nodeName
Why it's wrong here
The nodeName field in a pod spec directly specifies the exact name of a single node where the pod must run. It bypasses the scheduler entirely and does not consider labels, so if you want to select any node that matches a label (e.g., disktype=ssd) across a cluster, nodeName would require you to know the specific node name in advance and manually pin the pod, which is inflexible, fails if that node is unavailable, and doesn't scale. It's a hard constraint to a specific node, not a label-based selection.
✓
nodeSelector with a label matching nodes with SSD
Why this is correct
This is the correct approach. By labeling nodes that have SSDs (e.g., disktype=ssd), you can set pod.spec.nodeSelector to {disktype: ssd}, which directs the scheduler to place the pod only on nodes carrying that label. This is a simple, declarative, and supported mechanism for node-level constraints based on node labels. It works even across multiple nodes and integrates with the scheduler's filtering phase, ensuring the pod runs on an SSD-equipped node as requested.

Go deeper

CKAD Application Design and Build Practice Question

Why each option matters

Option-by-option breakdown

Related to this question