CKA Workloads & Scheduling Practice Question
A cluster administrator wants to ensure that no pods are scheduled on the master node(s). Which approach is the best practice?
⚠ Common exam trap
A common mix-up: candidates confuse `nodeSelector` (a pod scheduling constraint) with node-level restrictions, or think that deleting a node or using resource quotas can control scheduling to a specific node, when only taints (or node affinity with requiredDuringSchedulingIgnoredDuringExecution) provide that node-level control.
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
✓
Add a taint to the master node
Adding a taint to the master node(s) with the `node-role.kubernetes.io/master:NoSchedule` effect is the best practice because it prevents the Kubernetes scheduler from placing any pods on that node unless a pod explicitly tolerates the taint. This ensures that only critical system pods (which include the toleration) can run on the master, keeping it dedicated to cluster control plane operations.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Add a taint to the master node
Why this is correct
Applying a NoSchedule or NoExecute taint to the master (control plane) node ensures that the Kubernetes scheduler will not place any pods on it unless they have a matching toleration. While modern Kubernetes clusters apply this taint by default to protect control plane resources, manually adding or verifying this taint is the standard declarative method to enforce this scheduling restriction.
- ✗
Delete the master node from the cluster
Why it's wrong here
Removing the master node entirely from the cluster is an extreme and destructive action that would dismantle the control plane, rendering the cluster unmanageable. To prevent pod scheduling, administrators must use scheduling constraints like taints rather than deleting critical infrastructure components that run the API server, scheduler, and controller manager.
- ✗
Use a resource quota on the master namespace
Why it's wrong here
ResourceQuotas are admission control policies designed to limit total resource consumption (like CPU, memory, or object counts) within a specific Kubernetes namespace. They operate at the namespace level and cannot influence the scheduler's node-selection decisions or prevent pods from being scheduled onto specific physical or virtual nodes.
- ✗
Set nodeSelector on the master node
Why it's wrong here
The nodeSelector field is a pod specification property used to constrain pods to nodes with particular labels, not a configuration option applied directly to nodes. Attempting to configure a node selector on a node object is syntactically invalid and does not prevent arbitrary pods from being scheduled onto that node.
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
One of 726 original CKA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.