A containerized 311 intake service on ECS must cut over safely and keep the prior task set for a fast revert. Which blue/green approach fits?
Select an answer to reveal the explanation.
Short Explanation
Blue/green on ECS is two teams on the field: CodeDeploy moves the crowd to the new task set after health checks, but keeps the old roster warmed up. Instant revert beats "stop everything and hope."
Full Explanation
For a containerized 311 intake service on ECS, blue/green means maintaining two task sets and shifting traffic only after the new set is healthy, while retaining the old set for quick rollback. AWS CodeDeploy integrates with ECS to perform that controlled traffic shift (for example via load balancer target groups) after health success. Citizens calling 311 keep a fast revert path if the new intake revision mis-routes tickets.
Replacing tasks in place with no second task set removes environment-level rollback and traffic-shift controls. Stopping all tasks, waiting an hour, then starting only the new definition creates an outage window and skips health-gated shifting. Publishing containers only to a developer's laptop Docker daemon never engages ECS service traffic management.
Exam caveat: ECS rolling updates differ from CodeDeploy blue/green with dual task sets; read the question's rollback and traffic-shift cues carefully.
Operational check: start a CodeDeploy ECS blue/green for the 311 service, confirm the new task set passes health checks before listener cutover, verify the old task set remains available for rollback, and rehearse a reverse shift in a non-production cluster before production night.