# Guided Exercise: Configure a Readiness Probe

This is a paper-and-thinking exercise, not a Lab task — you won't run these commands against a
real cluster here (that comes next). The goal is to practice reading and writing a probe
definition correctly before you're diagnosing someone else's broken one.

## The scenario

You're deploying a small HTTP API that listens on port `3000` and exposes a health endpoint at
`/healthz`. It takes a couple of seconds to finish connecting to its database on startup — if a
request arrives before that finishes, it correctly returns a `503` at `/healthz` until it's
ready.

## Your task

Work out, on paper (or in a scratch file), what you'd write for this container's readiness
probe. Think through:

1. Which mechanism fits — `httpGet`, `tcpSocket`, or `exec`? (Hint: you have a real health
   endpoint that returns a meaningful status code — use it rather than a shallower check.)
2. What `port` and `path` should the probe target?
3. Roughly what `initialDelaySeconds` makes sense, given the database connection takes a couple
   of seconds?
4. Should this be a `readinessProbe`, a `livenessProbe`, or both? Justify your answer using the
   distinction from the lesson — what actually goes wrong if you get this specific choice wrong
   here?

## A worked shape to check yourself against

Your answer should end up structurally similar to this (exact field names matter more than the
precise numbers you chose):

```yaml
readinessProbe:
  httpGet:
    path: /healthz
    port: 3000
  initialDelaySeconds: 3
  periodSeconds: 5
```

If you reached for `livenessProbe` instead of `readinessProbe` for this specific scenario,
re-read the lesson's distinction before continuing — "returns 503 while warming up" is
precisely the readiness case, not the liveness case. A liveness probe here would restart a
perfectly healthy, still-starting container over and over, which never lets it finish starting.

## Instructor Notes

**Facilitation:** Have students write their probe block on paper or a shared doc before showing
the worked shape — resist showing the answer early, since the value here is in students
committing to an answer and comparing, not passively reading a correct one.

**Approximate timing:** 10-15 minutes live with discussion; 10 minutes self-paced.

**Common mistake to watch for:** choosing `livenessProbe` because "the app isn't healthy yet"
— this is the single most common real-world probe mistake and exactly what question 4 is
designed to surface before the next activity's real diagnostic task.

**Optional extension:** ask what would need to change in this same YAML if the health endpoint
took up to 60 seconds to become available on cold start (answer: a `startupProbe` with a
generous `failureThreshold` × `periodSeconds`, so liveness/readiness don't engage too early).