Choose health probes for a slow-starting service.

Example Answer

I would use a startup probe to allow measured initialization time, readiness to express whether this instance can serve the traffic it will receive, and liveness for an internal condition that restarting can actually repair. A database outage should not automatically trigger app restarts.

Because this service can still serve cached reads, I would make the routing contract explicit. A single readiness bit cannot distinguish reads from writes unless the deployment and routing design support that separation. We could keep reads available while rejecting writes predictably, or remove the instance from mixed traffic if that is the agreed contract.

Worked reasoning

An illustrative startup budget is periodSeconds: 5 and failureThreshold: 20, roughly 100 seconds of failed checks, leaving margin above the observed 80 seconds. It is a tuning starting point, not a precise startup deadline or a substitute for measuring cold starts.

When a startup probe is configured, readiness and liveness checks wait until it succeeds. Readiness failure makes the Pod unready for ordinary Service traffic; it does not restart the container. Repeated liveness failure triggers a restart. Endpoint changes and connections still have propagation and lifecycle details.

Test slow startup, temporary dependency loss and a truly wedged process separately. Confirm that degraded read behavior is truthful and that writes fail clearly without being partially accepted.

What the interviewer is assessing

Core checks (1 point each):

• Assigns startup, readiness and liveness distinct purposes.
• Removes the failing database from restart-triggering logic.
• Addresses read/write routing instead of assuming a single readiness bit is granular.

Stronger (+1 after all core checks): Tests initialization timing and readiness propagation under the actual rollout strategy.

Acceptable alternatives: Separating read and write workloads is optional; a clearly stated mixed-traffic contract can also work.

Red flags: Uses dependency availability as universal liveness or claims readiness failure restarts a container.

Follow-up

The process is alive but its request loop is deadlocked. Which check should fail?

Example response: A liveness check can detect a local unrecoverable stall if it actually exercises the stuck component and avoids the same external dependency problem. It must have enough tolerance for expected pauses so it does not create a restart loop under normal load.