CKA Workloads & Scheduling Practice Question
You are managing a Kubernetes cluster that hosts a microservices application. One of the services, 'payment-processor', is critical and must always be available. It has a Deployment with 3 replicas, each requesting 1 CPU and 2Gi memory. Recently, the team added a new service 'data-analyzer' that runs as a DaemonSet on all nodes, consuming significant CPU and memory. After the addition, you notice that 'payment-processor' pods are occasionally being evicted, and new pods are slow to be scheduled. You check node resource usage and find that some nodes are overcommitted. You want to ensure that 'payment-processor' pods are never evicted and are scheduled before less critical workloads. Which action should you take?
⚠ Common exam trap
Many candidates confuse taints/tolerations or node affinity with priority and preemption, but those features only affect scheduling placement, not eviction ordering or preemption behavior.
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
✓
Create a PriorityClass with a high value and assign it to the 'payment-processor' Deployment
PriorityClass with a high value ensures that 'payment-processor' pods are considered higher priority than other pods during scheduling and eviction. When nodes are overcommitted, the Kubernetes scheduler will preempt lower-priority pods to make room for higher-priority pods, and the kubelet will evict lower-priority pods first when resources are scarce. This directly addresses the requirement that 'payment-processor' pods are never evicted and are scheduled before less critical workloads.
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 nodes that have low resources and add tolerations only to 'payment-processor' pods
Why it's wrong here
Adding a taint to nodes and tolerations to specific pods primarily controls *where* pods can be scheduled initially. A taint prevents pods without a matching toleration from being placed on that node. However, taints and tolerations do not provide any mechanism to prevent an *already running* pod from being evicted due to resource exhaustion, node unhealthiness, or other operational issues on the node. They are scheduling constraints, not eviction protection.
- ✗
Increase the resource requests for 'payment-processor' pods to guarantee resources
Why it's wrong here
Increasing resource requests for 'payment-processor' pods informs the Kubernetes scheduler about the minimum CPU and memory required, making scheduling stricter. While this might prevent the pod from being scheduled on an already resource-constrained node, it does not prevent eviction of an *already running* pod. If the node's overall allocatable resources become exhausted, or if a higher-priority pod needs to preempt resources, the 'payment-processor' pod can still be evicted, regardless of its requests.
- ✓
Create a PriorityClass with a high value and assign it to the 'payment-processor' Deployment
Why this is correct
Creating a PriorityClass with a high integer value and assigning it to the 'payment-processor' Deployment is the most effective solution. Pods with higher priority are preferentially scheduled by the kube-scheduler. Crucially, if a high-priority 'payment-processor' pod cannot be scheduled due to insufficient resources on any node, the scheduler will attempt to preempt (evict) lower-priority pods on suitable nodes to free up the necessary resources, thereby ensuring the critical workload runs.
- ✗
Use node affinity to ensure 'payment-processor' pods run on dedicated nodes
Why it's wrong here
Node affinity rules, such as `requiredDuringSchedulingIgnoredDuringExecution`, dictate which nodes a pod *can* be scheduled on based on node labels. While using node affinity can ensure 'payment-processor' pods are initially placed on dedicated nodes, it offers no protection against eviction once the pods are running. If the dedicated node itself experiences resource pressure, becomes unhealthy, or if a higher-priority pod needs to be scheduled there, the 'payment-processor' pods could still be evicted.
Go deeper
Related to this question
Learn chapter
Kubernetes Architecture Overview
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.
Key term
DaemonSets
A DaemonSet is a Kubernetes object that ensures a copy of a specific pod runs on every node in a cluster, or on a subset of nodes.
About these practice questions
One of 302 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.