Explain blue-green deployment, its prerequisites, and how it reduces deployment risk.

WHAT THIS TESTS: Whether you can design a deployment strategy that eliminates in-place mutation risk by running two isolated production environments and cutting over traffic atomically. Interviewers want to see that you understand this is not just "two servers" but a cross-layer contract involving infrastructure orchestration, application statelessness, and database schema discipline.

A GOOD ANSWER COVERS: First, the core concept: blue is live production, green is an identical stack running the new version, and a load balancer or DNS switch moves traffic instantly. Second, infrastructure prerequisites: you need automated provisioning so green is truly identical, a health check mechanism to validate green before cutover, and enough capacity to run both environments simultaneously without starving blue. Third, application prerequisites: sessions must be externalized to Redis or a database so requests can bounce between environments without loss, and configuration must be environment-agnostic so green does not accidentally point to blue backends. Fourth, database prerequisites: schema changes must be backward compatible so both blue and green can read and write safely during the transition; destructive changes like column drops happen only after green is fully promoted and blue is drained. Fifth, risk reduction: because the old environment stays warm, rollback is a single traffic switch rather than a redeploy, and you never suffer partial fleet updates where some nodes are on different versions.

COMMON WRONG ANSWERS: Calling it a rolling update or canary; these reuse the same infrastructure. Saying you need zero schema changes instead of backward-compatible ones. Ignoring the doubling of infrastructure cost and capacity. Claiming blue-green solves database migrations automatically without explaining expand-contract patterns or compatibility windows.

LIKELY FOLLOW-UPS: How do you handle long-running transactions during cutover? What happens if green passes health checks but fails under real traffic? How do you manage database migrations when the schema must serve two application versions? When would you choose canary over blue-green?

ONE CONCRETE EXAMPLE: A web service on EC2 behind an ALB uses blue-green deployment. The Auto Scaling group for green is cloned from blue via infrastructure as code. The database adds a new nullable index before cutover so green can use it while blue ignores it. Sessions live in ElastiCache, so users do not notice the ALB target group switch. If error rates spike after cutover, the ALB shifts traffic back to blue in under thirty seconds while the team debugs green.