CKA Workloads and Scheduling Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  The pod will never be preempted by other pods

  Why it's wrong here

  This statement is incorrect because preemption is not absolute based on priority alone. A pod with a high-priority PriorityClass can still be preempted by another pod whose PriorityClass has an even higher numeric value, since the scheduler always admits or preempts according to the highest priority first. In fact, preemption is explicitly triggered when a pending pod's priority exceeds that of pods already running on the node, so unless your pod has the highest possible priority in the cluster, it remains vulnerable to preemption by higher-priority workloads.

• ✗

  The pod will be scheduled only after all lower-priority pods have been scheduled

  Why it's wrong here

  This is false because the Kubernetes scheduler does not serialize pod scheduling in a strict lower-priority-first order. Instead, the scheduling queue is sorted by priority, so higher-priority pods are processed and placed before lower-priority ones, which can cause lower-priority pods to wait for resources. Higher-priority pods can also preempt running lower-priority pods to get resources immediately, meaning lower-priority pods are not a barrier; they are victims of resource reclamation, not prerequisites.

• ✓

  The pod may preempt lower-priority pods to be scheduled

  Why this is correct

  Correct. When a pod carries a high-priority PriorityClass, the scheduler treats it as eligible for preemption: if the pod cannot be placed on any node because of insufficient resources, the scheduler identifies nodes running pods with lower priorities and evicts those lower-priority pods to free capacity for the pending high-priority pod. This is governed by the preemptionPolicy field in the PriorityClass, which defaults to PreemptLowerPriority, and the actual eviction is performed through the PodDisruptionBudget-aware API, though critical pods may be protected if they have higher priority or are in terminating state.

• ✗

  The pod will be assigned a higher CPU priority in the kernel

  Why it's wrong here

  This is a common misconception. Kubernetes PriorityClass does not map to OS-level nice values, CPU shares, or any kernel scheduling priority for container processes. It only affects the Kubernetes scheduler's ordering and preemption decisions within the cluster control plane. Actual CPU resource allocation is controlled by requests, limits, and QoS classes (Guaranteed, Burstable, BestEffort), which translate into cgroup shares and CFS quotas in the kernel, not by the PriorityClass value.

Go deeper

Related to this question