CKAD Application Observability and Maintenance Practice Question
Which THREE of the following are valid reasons to use a startup probe? (Select THREE.)
⚠ Common exam trap
CNCF often tests the distinction between probe types, and the trap here is confusing the startup probe's role of delaying other probes with the readiness probe's role of controlling service traffic, or the liveness probe's role of restarting unhealthy containers.
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
✓
To handle containers that have a variable startup time
A startup probe is specifically designed for containers that have a variable or long initialization time. It allows the kubelet to delay the start of liveness and readiness probes until the application has finished starting up, preventing premature failures.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
To handle containers that have a variable startup time
Why this is correct
Containers that take a variable amount of time to become ready—for example, because they must load large datasets or wait for external dependencies—can trip the default liveness probe settings and be restarted before they finish initializing. A startup probe lets you set a generous periodSeconds and failureThreshold so the kubelet waits an adequate, configurable window that can encompass all startup variability. Once the startup probe succeeds, normal liveness/readiness probing begins, but the startup probe itself ensures the variable initialization doesn't cause premature termination.
- ✗
To check if the container is healthy after startup
Why it's wrong here
After a container has successfully started and the startup probe has returned success, it is the liveness probe's job to continuously assess whether the container remains healthy—for example, by checking for deadlocks or unresponsive threads. A startup probe is only evaluated during the initial boot phase; it does not perform ongoing health checks. Therefore, using a startup probe to verify post-startup health would be a category mistake: that concern belongs exclusively to the liveness probe, which runs throughout the container's lifetime.
- ✓
To delay readiness and liveness probes until the application is fully initialized
Why this is correct
The kubelet deliberately withholds execution of both readiness and liveness probes until the startup probe has succeeded. This means that during the entire startup period, only the startup probe is actively checking, and readiness/liveness are effectively suspended until the application has performed its initialization routines. This is exactly what you want when, for instance, an application must connect to a database or run schema migrations before it can respond to any requests; the delay prevents the other probes from sending traffic to an incomplete pod or declaring it unhealthy prematurely.
- ✗
To remove the pod from service endpoints if it fails
Why it's wrong here
Removing a pod from a Service's endpoints is the specific responsibility of the readiness probe: the kubelet periodically checks readiness and, on failure, marks the pod as not ready so that the endpoints controller removes its IP from backing Services. A startup probe has no direct effect on endpoint membership; it only gates the other probes and triggers container restarts if it fails (based on restartPolicy). Thus, if a pod fails its startup probe, it will be killed/restarted, not just removed from endpoints—so this is not a valid reason to use a startup probe.
- ✓
To allow a container a long time to start up without being killed by liveness probe
Why this is correct
A container that legitimately needs a long time to boot—such as a Java application preloading a large JVM or a workload that performs heavy initialization—can easily exceed the default liveness probe's initialDelaySeconds and be killed repeatedly. Setting a startup probe with a high failureThreshold and/or long periodSeconds gives the container an extended window to become ready, during which the liveness probe is not started at all. The liveness probe only begins to fire after the startup probe succeeds, so slow-starting containers are no longer penalized with unnecessary restarts.
Go deeper
Related to this question
About these practice questions
One of 826 original CKAD practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.