CKAD Application Design and Build Practice Question
You are designing a Pod that must run a diagnostic tool to collect network logs before the main application starts. The diagnostic tool should run to completion, then the main application starts. Which approach should you use?
⚠ Common exam trap
Many exam-takers confuse init containers with sidecar containers or lifecycle hooks, assuming any container that runs before the main application can be a sidecar, but only init containers guarantee sequential execution to completion before the main container starts.
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
✓
Add the diagnostic tool as an init container in the Pod
Init containers run sequentially before the Pod's main containers start, and they must complete successfully before the main application container begins. This makes them ideal for setup tasks like running a diagnostic tool to collect network logs that must finish before the main application starts.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Add the diagnostic tool as an init container in the Pod
Why this is correct
An init container is the correct choice because Kubernetes runs init containers to completion, in order, before any regular app container is started. This guarantees the diagnostic tool finishes its checks first, and if it exits with a non-zero status, the app container will not be created. The diagnostic is thus an explicit, blocking prerequisite within the same Pod.
- ✗
Add the diagnostic tool as a sidecar container in the same Pod
Why it's wrong here
Adding the diagnostic tool as a sidecar container makes it start concurrently with the main app container, not ahead of it, because all regular containers in a Pod are scheduled and started in parallel. A sidecar is also a long-running process expected to stay alive, whereas a diagnostic check is a one-shot action that should terminate when finished. Therefore, a sidecar does not enforce the required before-start ordering.
- ✗
Add the diagnostic tool as a sidecar container with a postStart hook
Why it's wrong here
A postStart hook is executed after the container's main process starts, so it cannot push a diagnostic before the app container begins; the hook semantics are the wrong ordering direction. Moreover, the sidecar container itself starts at the same time as the app container, and its postStart hook fires only after that sidecar is already running. This approach is doubly incorrect because both the sidecar concurrency and the hook timing violate the required sequence.
- ✗
Create a separate Job that runs before the Pod
Why it's wrong here
A Job is a separate Pod-level resource, and creating it before the main Pod does not create any dependency or ordering guarantee between them. Without an explicit controller or external wait, the main Pod can start before or even while the Job is still running. The diagnostic tool would also not share volumes or lifecycle with the app container, whereas an init container is the native mechanism that makes the app container's start conditional on completion.
Go deeper
Related to this question
About these practice questions
This CKAD question is part of Courseiva's 160-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.