TL;DR: Readiness failure marks the pod unready for ordinary Service routing and keeps it running. Liveness failure kills and restarts the container. Startup failure kills it too, but it suspends the other two while the app boots. The dangerous one is liveness, because a probe that fails under load restarts healthy pods and turns a slowdown into an outage.
How to approach it
Lead with the consequence of each failure rather than the definition, because the consequences are what make them different. Then make the argument that liveness should be conservative, which is the opinionated part.
A strong answer
Readiness answers "should I get traffic right now?" On failure the matching endpoint is marked unready. Ordinary Service routing stops selecting it for new traffic once the update propagates, but existing connections and direct pod-IP requests can continue. This is the probe that should reflect real ability to serve, including a dependency you cannot work without. Avoid aggressive checks against shared dependencies: one database outage can mark every replica unready and remove all service capacity. Check whether removing the pod actually improves the request outcome.
Liveness answers "is this process wedged beyond recovery?" On failure the kubelet kills the container and the restart policy applies. This is the dangerous one. If your liveness probe hits an endpoint that also does real work, then under load it times out, the kubelet kills a pod that was merely busy, load shifts to the remaining pods, they get busier, and you have built a cascading restart loop that takes the service down. A liveness probe should test almost nothing: that the process is alive and its event loop is turning. If you cannot name a failure mode where the process is running but permanently unrecoverable, you do not need a liveness probe at all, and no probe is safer than a bad one.
Startup exists because those two have incompatible requirements during boot. A JVM that takes 90 seconds to warm up needs a long liveness timeout, but a long timeout means a genuinely wedged process is not restarted for 90 seconds forever after. The startup probe resolves it: while it is failing, liveness and readiness are suspended, and once it passes it never runs again. So you get a generous boot allowance and an aggressive steady-state check. Use failureThreshold and periodSeconds to size the startup allowance, including configured initial delay and probe timing. Kubernetes probe configuration.
The configuration that most often causes an incident: liveness and readiness pointed at the same handler. That handler checks the database, the database gets slow, every pod fails liveness simultaneously, and the entire deployment restarts at once. Readiness on dependencies, liveness on the process, never the same endpoint.
What interviewers probe next
"When would you use no liveness probe?" Most of the time. If a crash exits the process, the restart policy already handles it. Liveness is for the deadlock case specifically.
"How do the probes interact with a rolling update?" Readiness gates it. A new pod that never becomes Ready blocks the rollout, which is a feature: it stops a broken version replacing a working one.
"What about exec probes?" They fork a process on every check. At high frequency across many pods that is real overhead, and a slow exec probe can pile up. Prefer HTTP or gRPC where you have the choice.
Common mistakes
Using the same endpoint for liveness and readiness, which is the single most common cause of probe-induced outages.
Making liveness check dependencies. If the database is down, restarting your pod does not help and makes recovery slower.
Not knowing the startup probe exists, then using a long initialDelaySeconds without a startup probe. Initial delay applies only after container startup; it does not delay every steady-state failure detection.