CKAD Application Observability and Maintenance Practice Question
A pod is running but not serving traffic. You suspect the readiness probe is failing. Which THREE commands or actions would help you diagnose the readiness probe issue?
⚠ Common exam trap
CNCF often tests the distinction between resource monitoring commands and probe-specific diagnostics, so candidates may mistakenly choose 'kubectl top pod' or 'kubectl get nodes' thinking they reveal probe failures, when in fact only describe, logs, and direct endpoint testing are relevant.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Examine the container logs for errors during readiness probe checks.
Container logs often contain detailed error messages from the readiness probe itself, such as HTTP 4xx/5xx responses or connection timeouts. By examining the logs, you can directly see why the probe is failing, e.g., the application's health endpoint returning a non-2xx status or the probe timing out.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Examine the container logs for errors during readiness probe checks.
Why this is correct
Container logs are one of the first places to look when a readiness probe fails. The kubelet sends probe requests (e.g., HTTP GET to the probe path), and if the application logs each request, you may see the probe arriving with a non-2xx status, stack traces, or slow response times indicating why the endpoint is not healthy. While probe requests are not always logged, if they are, they can directly reveal the underlying cause such as a crash loop, a missing dependency, or a connection timeout.
- ✗
Run 'kubectl top pod <pod-name>' to check CPU/memory usage.
Why it's wrong here
The `kubectl top pod` command reports live CPU and memory usage gathered by the metrics-server, but it does not show the status of application endpoints or readiness probe results. A pod could be consuming high resources yet still respond successfully to its probe, or it could be using minimal resources while failing because the application is deadlocked or misconfigured. Therefore, this command provides no diagnostic value for determining why a pod is not serving traffic due to a readiness probe failure.
- ✗
Run 'kubectl get nodes' to see node conditions.
Why it's wrong here
Node conditions like `Ready`, `MemoryPressure`, or `DiskPressure` describe the state of the entire node and affect scheduling and eviction decisions, not the health of a specific pod's readiness probe. Since the pod is already running, the node is typically in a condition that permits pods to run; even if a node condition were problematic, it would not explain why the kubelet is marking this pod's readiness probe as failing. The right approach is to inspect pod-level resources such as events, logs, and the probe endpoint itself.
- ✓
Run 'kubectl describe pod <pod-name>' to check the events section for probe failures.
Why this is correct
The events section of `kubectl describe pod` is a built-in, authoritative source for probe outcomes. The kubelet emits events when a readiness probe fails, such as `Readiness probe failed: HTTP probe failed with statuscode: 500`, along with timestamps and the number of consecutive failures. This output also shows the exact probe configuration (path, port, periodSeconds), making it easy to confirm whether the probe is hitting the right endpoint and how often, which is often the fastest way to identify the failure mode.
- ✓
Exec into the container and manually curl the readiness endpoint to test it.
Why this is correct
Executing into the container and manually hitting the readiness endpoint (e.g., `kubectl exec <pod> -- curl -v http://localhost:8080/healthz`) tests the application directly, bypassing the kubelet and probe configuration. This allows you to see whether the endpoint is reachable from inside the container, what HTTP status it returns, and how long it takes—immediately distinguishing an application-level failure (like a deadlocked handler) from a probe configuration issue (like a wrong port or path). It is an essential hands-on verification step when logs and events are inconclusive.
Go deeper
Related to this question
Learn chapter
Health Checks: Readiness, Liveness, and Startup Probes
Key term
Container Logs
Container logs are records of output generated by applications running inside a container, showing what the application did, errors it encountered, or status updates it produced.
Key term
Readiness Probes
A Kubernetes mechanism that checks if a container is ready to start accepting traffic and serve requests.
About these practice questions
One of 826 original CKAD practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKAD practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKAD exam.