Which statement best describes blue-green deployment?

Which statement best describes blue-green deployment?

• A. Two production environments exist; traffic switches to the new version in a single cutover; rollback by switching back; use for high-risk releases or zero-downtime.
• B. A strategy where both versions run in parallel with continuous A/B tests.
• C. A deployment method that updates servers in place.
• D. A canary approach with gradual traffic.

Answer: (A)

Blue-green deployment is about two production environments that are identical in setup: one hosts the current live release, the other contains the new release ready to go. When you release, you switch all user traffic from the old environment to the new one in a single cutover. If something goes wrong, you can flip traffic back to the old environment quickly, giving you a fast and reliable rollback with minimal downtime. This setup is ideal for high-risk releases or scenarios where zero-downtime is important because the transition is a controlled swap between two complete environments rather than gradually updating live servers. This differs from strategies that involve gradually shifting traffic to a new version or running both versions in a rolling fashion for testing, which is more like canary or A/B testing. It also differs from updating servers in place, which doesn’t preserve a ready-to-switch duplicate environment.

Blue-green deployment is about two production environments that are identical in setup: one hosts the current live release, the other contains the new release ready to go. When you release, you switch all user traffic from the old environment to the new one in a single cutover. If something goes wrong, you can flip traffic back to the old environment quickly, giving you a fast and reliable rollback with minimal downtime. This setup is ideal for high-risk releases or scenarios where zero-downtime is important because the transition is a controlled swap between two complete environments rather than gradually updating live servers.

This differs from strategies that involve gradually shifting traffic to a new version or running both versions in a rolling fashion for testing, which is more like canary or A/B testing. It also differs from updating servers in place, which doesn’t preserve a ready-to-switch duplicate environment.