CKA Workloads and Scheduling Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  spec.nodeName: gpu-node

  Why it's wrong here

  Specifying spec.nodeName directly pins the pod to a particular node by its exact hostname, such as "gpu-node", but this is a literal name, not a label key/value. This approach bypasses the scheduler's label-based filtering entirely and will fail if the node name is misspelled, unavailable, or if the intent is to target any node carrying the GPU label. Moreover, it prevents the pod from being rescheduled to another matching node after a failure, making it an inflexible and non-declarative way to express a node-label constraint.

• ✗

  spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution

  Why it's wrong here

  Pod affinity is designed to schedule pods relative to other pods that are already running, such as "co-locate with pods having the label app=web". It does not evaluate node labels directly, so it cannot require that the node itself has the gpu=true label. While you could indirectly approximate this by referencing pods that happen to run on GPU-labeled nodes, that introduces an unnecessary dependency on existing pod placement and is not the intended mechanism for constraining nodes by their own characteristics.

• ✗

  spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution

  Why it's wrong here

  Node affinity with a requiredDuringSchedulingIgnoredDuringExecution rule can technically enforce the same label-based constraint, because it allows matching on node labels using operators like In or Exists. However, for a single exact key-value match such as gpu=true, nodeAffinity requires writing a YAML block under matchExpressions with a rule and a matchFields, which is far more verbose and less readable than a simple nodeSelector map. Since the question asks for a straightforward way to ensure the node label, nodeSelector is the recommended, more idiomatic choice, even though nodeAffinity is not functionally incorrect.

• ✓

  spec.nodeSelector: { gpu: "true" }

  Why this is correct

  The nodeSelector field provides a concise key-value map that the scheduler uses as a hard constraint for node selection. When you set nodeSelector to { gpu: "true" }, the scheduler will only place the pod on nodes that have the label gpu with the exact value "true". This is entirely label-driven, so it works across any number of GPU-enabled nodes, unlike nodeName, and it is the simplest declarative mechanism for an equality-based node label requirement, requiring no nested API structures.

Go deeper

Related to this question