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.

• ✗

  The failureThreshold should be increased to 10

  Why it's wrong here

  Increasing the failureThreshold to 10 only raises the number of consecutive failures allowed before Kubernetes kills the container; it does not change when the probe starts. With a 10-second probe interval, the liveness probe would still begin at t=10s and fail for 10 consecutive checks (100s), causing a restart at about 110s—just before the container finishes its 120-second startup. This masks the symptom without fixing the underlying premature probing, and it also slows down real failure detection. The correct approach is a startup probe that gives the container 120 seconds to initialize before liveness takes over.

• ✗

  The httpGet path '/healthz' is incorrect and should be '/ready'

  Why it's wrong here

  Changing the httpGet path from '/healthz' to '/ready' would produce a different HTTP response (likely a 404 if '/ready' doesn't exist at that time), but the probe would still execute at the same early point. The container is not ready after only 10 seconds, so any endpoint you choose will report failure and trigger the same restart loop. The liveness probe's path is not the issue; its start timing relative to the container's slow initialization is. Thus, modifying the path does not resolve the premature probe failures.

• ✗

  The readiness probe is misconfigured and should be used instead of a liveness probe

  Why it's wrong here

  Readiness probes only control whether a pod is added to Service endpoints for traffic routing; they never cause container restarts. If you replaced the liveness probe with a readiness probe, a dead or hung container would never be restarted, leaving the pod unhealthy but not killed. The current problem is that the container is being restarted too early, which is a liveness/startup concern, not a traffic-routing one. The correct solution is to introduce a startup probe with a substantial failureThreshold, not swap a readiness probe for a liveness probe.

• ✓

  The liveness probe is failing too early because initialDelaySeconds is too low for the slow-starting container

  Why this is correct

  The liveness probe is configured to begin only 10 seconds after container start (initialDelaySeconds=10), but the application requires 120 seconds to initialize and listen on its health endpoint. During those first 110 seconds, the probe returns HTTP 500 or fails to connect, and after the default failureThreshold (3) consecutive failures, Kubernetes kills and restarts the container. This restart loop never gives the application the 120 seconds it needs, so it never becomes healthy. By setting initialDelaySeconds to 120 or adding a startup probe with a longer period, the container can finish starting before liveness checks begin.

Go deeper

Related to this question