CKAD Application Design and Build Practice Question
What is the primary purpose of an Init Container in a Pod?
⚠ Common exam trap
It's easy for candidates to confuse init containers with sidecar containers — both run in the same Pod, but init containers are ephemeral and block startup, while sidecars persist for the Pod's lifetime.
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
✓
Perform initialization tasks such as waiting for a database to be ready
Init containers run to completion before the main application containers start, making them ideal for blocking or delaying the main container until prerequisites like a database readiness check succeed. They execute sequentially and can use different container images, allowing setup tasks without bloating the main app image or requiring special permissions.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Perform initialization tasks such as waiting for a database to be ready
Why this is correct
Init containers exist specifically to run one-time setup tasks that must finish successfully before the main application containers are started. A canonical example is polling or blocking until a database or external service is reachable, because the app cannot function until that prerequisite exists. They execute sequentially, run to completion, and if one fails, the whole pod is restarted according to its restartPolicy — they are not long-running processes.
- ✗
Run a sidecar proxy alongside the main container
Why it's wrong here
A sidecar proxy is a regular container that runs concurrently with the main application container for the entire life of the pod, intercepting or forwarding traffic. An init container, by contrast, runs to completion and exits before any main containers begin, so it cannot serve as a continuously available proxy. This option confuses the long-running sidecar pattern with the short-lived, sequential init container phase.
- ✗
Provide a health check endpoint for the main container
Why it's wrong here
Health checks are implemented via readiness, liveness, and startup probes declared in a container's own spec, usually the main application container. Init containers run before the main container starts and have already terminated by the time probes are evaluated, so they cannot serve an endpoint or act as a health monitor for the main process. Probes are about ongoing runtime health, whereas init containers are purely about startup prerequisites.
- ✗
Collect logs and metrics from the main container
Why it's wrong here
Collecting logs and metrics from the main container is a classic sidecar container responsibility: a long-running helper that shares the pod's network and filesystem and continuously streams or aggregates data. An init container exits immediately after its setup steps, so it cannot persistently observe or export logs and metrics from the main application. This option describes a sidecar pattern, not the init container lifecycle.
Go deeper
Related to this question
About these practice questions
This CKAD question is part of Courseiva's 826-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 CKAD 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 CKAD exam.