KCNA Kubernetes Fundamentals Practice Question
Which THREE of the following are valid ways to assign a pod to a specific node? (Choose three.)
⚠ Common exam trap
Candidates often confuse direct node assignment (nodeName) with scheduling constraints (nodeSelector, nodeAffinity). ServiceAccount and clusterName do not affect node placement.
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
✓
Setting the 'nodeName' field in the pod spec
Option A is correct because setting the 'nodeName' field directly in the pod spec bypasses the scheduler and binds the pod to that exact node by name. Option B is correct because 'nodeAffinity' rules under 'affinity' let the scheduler place the pod on nodes matching label expressions, including required and preferred constraints. Option C is correct because 'nodeSelector' matches node labels and constrains the scheduler to only nodes carrying the specified labels. Option D is not a placement mechanism; a ServiceAccount provides an identity for pods to authenticate to the API server, not to select a node. Option E is invalid because 'clusterName' is not a pod spec field used for node assignment and has no scheduling effect.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Setting the 'nodeName' field in the pod spec
Why this is correct
Setting nodeName directly bypasses the scheduler, binding the Pod to that named node at creation. It satisfies the requirement for assigning a Pod to a specific node, though it skips scheduling checks such as resource fit and taints.
- ✓
Using 'affinity' with 'nodeAffinity' rules
Why this is correct
nodeAffinity rules match node labels through requiredDuringSchedulingIgnoredDuringExecution or preferred variants, letting the scheduler place the Pod on qualifying nodes. This satisfies the requirement for assigning a Pod to a specific node while retaining normal scheduling evaluation.
- ✓
Using 'nodeSelector' with label matching
Why this is correct
Labels applied to nodes are matched by the pod's nodeSelector field, so the scheduler only places the pod on nodes carrying those exact labels. This directly satisfies the requirement to pin a pod to a specific node through declarative label matching.
- ✗
Using a ServiceAccount
Why it's wrong here
A ServiceAccount supplies an identity for API access and image-pull credentials; it carries no scheduling instructions, so the scheduler never reads it when placing pods. ServiceAccounts are the right mechanism when a workload needs scoped permissions to the Kubernetes API or a private registry.
- ✗
Setting the 'clusterName' field
Why it's wrong here
clusterName merely labels which cluster a kubeconfig context refers to; it is not a pod spec scheduling field, so the scheduler ignores it entirely. It is used in kubeconfig files to distinguish contexts when you administer several clusters from one machine.
Go deeper
Related to this question
About these practice questions
Courseiva writes every KCNA question from scratch — 930 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
2 more ways this is tested on KCNA
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Which TWO of the following are valid ways to assign a pod to a specific node?
medium- ✓ A.nodeSelector
- B.affinity: nodeAntiAffinity
- C.tolerations
- ✓ D.nodeName
- E.podSelector
Why A: Option A (nodeSelector) is correct because it is a field in the pod spec that matches against node labels, causing the scheduler to place the pod only on nodes carrying the specified label key/value pairs. Option D (nodeName) is correct because setting spec.nodeName bypasses the scheduler entirely and directly binds the pod to the named node, which is a valid (if low-level) way to assign a pod to a specific node. Option B (affinity: nodeAntiAffinity) is incorrect because node anti-affinity repels pods from nodes matching certain labels rather than assigning a pod to a specific node. Option C (tolerations) is incorrect because tolerations only allow a pod to be scheduled onto nodes with matching taints; they do not target a specific node. Option E (podSelector) is incorrect because podSelector is used in resources like NetworkPolicy, PodDisruptionBudget, and topology spread constraints to select pods, not to assign a pod to a node.
Variation 2. Which Kubernetes resource can be used to assign a pod to a specific node?
hard- ✓ A.Node affinity rules in the pod spec
- B.A NetworkPolicy
- C.A Service account
- D.A ConfigMap
Why A: Node affinity rules in the pod spec are a set of constraints that define which nodes a pod can be scheduled on, based on node labels. This is a native Kubernetes scheduling feature that allows you to attract pods to specific nodes using required or preferred matching rules, such as `requiredDuringSchedulingIgnoredDuringExecution`. This directly answers the question of assigning a pod to a specific node.
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.