CKA Workloads & Scheduling Practice Question
A Kubernetes cluster has a deployment with 3 replicas. After a node failure, you notice that only 2 pods are running, and the deployment has not rescheduled the missing pod. What is the most likely cause?
⚠ Common exam trap
Candidates often assume a deployment immediately reschedules pods after a node failure, but the CKA tests knowledge of the node controller's eviction timeout and the fact that the ReplicaSet controller waits for pod eviction before creating replacements.
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
✓
The node controller has not yet evicted the pod
When a node fails, the node controller marks the node as `NodeReady=False` and waits for a configurable timeout (`pod-eviction-timeout`, default 5 minutes) before evicting pods. Until eviction, the deployment's ReplicaSet sees the pod as still existing (though on an unreachable node) and does not create a replacement. Option C correctly identifies that the node controller has not yet evicted the pod, which is the default behavior.
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 deployment has a resource quota that prevents new pods
Why it's wrong here
If a ResourceQuota limit were reached in the namespace, the API server would reject the creation of any new Pods entirely. However, this does not explain why a specific third replica remains in an unevicted state on a failed node while the deployment controller is still expecting three replicas. Furthermore, a quota violation would trigger a ReplicaSet event indicating a failure to create the pod, rather than leaving the existing pod bound to the dead node.
- ✗
The pod's terminationGracePeriodSeconds is set to 0
Why it's wrong here
Setting terminationGracePeriodSeconds to 0 forces immediate deletion of the pod from the API server once the deletion signal is received. This configuration accelerates the rescheduling process rather than delaying it, as it bypasses the standard graceful shutdown window. It cannot cause a pod to linger on an unresponsive node before eviction is initiated by the control plane.
- ✓
The node controller has not yet evicted the pod
Why this is correct
When a node becomes unreachable, the node controller waits for a default grace period of five minutes (configured via the --pod-eviction-timeout flag) before marking the pods for eviction. During this window, the control plane keeps the pods in a Terminating or Unknown state on the failed node and does not reschedule them. Only after this timeout expires will the deployment controller spin up a replacement pod on a healthy node.
- ✗
The deployment's replicas field is set to 2
Why it's wrong here
The scenario explicitly states that the deployment is configured with 3 replicas. If the replicas field in the deployment specification were actually set to 2, the controller would only maintain two running pods under normal conditions. This mismatch does not explain why a third pod exists but is failing to reschedule after a node failure.
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
This CKA question is part of Courseiva's 726-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.