Application Observability and Maintenance →mediumMultiple Select

CKAD Application Observability and Maintenance Practice Question

Which TWO statements about readiness probes are correct? (Choose two.)

⚠ Common exam trap

It's easy for candidates to confuse readiness probes with liveness probes, leading candidates to incorrectly think readiness probes restart containers or are only used at startup, when in fact readiness probes manage traffic routing without restarting the pod.

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

✓

Readiness probes run continuously after the container starts

Readiness probes are designed to run continuously throughout the lifecycle of a container, not just during startup. They are periodically executed by the kubelet to determine whether the container is ready to accept traffic, and their success or failure directly controls the pod's inclusion in Service endpoints.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Readiness probes are only used during initial startup
Why it's wrong here
Readiness probes are not limited to the initial startup window. They start being checked as soon as the container begins, but, unlike the startup probe, they never stop: the kubelet keeps invoking them at every configured interval for the container's entire lifetime. A pod that becomes unready later in its life is still removed from Service endpoints, proving the probe continues beyond the initial phase.
✓
Readiness probes run continuously after the container starts
Why this is correct
This statement is correct because a readiness probe is a recurring health check, not a one-time gate. The kubelet executes it every periodSeconds once the container is running, even after the pod has already become Ready. If the probe later fails, the pod is marked NotReady and traffic is withdrawn; if it passes again, the pod is marked Ready and endpoints are restored.
✗
Readiness probes can only be of type httpGet
Why it's wrong here
Readiness probes support multiple handlers, not just httpGet. The kubelet can perform a tcpSocket check by opening a TCP connection to a port, an exec check by running a command inside the container and treating exit code 0 as success, or a grpc check using a gRPC health probe. The httpGet scheme is merely one of the available options and is chosen by adding a handler to the probe spec.
✗
Readiness probes restart the container if they fail
Why it's wrong here
A failing readiness probe does not cause the kubelet to kill or restart the container; restart decisions belong exclusively to liveness probes. If a readiness probe fails, the kubelet simply updates the pod's Ready condition and removes it from the backing endpoints of Services. The container keeps running and the probe continues to be evaluated, so a successful future probe can bring the pod back into rotation without any restart.
✓
If a readiness probe fails, the pod is removed from all Service endpoints
Why this is correct
This is the core effect of a readiness probe: the pod is only a valid traffic destination while its readiness probe succeeds. When the probe fails, the kubelet removes the pod's IP from the Endpoints and EndpointSlices that back every Service selecting the pod, so new traffic is never routed to it. This allows a pod that is alive but temporarily unable to serve requests, such as during heavy load or a deadlocked application, to be isolated from incoming traffic without being terminated.

Go deeper

CKAD Application Observability and Maintenance Practice Question

Why each option matters

Option-by-option breakdown

Related to this question