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.

• ✗

  Liveness probe with initialDelaySeconds=10 and readiness probe without delay

  Why it's wrong here

  Setting liveness initialDelaySeconds=10 while the application needs 60 seconds to initialize means the kubelet will begin sending liveness probes long before the app's HTTP endpoint is responsive. Since the liveness probe fails, the container is killed and restarted, potentially entering a crash loop before it ever finishes booting. A readiness probe without delay does not mitigate this because readiness only controls traffic routing, not container restarts. The correct approach is to delay liveness using a startup probe rather than relying on a fixed initial delay.

• ✗

  Readiness probe with initialDelaySeconds=60 only

  Why it's wrong here

  A readiness probe with initialDelaySeconds=60 ensures no traffic is sent to the pod until the app is ready, which is fine, but it completely omits a liveness probe. Without liveness, kubelet cannot detect and restart the container once it becomes unhealthy after startup—for example, if the web app deadlocks or its worker pool hangs. The pod would remain in a NotReady state indefinitely, serving no traffic and requiring manual intervention. While readiness addresses availability during startup, it fails to provide the automatic self-healing that liveness probes offer for steady-state failures.

• ✗

  Liveness probe with initialDelaySeconds=60 and readiness probe with initialDelaySeconds=60

  Why it's wrong here

  Configuring both liveness and readiness with initialDelaySeconds=60 avoids premature restarts because the liveness probe only starts after the expected startup window. However, this is fragile: if the application occasionally takes longer than 60 seconds due to cache warming, database connection retries, or overwhelming traffic, the liveness probe will fail and kill a healthy-but-still-booting container. The initialDelay is a fixed guess, not a safety threshold based on consecutive failures. A startup probe with failureThreshold and periodSeconds provides a configurable grace period while keeping liveness available immediately after startup succeeds.

• ✓

  Startup probe with failureThreshold=30 and periodSeconds=2, plus liveness and readiness probes

  Why this is correct

  A startup probe with failureThreshold=30 and periodSeconds=2 gives the container up to 60 seconds to become ready (30 failures × 2 seconds). The kubelet runs the startup probe first, and only after it succeeds do the liveness and readiness probes begin executing. This cleanly separates the startup phase from steady-state health checking, preventing premature liveness restarts without limiting the app's startup time to a hard-coded initialDelay. Once the startup probe passes, the liveness probe takes over to restart the container if it later becomes unhealthy, while the readiness probe controls traffic admission.

Go deeper

Related to this question