# Knowledge Check: Health Probes Answer each question yourself before reading the answer that follows it. This isn't graded — it's a checkpoint to catch a misunderstanding before you're troubleshooting a live Pod in the next activity. --- **1. A Pod shows `RESTARTS: 12` and `READY: 1/1`. What kind of probe failure, if any, is most consistent with this?** *Answer:* A liveness probe that was failing and has now recovered (or is intermittently failing) — the climbing restart count is the signature of liveness failures, since a failed liveness check causes the kubelet to kill and restart the container. `READY: 1/1` means it's currently passing its readiness check right now. --- **2. A Pod shows `RESTARTS: 0` and `READY: 0/1`, and has looked this way for several minutes. What kind of probe failure is most consistent with this?** *Answer:* A readiness probe that is failing. The container is running fine (no restarts), but Kubernetes has decided it isn't ready to receive traffic and has excluded it from the Service's endpoints. This is exactly the symptom you'll investigate in this module's lab. --- **3. Why does Kubernetes offer a separate startup probe instead of just making `initialDelaySeconds` on the liveness probe longer?** *Answer:* `initialDelaySeconds` is a fixed, one-size-fits-all wait before checks even begin — set it too short and a normally-slow startup gets killed; set it too long and every fast startup pays that same delay before liveness/readiness protection is even active. A startup probe instead keeps checking until the application actually reports ready (bounded by its own failure threshold), so liveness/readiness only take over once startup is confirmed done — correct for both a consistently slow app and one whose startup time varies. --- **4. True or false: a readiness probe failure will cause Kubernetes to restart the container.** *Answer:* False. A readiness probe failure only removes the Pod from Service endpoints — it does not restart anything. Only a liveness (or startup, before it succeeds once) probe failure causes a restart. ## Instructor Notes **Facilitation:** In a live classroom, ask these out loud and take verbal answers before revealing each one, rather than having students read this silently — the goal is to surface a wrong mental model while it's still cheap to correct. **Approximate timing:** 5 minutes. **Likely misconception this catches:** question 2 specifically catches students who default to "something is broken, kubectl logs will show an error" — for a pure readiness-probe misconfiguration, logs are usually clean, which is disorienting the first time you hit it.