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.

• ✗

  Use a HTTP GET liveness probe with path /healthz and port 8080

  Why it's wrong here

  A HTTP GET liveness probe with path /healthz and port 8080 only tests whether the container should be restarted after it has started; it does nothing to delay or suppress checks during initialization. Because the kubelet will run this probe according to the configured initialDelaySeconds and periodSeconds, a slow-starting app that hasn't yet bound /healthz will return non-2xx, be considered failed, and be killed before it ever becomes ready. This turns a slow startup into a crash loop, so it is not a solution to the slow startup problem.

• ✗

  Set livenessProbe.initialDelaySeconds to 300

  Why it's wrong here

  Setting livenessProbe.initialDelaySeconds to 300 is a hardcoded grace period, not an adaptive mechanism: if the application takes 301 seconds to become healthy, the first liveness probe fails because it fires at the 300-second mark and the container is restarted. It also masks real problems for the entire 300 seconds, because no liveness checks run at all, and it cannot accommodate variance across replicas or future versions of the app. A startup probe, by contrast, waits for a positive signal rather than a fixed clock interval, so this option is only a fragile partial delay.

• ✓

  Configure a startup probe with a high failureThreshold and appropriate initialDelaySeconds

  Why this is correct

  Configuring a startup probe with a high failureThreshold and an appropriate initialDelaySeconds is the correct approach: the kubelet runs the startup probe first and disables liveness and readiness probes until the startup probe succeeds. By setting failureThreshold high and periodSeconds short (for example, 30 failures x 2 seconds), you give the application up to 60 seconds to initialize without risking a restart, while still detecting a true startup failure. Once the startup probe passes, the normal liveness and readiness probes take over, ensuring ongoing health checks are responsive and do not interfere with the boot sequence.

• ✗

  Set livenessProbe.periodSeconds to a high value, like 300

  Why it's wrong here

  Setting livenessProbe.periodSeconds to a high value, such as 300, changes only the interval between subsequent checks; it has no effect on when the first liveness probe is issued, which is governed by initialDelaySeconds. If the container needs several minutes to start and initialDelaySeconds is left at its default of 0, the first probe still fires almost immediately, fails, and triggers a restart. After the container is healthy, a 300-second period also means a deadlocked process could go undetected for up to five minutes, hurting availability and defeating the purpose of liveness probes.

Go deeper

Related to this question