Courseiva
Workloads and Scheduling →mediumMultiple Choice

CKA Workloads and Scheduling Practice Question

You need to schedule a pod to a specific node named 'worker-2' for testing purposes. Which field should you set in the pod spec?

⚠ Common exam trap

CNCF often tests the distinction between `nodeSelector` (label-based scheduling) and `nodeName` (direct assignment), leading candidates to choose `nodeSelector` when the question explicitly requires a specific node name.

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

✓

nodeName

The `nodeName` field in the PodSpec directly assigns the pod to a specific node by name, bypassing the scheduler entirely. Setting `nodeName: worker-2` forces the kubelet on that node to run the pod, making it the correct choice for pinning a pod to a specific node for testing.

Answer analysis

Option-by-option breakdown

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

  • ✗

    schedulerName

    Why it's wrong here

    schedulerName only selects which scheduler process evaluates the pod for placement (e.g., my-custom-scheduler). The built-in kube-scheduler and any custom scheduler still decide the node using predicates and priorities; schedulerName does not bypass scheduling logic or pin the pod to a specific node. Unless you set nodeName, the pod remains unscheduled until a scheduler selects it.

  • ✗

    affinity

    Why it's wrong here

    Affinity rules, especially nodeAffinity, use label selectors to constrain feasible nodes but do not bypass the scheduler. You can require a node with a label owned by worker (e.g., kubernetes.io/hostname=worker), yet this is still label-based matching executed during scheduling. nodeAffinity is a soft or hard preference, not a direct pointer to a node object; the scheduler must still select a matching node and the pod is not instantaneously tied to a name.

  • ✗

    nodeSelector

    Why it's wrong here

    nodeSelector is a simple label-based constraint that limits scheduling to nodes carrying all specified labels. It never references the node's name field; while a node's hostname is typically exposed as a label (kubernetes.io/hostname), using nodeSelector with that label is indirect and requires the scheduler to match it. nodeSelector cannot force placement when no node is labeled, and it does not modify the pod's nodeName field.

  • ✓

    nodeName

    Why this is correct

    nodeName is the only field that directly assigns a pod to a specific node by its exact Node resource name. When nodeName is set, the kubelet on that node sees the pod in the API server and attempts to run it, completely bypassing the scheduling process. This is a hard assignment: the pod will never be scheduled elsewhere, and if the node does not exist or is not ready, the pod stays Pending or fails.

About these practice questions

This CKA question is part of Courseiva's 726-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 →

How Courseiva writes practice questions · Editorial policy

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.