A library catalog container is still marked Running but has stopped answering requests after a deadlock. Which probe is designed to restart that wedged process?
Select an answer to reveal the explanation.
Short Explanation
If the process is alive but brain-dead, readiness just stops sending it traffic. Liveness is the nudge that says restart this container so it can recover.
Full Explanation
A library catalog container that is still marked Running but has stopped answering requests after a deadlock needs a liveness probe whose failure causes kubelet to restart the container. Liveness detects that a process is wedged even though the container runtime still considers it running. When the probe fails past threshold, kubelet restarts the container so the catalog can recover without waiting for a human to kill the Pod.
A readiness probe that only removes the Pod from Service endpoints protects callers from bad backends but does not restart the wedged process. A startup probe that permanently disables the Deployment controller is fictional and wrong. A node affinity rule that relocates deadlocked processes to another node is scheduling policy, not a health restart mechanism.
Exam caveat: overly aggressive liveness on slow apps causes restart loops—use startup probes for long initialization. Operational check: add an appropriate liveness probe to the catalog container, induce or observe deadlock symptoms, and confirm kubelet restarts the container while readiness continues to manage Service membership separately. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.