CKAD Practice Question 1: Init Container Ordering
Certified Kubernetes Application Developer (CKAD) · Test 1 · question 1 of 10
An application container crashes on startup because it connects to a database whose schema has not been migrated yet. The migration is a short-lived command that must finish successfully, exactly once per Pod, before the application process is allowed to start.
Which Pod design meets this requirement?
Show answer and explanation
Answer:
Init containers are exactly the mechanism for this. They run in order, each one must exit successfully before the next starts, and none of the Pod's regular containers are started until every init container has completed. If the migration fails, the kubelet retries it according to the Pod's restartPolicy, so the application never sees a half-migrated database.
Option B is wrong because regular containers in a Pod are started in parallel, with no ordering guarantee. The application would race the migration and keep crashing, the exact symptom described.
Option C describes a sidecar: a container that runs *for the lifetime of the Pod*, not one that runs to completion first. Even the native sidecar form (an entry in initContainers with restartPolicy: Always) is explicitly designed so that the Pod continues starting once the sidecar is up, rather than waiting for it to exit, which defeats a run-once migration.
Option D is wrong on ordering. A postStart hook fires after the container is *created*, but it runs concurrently with the container's entrypoint; the application process is not held back while the hook executes. It is also not guaranteed to be delivered exactly once.
Reference: Init Containers