5 exercises on blue-green and canary deployment vocabulary.
0 / 5 completed
1 / 5
What is the core idea of a blue-green deployment?
Blue-green: two identical production environments (blue = live, green = staging). You deploy the new version to green, test it, then switch the load balancer or DNS to green. Rollback is instant — flip traffic back to blue.
2 / 5
What is a canary deployment?
Canary: like the canary in a coal mine, a small slice of real traffic (e.g., 1-5%) hits the new version. Metrics are monitored; if healthy, the percentage grows. Issues affect only a fraction of users before they are caught.
3 / 5
What is a key cost disadvantage of blue-green deployments?
Cost: running two complete production stacks means double the compute, storage, and licensing cost during the release window. This is mitigated by cloud auto-scaling (spin up green, tear down blue after cutover) but still incurs transition costs.
4 / 5
What is the main operational advantage of canary over blue-green deployments?
Canary advantage: rather than an all-or-nothing traffic switch, canary releases catch production-specific bugs (real data, real users) while limiting exposure. Blue-green involves an instant full switch with higher risk if something was missed in testing.
5 / 5
What is a feature flag-based deployment compared to a canary?
Flag vs canary: a canary deploys different code to a subset of servers. A feature flag enables different code paths within the same deployment for a subset of users. Flags are more flexible (can target by user attribute) but require flag evaluation in every code path.