KCNA Container Orchestration Practice Question
A cluster administrator needs to run a Pod that requires access to a raw block device on a specific node. The Pod must be scheduled only on nodes labeled disktype=ssd, and it must tolerate a taint hardware=gpu:NoSchedule that exists on those nodes. Which combination of Pod spec fields is required?
⚠ Common exam trap
The trap here is thinking that a toleration alone attracts a Pod to a tainted node, when it only permits scheduling on such nodes.
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: disktype=ssd and tolerations for hardware=gpu:NoSchedule
The Pod needs both a node selection mechanism and a toleration. nodeSelector with disktype=ssd restricts scheduling to labeled nodes, and the toleration for hardware=gpu:NoSchedule allows placement on those tainted nodes. Neither alone is sufficient: without the selector, the Pod could land on non-SSD nodes; without the toleration, the taint would block scheduling.
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: disktype=ssd and tolerations for hardware=gpu:NoSchedule
Why this is correct
nodeSelector restricts scheduling to nodes with the matching label, and the toleration allows the Pod to be placed on nodes tainted with hardware=gpu:NoSchedule. Both are required because the label narrows the candidate nodes and the toleration prevents the taint from repelling the Pod. This combination satisfies the scheduling constraints.
- ✗
tolerations for hardware=gpu:NoSchedule and podAntiAffinity against disktype=ssd
Why it's wrong here
A toleration only allows the Pod to be scheduled onto tainted nodes; it does not select nodes by label. Pod anti-affinity against disktype=ssd would actively avoid the desired nodes. This combination neither targets the SSD-labeled nodes nor correctly uses affinity semantics for the requirement.
- ✗
nodeName set to the specific node name and tolerations for hardware=gpu:NoSchedule
Why it's wrong here
Setting nodeName bypasses the scheduler and pins the Pod to one named node, which does not generalize to any node labeled disktype=ssd. While the toleration is correct, nodeName is a static binding and ignores labels. This approach fails if the node is replaced or if multiple SSD nodes should be eligible.
- ✗
affinity: nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution for disktype=ssd, and no tolerations
Why it's wrong here
Node affinity can enforce the disktype=ssd label, but without a matching toleration the Pod cannot be scheduled onto nodes that carry the hardware=gpu:NoSchedule taint. The taint would repel the Pod regardless of affinity rules. This option fails because it omits the required toleration.
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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CNCF exam blueprint
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.