CKAD Application Observability and Maintenance Practice Question
You are asked to ensure that a pod with a slow-starting container (requires 60 seconds to initialize) is not prematurely restarted by the liveness probe. The liveness probe should start only after the container is fully initialized. Which probe type should you add to the pod spec?
⚠ Common exam trap
CNCF often tests the misconception that initialDelaySeconds on a liveness probe is sufficient for slow-starting containers, but the trap is that initialDelaySeconds is a fixed delay that does not account for variable startup times, whereas a startupProbe dynamically waits until the container is actually ready.
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
✓
startupProbe
A startupProbe is specifically designed for slow-starting containers. It runs at pod startup and only after it succeeds does the liveness probe begin. This prevents the liveness probe from restarting the container during its 60-second initialization period, as the startupProbe will keep failing until the container is fully ready.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
startupProbe
Why this is correct
A startupProbe is the only probe type designed for slow-starting containers; it runs repeatedly until the process signals it has initialized successfully. Kubelet disables liveness and readiness probes until this probe succeeds, so the container gets unlimited (or configured) attempts to start without being killed. You can set a large failureThreshold with short periodSeconds to allow a long but controlled startup window.
- ✗
readinessProbe
Why it's wrong here
A readinessProbe determines whether a pod receives Service traffic; if it fails, the pod is removed from endpoints but the container is not restarted. It does not delay or suppress liveness probes, so an unstarted container can still be killed by a failing liveness check before readiness ever succeeds. Thus readiness alone cannot solve the slow-start problem.
- ✗
livenessProbe with initialDelaySeconds=60
Why it's wrong here
A livenessProbe with initialDelaySeconds=60 only postpones the first check by a fixed 60-second wait. If a container needs longer than that to become ready, the liveness probe will fail and trigger a restart, so the delay has to be manually tuned and can still cause premature kills. Startup probes are the recommended replacement because they measure actual readiness rather than assuming a constant delay.
- ✗
lifecycle preStop hook
Why it's wrong here
A lifecycle preStop hook executes immediately before a container is terminated – typically to drain connections or flush state. It runs during shutdown, not during startup, and does not interact with kubelet's probe scheduling. Since it doesn't delay liveness checks or give the application additional time to initialize, it has no bearing on slow container starts.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKAD question from scratch — 826 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.