CKAD Application Observability and Maintenance Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Set a long 'initialDelaySeconds' on the liveness probe

  Why it's wrong here

  initialDelaySeconds only postpones the initial liveness check; once it elapses, the probe executes at periodSeconds intervals regardless of startup progress. If the app is still initializing when the first check occurs, the failure counter begins, and with the default failureThreshold, the container can be restarted before it ever becomes ready. This treats the symptom of a slow startup by shifting the timing rather than telling the kubelet that startup is still in progress, and it also delays detection of genuine crashes after startup.

• ✗

  Add a readiness probe

  Why it's wrong here

  A readiness probe controls whether the pod receives traffic, but it has no effect on liveness probe lifecycle management. If the liveness probe fires during the long startup window and exceeds its failureThreshold, the kubelet kills and restarts the container even though the readiness probe would succeed moments later. Adding a readiness probe alone therefore leaves the startup-restart problem unsolved because it cannot suppress or delay liveness checks.

• ✗

  Increase the failureThreshold on the liveness probe

  Why it's wrong here

  Raising the liveness probe's failureThreshold gives the container more consecutive failed probes before a restart, but the liveness probe still starts ticking immediately at container start. A long startup period may consume so many probe intervals that the threshold is exceeded before the app becomes healthy, and during genuine post-startup failures, a higher threshold unnecessarily delays restart and recovery. It is a blunt workaround compared to a startup probe, which deliberately suppresses liveness and readiness probing until startup completes.

• ✓

  Add a startup probe with a longer failure threshold

  Why this is correct

  A startup probe is designed exactly for this scenario: it runs until it succeeds, and while it is active, the kubelet disables liveness and readiness probes. Configure failureThreshold high enough (e.g., 30) with a short periodSeconds, so the total startup allowance is failureThreshold * periodSeconds; once the startup probe succeeds, liveness and readiness probes resume normal operation. This cleanly decouples startup duration from liveness/readiness tuning and prevents restarts during slow initialization.

Go deeper

Related to this question