# Guided Exercise: Planning a Safe Rollout Strategy

Paper-and-thinking exercise — work through this before the Lab.

## The scenario

Your team runs `api-server`, a Deployment with 6 replicas serving live traffic. You need to
ship a new image version. The team lead asks: "what could go wrong, and how would we know
before it takes down the whole service?"

## Your task

Work through these questions:

1. If the new image has a bug that crashes the container immediately on startup, at what point
   in the rolling update would you expect to notice — after 1 new Pod, after all 6, or somewhere
   in between? Why?
2. What's the difference in blast radius between that crash-on-startup bug and a subtler bug
   that only fails under load, several minutes after a Pod starts serving traffic?
3. Given your answer to question 2, what's the practical value of watching `kubectl rollout
   status` and `kubectl get pods` DURING a rollout, rather than only checking after it reports
   "successfully rolled out"?
4. If you noticed a problem partway through, what's the single command that gets you back to
   the last known-good state fastest?

## A worked answer to check yourself against

1. After the FIRST new Pod — a crash-on-startup bug means the new Pod never becomes Ready
   (`CrashLoopBackOff`), so the rollout stalls immediately, well before more old Pods are
   removed. This is actually the SAFEST kind of bug, because the blast radius stays tiny.
2. A crash-on-startup bug is naturally self-limiting (the rollout stalls itself, as above). A
   bug that only appears under load is NOT self-limiting the same way — by the time it's
   noticeable, several old (working) replicas may already have been replaced, meaning a larger
   fraction of real traffic is already hitting the broken version.
3. Watching during the rollout, not just checking the final "successfully rolled out" message,
   is what lets you catch the load-dependent case in question 2 early — waiting for the final
   status alone would let the rollout complete entirely (100% on the broken version) before you
   noticed anything wrong.
4. `kubectl rollout undo deployment/api-server` — assuming the previous ReplicaSet is still
   present (the default), this is faster than trying to hand-diagnose and hot-fix the new
   version under pressure.

## Instructor Notes

**Facilitation:** Question 2's distinction (self-limiting vs. not) is the core insight worth
making sure lands — it's why "the rollout said success" is necessary but not sufficient
evidence that a deploy actually went well.

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

**Optional extension:** ask what monitoring/observability signal (beyond `kubectl` output) a
real team would want during a rollout to catch the load-dependent case even faster (a good
forward pointer to ROOT 10's observability themes, without needing to build any actual
monitoring infrastructure here).