CKA Workloads & Scheduling Practice Question
You are a platform engineer managing a Kubernetes cluster with 5 worker nodes (node1-node5). The cluster runs a mix of stateless web services and stateful databases. Users report that a critical database Pod (part of a StatefulSet) is frequently evicted during node maintenance. The StatefulSet has a single replica. You need to improve the availability of this database Pod. The current configuration: the Pod has resource requests (2 CPU, 4Gi memory) and limits (4 CPU, 8Gi memory). The cluster uses the default scheduler with no custom policies. Nodes have varying capacities: node1 and node2 have 8 CPU/32Gi memory, node3-node5 have 4 CPU/16Gi memory. During rolling node reboots, the database Pod gets evicted and takes a long time to reschedule because no node has enough resources. What should you do to minimize downtime and ensure the Pod is rescheduled promptly after eviction?
⚠ Common exam trap
CNCF often tests the distinction between disruption budgets (which prevent eviction) and priority/preemption (which ensure rescheduling after eviction), leading candidates to mistakenly choose PDB when the real issue is resource contention after eviction.
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
✓
Assign a high priority class to the database Pod.
Assigning a high priority class (Option C) ensures that when the database Pod is evicted during node maintenance, the scheduler treats it as a higher-priority workload than other Pods. This allows it to preempt lower-priority Pods on nodes with sufficient capacity (e.g., node1 or node2), even if those nodes appear fully allocated, thereby minimizing downtime and ensuring prompt rescheduling.
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 nodeAffinity to prefer node1 and node2.
Why it's wrong here
Adding nodeAffinity to prefer specific nodes like node1 and node2 only influences the Kubernetes scheduler's preference or requirement for placing the Pod. It does not guarantee that the specified nodes will have sufficient available resources, nor does it enable the Pod to preempt other workloads if resources are scarce. Furthermore, during maintenance or high load, even preferred nodes might become unavailable or fully utilized, preventing the database Pod from being scheduled quickly.
- ✗
Create a PodDisruptionBudget with minAvailable: 1.
Why it's wrong here
Creating a PodDisruptionBudget (PDB) with `minAvailable: 1` is designed to protect applications from voluntary disruptions, such as node drains or cluster upgrades, by ensuring a minimum number of Pods remain running. However, a PDB does not influence the initial scheduling process or help a Pod get scheduled faster if it's struggling to find resources. It also offers no protection or acceleration for involuntary disruptions or when a critical Pod simply cannot find a suitable node to begin with.
- ✓
Assign a high priority class to the database Pod.
Why this is correct
Assigning a high priority class to the database Pod is the most effective solution for ensuring critical workloads are scheduled promptly. When the scheduler attempts to place a high-priority Pod and cannot find a node with sufficient resources, it will actively preempt (evict) lower-priority Pods from existing nodes to free up the necessary capacity. This mechanism directly addresses resource contention, significantly reducing the scheduling delay for essential applications like a database.
- ✗
Increase the resource requests to match the limits.
Why it's wrong here
Increasing the resource requests to match the limits means the Kubernetes scheduler will require a larger, more specific block of resources to be available on a node before it can place the Pod. While resource requests define the guaranteed minimum, making them equal to limits makes the Pod's resource footprint more rigid and demanding. This rigidity can make it significantly harder for the scheduler to find a suitable node, especially in a busy or fragmented cluster, thereby increasing scheduling delays rather than alleviating them.
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
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.
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.