CKA Workloads and Scheduling Practice Question
You have a PriorityClass 'high-priority' with value 1000 and 'low-priority' with value 100. A pod A with 'high-priority' is pending because the node has no resources. A pod B with 'low-priority' is running on that node. What will happen if preemption is enabled?
⚠ Common exam trap
Candidates often assume preemption requires manual configuration or is disabled by default, but Kubernetes enables preemption by default in the scheduler, and the scheduler automatically handles eviction without administrator intervention.
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
✓
Pod B will be preempted (evicted) to allow pod A to be scheduled on the node
When preemption is enabled, the Kubernetes scheduler can evict lower-priority pods to free resources for pending higher-priority pods. In this scenario, Pod A (priority 1000) is pending due to insufficient resources, while Pod B (priority 100) is running on the node. The scheduler will preempt (evict) Pod B to allow Pod A to be scheduled, as the priority difference is significant and preemption is enabled by default in Kubernetes (via the 'PrioritySort' and 'Preemption' plugins).
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Pod A will be scheduled only after pod B completes its work
Why it's wrong here
This statement is incorrect because Kubernetes' preemption mechanism is specifically designed to prevent higher-priority pods from waiting. Instead of waiting for Pod B to naturally complete its execution and release resources, the kube-scheduler will actively identify Pod B as a candidate for eviction. This ensures that the critical Pod A, with its higher priority, gains immediate access to the necessary node resources without delay, overriding a simple FIFO scheduling approach.
- ✗
Pod A will remain pending because preemption is not enabled by default
Why it's wrong here
This option is false because preemption is a fundamental and enabled-by-default feature of the Kubernetes kube-scheduler. The scheduler continuously evaluates pending pods and, if a higher-priority pod cannot be scheduled due to resource constraints, it automatically initiates the preemption process. There is no special configuration or manual intervention required to activate this behavior, making the premise of preemption not being enabled by default incorrect.
- ✗
The cluster administrator must manually delete pod B to allow pod A to schedule
Why it's wrong here
This option is incorrect as it fundamentally misrepresents the automated nature of Kubernetes preemption. The kube-scheduler is specifically designed to handle resource contention by identifying lower-priority pods that occupy resources needed by a higher-priority pod and then automatically triggering their eviction. Manual intervention by a cluster administrator to delete Pod B would bypass this built-in automation, which is designed for efficient and self-managing resource allocation.
- ✓
Pod B will be preempted (evicted) to allow pod A to be scheduled on the node
Why this is correct
This is the correct behavior. When Pod A, possessing a higher priority, cannot find a node with sufficient available resources, the kube-scheduler will identify a node where Pod B (a lower-priority pod) is running and whose eviction would free up the necessary resources. The scheduler then initiates the preemption process, which involves evicting Pod B from that node. This action frees up the required resources, allowing Pod A to be successfully scheduled and started on the now-available node.
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
This CKA question is part of Courseiva's 302-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.