Workloads and Scheduling →mediumMultiple Select

CKA Workloads and Scheduling Practice Question

Which three are valid pod phases?

⚠ Common exam trap

The CKA exam often tests the distinction between pod phases and container states, so the trap here is confusing container-level statuses like CrashLoopBackOff or Terminating with the higher-level pod phase.

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

✓

Pending

Option A (Pending) is a valid pod phase: it means the pod has been accepted by the Kubernetes API server but one or more containers are not yet running, typically because images are still being pulled or scheduling is incomplete. Option C (Succeeded) is valid: it indicates all containers in the pod terminated successfully with exit code 0 and the pod will not be restarted. Option E (Running) is valid: it means the pod has been bound to a node and all containers have been created, with at least one container still running or starting/restarting. The unmarked options do not belong because Terminating is not a pod phase (it is a deletion state reflected in metadata.deletionTimestamp), and CrashLoopBackOff is a container waiting reason, not a pod phase.

Answer analysis

Option-by-option breakdown

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

✓
Pending
Why this is correct
Pending is a valid pod phase defined in the Kubernetes API (PodStatus.phase). A pod enters Pending as soon as the API server records it, but it has not yet been fully accepted by a kubelet: this phase covers scheduling onto a node, pulling container images, and waiting for containers to start. If scheduling fails, the pod can stay Pending indefinitely, and the condition PodScheduled=False typically explains why.
✗
Terminating
Why it's wrong here
Terminating is not a pod phase but rather a transitional state visible in kubectl when a pod has a deletionTimestamp and is being shut down. The official PodPhase values are Pending, Running, Succeeded, Failed, and Unknown; Terminating is a display artifact that occurs while kubelet is sending SIGTERM, executing preStop hooks, and waiting for graceful termination. Once all containers exit, the pod either transitions to Succeeded/Failed or is forcefully removed after the grace period elapses.
✓
Succeeded
Why this is correct
Succeeded is a valid pod phase in the PodStatus.phase field: all containers in the pod have terminated successfully, and the kubelet will not restart them. This phase is typical for job-like workloads, such as a batch process that finishes its work and exits with a zero exit code. Because no further activities occur, the pod remains in the cluster until it is cleaned up by the Job controller or manually deleted.
✗
CrashLoopBackOff
Why it's wrong here
CrashLoopBackOff is a container status condition, not a pod phase. It appears as a reason under the container's waiting state in PodStatus.containerStatuses and indicates that a container repeatedly starts, fails, and is restarted by the kubelet with exponential backoff. The pod itself can still be in the Running or Pending phase, so conflating this container-level detail with the pod-level lifecycle is a common mistake.
✓
Running
Why this is correct
Running is a valid pod phase defined in the Kubernetes API: after the pod has been scheduled to a node, its containers have been created, and at least one container is still in the process of starting or is running. During this phase, the pod is actively executing workloads, and the kubelet continuously performs health checks, restarts failing containers, and reports status updates. If all containers later exit with a non-zero exit code, the phase changes to Failed; with zero exit codes, it changes to Succeeded.

Go deeper

CKA Workloads and Scheduling Practice Question

Why each option matters

Option-by-option breakdown

Related to this question