Public-health Pods keep running but fail readiness probes. How does that affect a Service that selects those Pods?
Select an answer to reveal the explanation.
Short Explanation
Failing readiness is like putting a "closed" sign on a register — the Pod stays in the store, but the Service stops sending customers there.
Full Explanation
Public-health Pods that keep running but fail readiness probes are removed from the Service Endpoints so traffic is not sent to them until they become ready. Readiness is the closed-sign on a register: the Pod object remains, containers may still run, but the Service stops sending citizen traffic to backends that cannot serve correctly.
Failed readiness probes do not delete the Service object and recreate it as NodePort. Not-ready Pods do not remain in Endpoints while kube-dns stops resolving the Service name entirely—DNS still resolves; backends are what change. Readiness failures do not convert the Service to headless automatically until probes pass.
Exam caveat: liveness failures restart containers; readiness failures only gate traffic—do not conflate them. Operational check: watch Endpoints while inducing readiness failure on a public-health Pod and confirm it disappears from ready backends until probes pass again. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.