CKAD Application Observability and Maintenance Practice Question
Which TWO of the following are valid reasons to use a readiness probe? (Select 2)
⚠ Common exam trap
CNCF often tests the distinction between readiness, liveness, and startup probes; the trap here is confusing the purpose of a readiness probe (traffic routing) with that of a liveness probe (container restart) or a startup probe (delaying other probes).
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
✓
To prevent traffic from being sent to a pod that is not ready due to a dependency
A readiness probe is used to determine whether a pod is ready to serve traffic. Option A is correct because it prevents traffic from being sent to a pod that is not ready due to a dependency, such as a database or cache that hasn't fully initialized. The kubelet uses the probe's success or failure to control whether the pod's IP address is added to the endpoints of a Service, ensuring only ready pods receive requests.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
To prevent traffic from being sent to a pod that is not ready due to a dependency
Why this is correct
A readiness probe determines whether a pod can accept requests by periodically executing a check (HTTP, TCP, or command) inside the container; if the check fails because a required dependency, such as a database or configuration service, is not yet available, the pod is marked NotReady. The kubelet then removes the pod's IP from all backing Service EndpointSlices, so live traffic is never forwarded to a container that would fail the request. This prevents users from hitting a pod that is running but still initializing its dependent components.
- ✓
To ensure the pod is not added to a Service until the application is ready
Why this is correct
The kubelet uses successful readiness probe results to set the pod's Ready condition, and only pods with this condition are selected as active endpoints by a Service. When the pod is starting and the probe has not yet succeeded, the pod is deliberately excluded from the Service's endpoint list, so it does not receive round-robin or load-balanced traffic. This guarantees that clients connect only to pods whose application has completed initialization and can handle new connections, preserving the Service's overall availability and reliability.
- ✗
To monitor resource usage and scale the pod
Why it's wrong here
Readiness probes return a binary success/failure for a liveness-style check, not telemetry such as CPU or memory consumption; they are designed to answer 'can this pod serve a request?' not 'how much resources is it using?'. Resource metrics are collected by cAdvisor and metrics-server, and the Horizontal Pod Autoscaler (HPA) scales replicas based on that data. Therefore, scaling decisions would never be driven by readiness probe output, and this is not a valid reason to use one.
- ✗
To delay the start of the application until a database is available
Why it's wrong here
A readiness probe checks container-internal readiness, not external dependencies like a database. The correct mechanism for delaying startup until a database is available is an init container, which runs to completion before the main container starts. This option is tempting because readiness probes are commonly used to signal when an application is ready to serve traffic, but they cannot block the start of the container itself—they only control whether the container receives traffic after it has already started.
- ✗
To restart the container if it becomes unresponsive
Why it's wrong here
Readiness probes do not trigger restarts; when a readiness check fails, Kubernetes keeps the container running and merely stops sending it traffic, while the kubelet continues to execute the probe. Restarting an unresponsive container is the responsibility of a liveness probe, which, on repeated failure, causes the kubelet to kill the container and apply the pod's restartPolicy. Thus using a readiness probe for restart behavior would never restart anything, making this an invalid reason.
Go deeper
Related to this question
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.