Walk through a blue-green deployment, and why does it reduce downtime risk?
Blue-green deployment keeps two identical production environments, “blue” (currently live) and “green” (the new version), running side by side. You deploy and fully test the new release on green while blue keeps serving all real traffic, then switch a router or load balancer to send traffic to green all at once. If anything’s wrong, you switch back to blue instantly, since it’s still running unchanged, rather than scrambling to roll back a broken in-place deployment.
Why this beats an in-place deployment
An in-place deployment overwrites the running version, so if the new code is broken, there’s no fast way back, you have to redeploy the old version and wait through the same slow deploy process again while production stays down. Blue-green sidesteps this by never touching the environment that’s currently serving traffic until the new one is proven, and keeps the old one instantly available as a fallback.
Best practice
Run real health checks and smoke tests against green before switching traffic, not just “it deployed without error.” Also keep the database schema compatible with both versions during the transition (avoid breaking migrations), since both blue and green may briefly need to work against the same database.
Edge case interviewers probe for
What happens to in-flight requests and open connections at the exact moment of the switch? A naive instant cutover can drop active user sessions or in-progress requests; the fix is a graceful cutover, draining existing connections from blue while routing new ones to green, rather than severing everything at once.
Common mistake
Treating blue-green as a substitute for testing, assuming that because rollback is fast, the new release doesn’t need to be validated first. Fast rollback reduces the cost of a mistake; it doesn’t reduce the chance of shipping one.
What the interviewer is checking
Whether you understand deployment strategy as a risk-management tool (fast, safe rollback) rather than just a way to “release code,” and whether you can reason about the messier real details like in-flight requests and schema compatibility.
Imagine a restaurant with two identical kitchens. Kitchen A is currently cooking every order that comes in. You quietly build and test a new menu in Kitchen B while Kitchen A keeps serving customers uninterrupted. Once you’re confident Kitchen B works, you flip a sign at the door so every new order goes to Kitchen B instead.
If Kitchen B’s new dishes turn out to have a problem, you just flip the sign back to Kitchen A, which never stopped working and is still exactly as it was. That’s the whole idea: you never touch the kitchen that’s actively feeding customers until the replacement is proven, so a bad new menu never leaves anyone without food while you fix it.
Why interviewers ask this
Deployment strategy directly affects production reliability, and it’s a common enough real-world responsibility that a DevOps candidate is expected to reason about it concretely, not just name-drop the term.
What a strong answer signals
That you think about rollback speed and in-flight traffic, not just “deploy the new version,” and that you know blue-green isn’t a replacement for pre-release testing.
Common follow-ups
- How is this different from a canary deployment?
- How do you handle database migrations across blue and green?
- What happens to active user sessions during the switch?
Advanced variation
“When would you pick canary over blue-green?” expects knowing canary gradually shifts a small percentage of traffic to catch issues with less blast radius, versus blue-green’s all-at-once cutover with instant full rollback.
A team’s in-place deployments meant every release carried real risk of extended downtime if something broke, since rolling back meant redeploying the previous version from scratch. Moving to blue-green with an automated health check gate before cutover meant a bad release could be caught by the health check and never receive traffic at all, and on the rare occasion a subtle bug slipped through, flipping back to the previous environment took seconds instead of the 20-plus minutes a redeploy used to take.
# Health-check green before touching any live traffic
if ! curl -sf https://green.internal/healthz; then
echo "green failed health check, aborting cutover"
exit 1
fi
# Point the load balancer at green; blue keeps running, untouched
lb-cli set-target --pool production --target green
# Keep blue warm for instant rollback
echo "cutover complete, blue retained as rollback target"- 1Blue-green keeps two full environments, only one of which serves live traffic at a time.
- 2The new version is tested on the idle environment before any real traffic reaches it.
- 3Rollback is instant, switch traffic back to the untouched previous environment.
- 4Fast rollback doesn’t replace pre-release testing, it just reduces the cost of a mistake.
- 5In-flight requests need a graceful drain, not an instant severing, at cutover.