Courseiva
Workloads and SchedulingmediumMultiple ChoiceObjective-mapped

CKA Workloads and Scheduling Practice Question

A pod with an init container that runs a database migration fails. The init container exits with code 1. What is the pod's status?

⚠ Common exam trap

Many candidates confuse the pod phase (Pending, Running, Failed) with the detailed pod status condition (Init:CrashLoopBackOff), and mistakenly choose 'Failed' thinking the init container failure ends the pod, not realizing Kubernetes will retry the init container automatically.

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

Init:CrashLoopBackOff

When an init container exits with a non-zero exit code (code 1), Kubernetes considers the init container to have failed. By default, the pod restarts the init container according to the pod's restart policy (which defaults to Always for pods, but init containers always restart on failure regardless of the pod's restart policy). This repeated failure and restart cycle places the pod in the Init:CrashLoopBackOff status, indicating that the init container is crashing in a loop.

Answer analysis

Option-by-option breakdown

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

  • Init:CrashLoopBackOff

    Why this is correct

    When an init container fails (e.g., exits with a non-zero status code), Kubernetes will restart it according to its restart policy. If it repeatedly fails, Kubernetes applies an exponential back-off delay between restart attempts. This continuous cycle of starting, failing, and backing off is precisely what the "Init:CrashLoopBackOff" status indicates for an init container, preventing the main application containers from ever starting.

  • Pending

    Why it's wrong here

    A pod enters the "Pending" state when it has been accepted by the Kubernetes system but one or more of its containers (including init containers) are not yet running. This typically occurs due to resource constraints, image pull failures, or node scheduling issues. In this scenario, the init container is actively attempting to execute and failing, indicating it has moved beyond the initial "Pending" phase.

  • Failed

    Why it's wrong here

    The "Failed" status for a pod is assigned only when all containers within the pod have terminated, and at least one container has terminated in failure (i.e., exited with a non-zero status). Crucially, if an init container fails, Kubernetes' default behavior is to restart it repeatedly, preventing the pod from reaching a final "Failed" state. The pod remains in a state of active failure and retry until the init container eventually succeeds or a manual intervention occurs.

  • Running

    Why it's wrong here

    The "Running" status for a pod signifies that all containers within the pod, including any init containers, have successfully started and are currently executing. Init containers are designed to run to completion in order, and only after all init containers have successfully finished will the main application containers begin their lifecycle. Therefore, if an init container is failing, the pod cannot transition to a "Running" state.

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 →

How Courseiva writes practice questions · Editorial policy

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.