A building-permits JVM app takes minutes to initialize and would fail early liveness checks. Which probe gives it time before liveness restarts begin?
Select an answer to reveal the explanation.
Short Explanation
Slow starters need a startup probe—like a grace period before the referee starts calling fouls. Once startup succeeds, normal liveness and readiness take over.
Full Explanation
A building-permits JVM app that takes minutes to initialize and would fail early liveness checks should use a startup probe that delays liveness and readiness checks until the app has started. Startup probes give slow municipal JVM boots a protected window: kubelet withholds liveness and readiness evaluation until startup succeeds or fails the startup threshold. That prevents restart loops during legitimate long initialization of the permits stack.
A readiness-only probe that also raises PriorityClass during boot mixes unrelated concepts; readiness does not raise PriorityClass. A liveness probe with failureThreshold set to zero permanently is not the correct slow-start tool. A preStop lifecycle hook that blocks kubelet until the JVM is warm runs at termination, not at startup.
Exam caveat: once startup succeeds, liveness and readiness proceed with their own thresholds—tune each for the permits app. Operational check: add a startup probe matching the JVM warm path, roll the Deployment, and confirm Pods reach Ready without liveness kill loops during boot. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.