# Reflection: Rollback Is a Plan, Not a Panic Button

You just completed a real rolling update. Take a few minutes to connect it to how this plays out
in a real production team.

## Reflection questions

1. "Successfully rolled out" (from `kubectl rollout status`) tells you every replica is Running
   and Ready. What does it NOT tell you about whether the new version is actually correct?
2. If you were on-call and a rollout you just ran seemed to be causing problems, would you reach
   for `kubectl rollout undo` immediately or try to hot-fix the new version first? What would
   change your answer?
3. Think back to the guided exercise's crash-on-startup vs. load-dependent distinction. Which
   one would a typical automated health check (like a readiness probe, ROOT 10) catch, and
   which one might slip through even with probes configured correctly?

## Real Ops takeaway

**A rollout completing is not the same as a deploy succeeding.** "Every Pod is Running and
Ready" only proves the new code started up and passed whatever checks are configured — it says
nothing about whether the new version is functionally correct under real traffic. Real teams
pair a rollout with actual monitoring (error rates, latency) before calling a deploy genuinely
successful, not just a green `kubectl rollout status`.

**Rollback should be a rehearsed, low-drama action, not a last resort.** Teams that treat
`kubectl rollout undo` as a normal, expected tool — something you reach for calmly the moment
something looks wrong — recover from bad deploys in seconds. Teams that treat rollback as an
admission of failure hesitate, try to hot-fix forward under pressure, and turn a small,
recoverable mistake into a longer outage.

This module is complete. Continue to the next module.

## Instructor Notes

**Discussion questions for a live classroom:** question 2 is worth pushing on — many students'
instinct is to try to fix forward, and it's worth surfacing WHY that instinct is often wrong
under time pressure (unknown time-to-fix vs. known, fast rollback).

**Approximate timing:** 8-10 minutes live discussion; 5 minutes self-paced writing.

**Optional extension:** ask students to write the one-sentence Slack message they'd post to
their team the moment they decide to roll back a bad deploy — reinforces that rollback is a
normal, communicable operational action, not a private failure.