KCNA Kubernetes Fundamentals Practice Question
A platform team needs to ensure that a critical StatefulSet pod always runs on a specific node that has local NVMe storage. The node is labeled `disktype=nvme`. Which Kubernetes scheduling mechanism should they use to guarantee this placement?
⚠ Common exam trap
Watch out — candidates often confuse taints and tolerations with node selection: tolerations only allow a pod to be scheduled on a tainted node, but they do not require the pod to go there.
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
✓
nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution
The requirement is a guaranteed placement on a node with a specific label. nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution enforces a hard rule that the pod must be scheduled on a node matching the label selector. This is the standard, declarative way to pin pods to nodes based on labels, and it works well with StatefulSets. Other options either provide only soft preferences, do not attract pods, or bypass the scheduler in a non-idiomatic way.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution
Why this is correct
This is correct because requiredDuringSchedulingIgnoredDuringExecution enforces a hard constraint: the pod will only be scheduled on a node matching the specified label selector. In this scenario, the team can specify a nodeAffinity rule requiring the label disktype=nvme, ensuring the StatefulSet pod always lands on the node with local NVMe storage. This satisfies the guarantee requirement without manual intervention.
- ✗
Taints and tolerations on the node
Why it's wrong here
Taints and tolerations allow a node to repel pods that do not tolerate its taint, but they do not attract pods to a specific node. A toleration only permits scheduling; it does not require the pod to run on that node. Without additional affinity rules, the pod could be scheduled elsewhere, so this mechanism alone cannot guarantee placement on the NVMe node.
- ✗
nodeName field in the Pod spec
Why it's wrong here
Setting nodeName bypasses the scheduler entirely and forces the pod onto a specific node by name. While it guarantees placement, it is brittle and not recommended for StatefulSets because it breaks if the node is renamed or replaced. It also ignores label-based selection, so it does not use the disktype=nvme label and is not the appropriate mechanism here.
- ✗
podAffinity with preferredDuringSchedulingIgnoredDuringExecution
Why it's wrong here
podAffinity co-locates pods based on labels of other pods, not nodes. Even with preferredDuringSchedulingIgnoredDuringExecution, it is only a soft preference and does not guarantee placement. This does not directly target the node with the disktype=nvme label and would not enforce the requirement, so it fails the scenario's need for a guaranteed node assignment.
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.