DOP-C02 Practice Question 1: Lambda Canary Deployment Rollback

A canary deployment configuration shifts a fixed small percentage of traffic in the first increment and holds it there for a defined interval before shifting the remainder. CodeDeployDefault.LambdaCanary10Percent10Minutes sends 10 percent of traffic to the new function version and waits 10 minutes, exactly the "small slice, then soak" requirement. CodeDeploy deployment groups accept a CloudWatch alarm configuration plus an automatic rollback setting of "roll back when alarm thresholds are met". When the alarm enters ALARM state during the deployment, CodeDeploy stops the deployment and redeploys the last known good revision as a new deployment, returning 100 percent of traffic to the previous version with no human action.

Option A is a *linear* configuration: it shifts 10 percent every minute continuously, so there is no soak period at a fixed small percentage, and a manual approval gate runs before the deployment starts rather than reacting to production error rates during it. It also puts an engineer in the loop, which the stem forbids.

Option B shifts all traffic at once, which defeats the entire purpose. Hand-managing a weighted alias outside CodeDeploy also gives up the automatic rollback machinery, nothing would shift traffic back on its own.

Option D uses the wrong hook and the wrong mechanism. BeforeAllowTraffic for a Lambda deployment runs *before* any traffic is shifted to the new version, so it cannot observe production error rates from the canary. The hook that runs after the canary increment is AfterAllowTraffic. Building your own alarm-polling logic is also strictly worse than the built-in alarm-based rollback, which is what the deployment group option exists for.

Reference: Working with deployment configurations in CodeDeploy