DOP-C02 Practice Question 6: ECS Blue Green Test Listener Validation

An ECS blue/green deployment group takes a required production listener and an optional test listener. The test listener is the mechanism for exactly this need: during the AllowTestTraffic lifecycle event CodeDeploy points the test listener at the replacement task set's target group, while the production listener still serves every customer request from the original task set. The AfterAllowTestTraffic hook then runs your validation Lambda function against that test endpoint. If the function returns Failed, the deployment is marked Failed and, with rollback configured, CodeDeploy reroutes to the original task set (which is still running and still serving production), so the abort is effectively instantaneous. Only after the hook succeeds does AllowTraffic shift the production listener.

Option A fails the isolation requirement twice over. BeforeInstall runs before the replacement task set exists, so there is nothing to test. And a canary configuration by definition puts 10 percent of *production* traffic on the new task set, which the stem forbids.

Option B tests after the fact. Once the production listener has been shifted, customers are already on the new version, so the smoke tests are detecting a customer-visible failure rather than preventing one. Setting the termination wait to zero also removes the fast rollback path, because the original task set is gone.

Option D is a parallel-environment pattern, not a blue/green one. It doubles the cluster footprint, and the artifact validated in the test cluster is not the running task set that will receive production traffic; configuration and load-balancer differences between the two clusters are exactly where release bugs hide. It also adds a manual promotion step CodeDeploy already automates.

Reference: Deployments on an Amazon ECS Compute Platform