Application Observability and Maintenance →hardMultiple Choice

CKAD Application Observability and Maintenance Practice Question

You have a pod that takes 2 minutes to start its application. You want to avoid the liveness probe from killing the pod during startup, but still have it active afterward. Which probe should you add to the pod spec?

⚠ Common exam trap

A common mix-up: candidates choose initialDelaySeconds (option D) thinking it's the standard way to handle slow starts, but it doesn't account for variable startup times and can mask real failures after the delay expires.

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 a startup probe with a failureThreshold high enough to cover the startup time

A startup probe is designed specifically for slow-starting containers. It runs before the liveness probe and, if it fails, the container is killed. By setting a high failureThreshold (e.g., 12 with a 10-second period gives 120 seconds), you allow the application up to 2 minutes to start without the liveness probe interfering. Once the startup probe succeeds, the liveness probe takes over normally.

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 a startup probe with a failureThreshold high enough to cover the startup time
Why this is correct
A startup probe is the idiomatic solution because Kubernetes keeps the liveness and readiness probes disabled until this startup probe succeeds, so a slow-starting process is not repeatedly killed. Configure failureThreshold and periodSeconds together so their product comfortably exceeds the ~2 minute startup window (e.g., failureThreshold: 20, periodSeconds: 10). Once the startup probe succeeds, the normal liveness and readiness probes take over, and if the app later fails, it gets restarted.
✗
Increase the timeoutSeconds on the liveness probe
Why it's wrong here
Increasing timeoutSeconds only extends the time a single probe HTTP/TCP request is allowed to respond — it is not an outer deadline for the container's startup. The first liveness probe still fires at initialDelaySeconds (default 0) and keeps firing every periodSeconds, so a 2-minute startup will still encounter many failed probes long before it is ready. A longer timeout also delays the eventual restart after a true crash, which is an undesirable side effect rather than a startup grace period.
✗
Set periodSeconds on the liveness probe to 120
Why it's wrong here
Setting periodSeconds to 120 on the liveness probe changes the interval between subsequent checks, but it does nothing to delay the very first probe; with default initialDelaySeconds, the probe executes immediately and fails repeatedly during the entire 2-minute startup. The kubelet counts consecutive failures and will restart the container once failureThreshold is reached, usually well before startup completes. After a successful start, a 120s interval also leaves a long outage window before a dead container is detected.
✗
Set initialDelaySeconds on the liveness probe to 120
Why it's wrong here
initialDelaySeconds postpones the first liveness check by exactly 120 seconds, which appears to match the startup time, but it grants no grace beyond that instant; if the app has not become healthy by the time the first check runs, the probe fails and the kubelet begins counting failures. With default periodSeconds and failureThreshold, another probe comes quickly and a few failures trigger a restart. The app also receives no protection for minor startup variability, because after the delay liveness probing is fully active and unforgiving.

Go deeper

CKAD Application Observability and Maintenance Practice Question

Why each option matters

Option-by-option breakdown

Related to this question