Implement deployment strategies for container workloads on Amazon ECS and Amazon EKS, including blue/green deployments with AWS CodeDeploy and rolling updates.

A payments team runs a containerised service as an Amazon ECS service on AWS Fargate behind an Application Load Balancer. Releases currently use the default rolling update, and a recent bad image briefly served errors to live users before tasks were replaced. The team now wants each release to stand up the new task set in full, expose it on a separate test listener so an automated suite can validate it, and shift production traffic across only after validation passes, with an instant reroute back to the old task set if anything fails. Which deployment approach MOST directly meets this requirement?

• AKeep the ECS rolling update controller but lower the minimum healthy percent so fewer new tasks start at once, then add a container health check that fails fast when the new image misbehaves under live traffic.
• BKeep the ECS rolling update controller and add a CodeDeploy in-place hook that runs the validation suite against each replacement task before it joins the target group, failing the deployment if a check fails.
• CKeep the ECS rolling update controller but raise the maximum percent to 200 so a full second set of tasks starts before any old task stops, giving a parallel fleet that the load balancer validates before cutover.
• DSwitch the ECS service to the CodeDeploy deployment controller so a blue/green deployment creates a replacement task set, registers it behind a test listener for automated validation, then shifts the production listener to it with one-click rollback.check_circle Correct

Why A is wrong: Tuning rolling update percentages slows the replacement and isolates failures a little, but new tasks still take live production traffic during the rollout, so there is no separate test listener and no instant reroute to a preserved old task set.

Why B is wrong: CodeDeploy in-place deployments target EC2 and on-premises hosts, not ECS task sets, so this mixes an EC2 model into an ECS service and still validates tasks only as they enter the live production target group.

Why C is wrong: A maximum percent of 200 doubles task count during the rollout but both task sets share the same production target group, so there is no isolated test listener and no clean reroute back to the original tasks.

Why D is correct: The CodeDeploy deployment controller for ECS builds a green task set, exposes it on a test listener for validation hooks, and only then shifts the production listener, keeping the blue task set for an instant reroute on failure.