A failing liveness probe makes the kubelet restart the container, so it is for a process that is stuck and cannot recover on its own. A failing readiness probe pulls the pod out of the Service endpoints so it stops receiving traffic, but leaves it running. Startup probes cover slow booting apps so a long startup does not trip liveness. Liveness should check the process itself, not its dependencies.
Why interviewers ask this
This is a small question that reliably exposes real experience. Anyone who has run Kubernetes in anger has seen a liveness probe wired to a deep health check take down a whole deployment during a dependency blip. The interviewer wants that distinction, plus knowledge of startup probes, plus an understanding of how readiness interacts with rolling updates and graceful shutdown.
How to structure your answer
- Give the one line difference: restart versus remove from traffic.
- Explain what each probe should actually check.
- Name the classic failure of a dependency aware liveness probe.
- Add startup probes and the link to rolling updates.
Example answer
Readiness answers can this pod take traffic right now, and liveness answers is this process beyond saving. If readiness fails, the endpoints controller removes the pod from the Service, traffic stops, and the pod carries on running so it can recover. If liveness fails, the kubelet kills and restarts the container. The mistake I see most often is a liveness endpoint that checks the database and the cache. Then the database has a thirty second wobble, every replica fails liveness at once, the whole deployment restarts, and now you have a cold cache and a thundering herd on top of the original problem. So liveness checks only that the process is responsive, and readiness is where dependency checks belong, because losing traffic temporarily is recoverable. For a service that takes ninety seconds to warm up I add a startup probe with a generous failure threshold so liveness does not start until it is up. Readiness also drives rolling updates, so I make sure it flips to not ready at the start of shutdown, before the process stops accepting connections.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- How do readiness probes interact with graceful shutdown and preStop hooks?
- What happens during a rolling update if readiness never passes?
- When would you use a startup probe rather than a long initial delay?
Related devops engineer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions