CKA Workloads & Scheduling Practice Question
An administrator wants to ensure that a critical Pod always runs on a node that has an SSD. Which approach should be used?
⚠ Common exam trap
It's easy for candidates to confuse taints and tolerations with node selection, thinking they can force a Pod onto a specific node type, when in fact taints only repel Pods from nodes and require tolerations to allow scheduling, not to guarantee placement on a desired node.
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
✓
Label SSD nodes with 'disk=ssd' and use nodeSelector in the Pod spec.
Using a nodeSelector with a label like 'disk=ssd' ensures that the Pod is scheduled only on nodes that have that specific label, which directly matches the requirement to run the Pod on a node with an SSD. This is the simplest and most reliable method for node-level selection in Kubernetes, as it leverages the scheduler's built-in filtering mechanism.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use podAffinity to prefer nodes running other Pods.
Why it's wrong here
Pod affinity is designed to schedule Pods relative to other Pods based on labels, rather than targeting specific node hardware characteristics like SSDs. Additionally, using a 'preferred' affinity rule (soft affinity) does not guarantee placement, meaning the scheduler could still place the Pod on a non-SSD node if resources are constrained.
- ✗
Set spec.nodeName to an SSD node's name.
Why it's wrong here
Hardcoding a specific node name in spec.nodeName bypasses the Kubernetes scheduler entirely and binds the Pod to that single node. If that specific node fails, undergoes maintenance, or runs out of resources, the Pod will not be rescheduled onto another SSD-capable node, creating a single point of failure.
- ✗
Add a taint to nodes without SSD and add a toleration to the Pod.
Why it's wrong here
Taints and tolerations are used to repel Pods from nodes, not to attract them. While adding a taint to non-SSD nodes prevents this Pod from landing on them, it does not force the scheduler to choose an SSD node over other untainted nodes that might also lack SSDs but aren't tainted.
- ✓
Label SSD nodes with 'disk=ssd' and use nodeSelector in the Pod spec.
Why this is correct
Applying a custom label like 'disk=ssd' to the target nodes and referencing it via nodeSelector in the Pod specification is the standard, declarative way to constrain scheduling. The Kubernetes scheduler will strictly filter out any nodes lacking this label, ensuring the Pod is only scheduled on SSD-equipped hardware.
Go deeper
Related to this question
Learn chapter
Installing Kubernetes with kubeadm
Key term
Ingress Resources
Ingress Resources are Kubernetes API objects that manage external access to services inside a cluster, typically HTTP and HTTPS traffic, by defining rules for routing requests based on hostnames and paths.
Key term
Network Policies
A Kubernetes resource that controls how pods communicate with each other and with other network endpoints, acting as a firewall for pod-to-pod traffic.
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 →
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.