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.

• ✗

  Check the liveness probe events via 'kubectl describe pod' to see the exact probe responses.

  Why it's wrong here

  kubectl describe pod shows probe events like 'Liveness probe failed' with the HTTP status code or command exit code, but these events are generated by the kubelet and do not contain the application's internal error message, stack trace, or logging output. The event will tell you that the probe failed and possibly the raw response (e.g., 500), but not why your application returned that response. This makes describe a useful first step for confirming the failure, but insufficient for root-cause diagnosis.

• ✗

  Run 'kubectl exec' to curl the endpoint from another pod to test network connectivity.

  Why it's wrong here

  Executing curl from another pod tests network reachability to the pod's IP/port from the cluster network, but the kubelet runs liveness probes directly on the node, so a network partition between pods is rarely the cause of a liveness probe failure. Even if the endpoint is reachable, the application can still be internally unhealthy—for example, deadlocked or stuck in a bad state—and return a 500 or fail to respond to the probe specifically. This action adds extra load and could even change timing, making it a poor diagnostic for application-level failures.

• ✗

  Review the liveness probe parameters in the deployment YAML and increase the failureThreshold.

  Why it's wrong here

  Increasing failureThreshold or adjusting other probe parameters only tells Kubernetes to tolerate more consecutive failures before restarting the container; it does nothing to address the underlying application defect. During the extended threshold window, the pod remains unhealthy and may be removed from Service endpoints, meaning user traffic continues failing while the container is kept alive artificially. This is a config tuning approach that masks the symptom, not a diagnostic step, and should only be considered after the root cause is identified and the threshold is aligned with actual startup and response behavior.

• ✓

  Examine the container logs via 'kubectl logs' for error messages around the time of the failures.

  Why this is correct

  Container logs are the most direct source of information about what the application was doing when the liveness probe failed, because the application often writes an error, panic, or timeout message immediately before it becomes unresponsive. Use `kubectl logs <pod>` to view the current logs, and `kubectl logs <pod> --previous=true` if the container has been restarted, to find logs from the failed run. Correlating log timestamps with probe failure events from `kubectl describe` lets you pinpoint the exact code path or dependency failure causing the probe to fail.

Go deeper

Related to this question