During a rolling update of a utility billing API, new Pods start but must not receive Service traffic until healthy. Which statement correctly ties readiness to rollout safety?
Select an answer to reveal the explanation.
Short Explanation
Don’t seat diners at a table that isn’t set. If readiness fails, the Pod stays off the Service endpoints, so clients keep hitting Ready Pods while the rollout waits for healthy newcomers.
Full Explanation
During a rolling update of a utility billing API, failed readiness keeps Pods out of Service endpoints (and EndpointSlices), so clients keep hitting old Ready Pods while the Deployment waits for new Pods to become Ready before considering them available for rollout progress. Readiness is therefore the bridge between Pod health and both Service traffic and safe rollout advancement—exactly what billing APIs need so residents never hit half-started containers.
Why the other options fail by concept: Liveness failures restart containers; they do not add Pods to endpoints faster. Startup probes gate when other probes begin; they do not replace Services. Readiness failures do not delete the Deployment automatically.
Exam caveat: A Pod can be Running yet not Ready—Services will not send traffic. If readiness is too strict or depends on a broken dependency, rollouts stall and Endpoints can empty. Combine readiness with appropriate maxUnavailable so the Service always retains enough backends for municipal SLOs.
Operational check: During a billing API rollout, watch kubectl get pods and kubectl get endpointslices -l <svc> together. Confirm new Pods appear in endpoints only after Ready, and that rollout status waits on Available replicas. Intentionally break readiness in a test namespace to see endpoints drop without necessarily restarting the container (liveness still passing).