After a canary deployment, error budgets burn and logs/metrics implicate the new Lambda version. What observability-backed action should the team take?
Select an answer to reveal the explanation.
Short Explanation
When the canary burns the error budget and the graphs blame the new version, roll traffic back to the prior alias. Observability is there so you can reverse course with evidence, not vibes.
Full Explanation
After a canary deployment, when error budgets burn and logs plus metrics implicate the new Lambda version, the correct observability-backed action is to roll traffic back to the prior alias target or previous version. Canary weighting exists so municipal operators can limit blast radius and reverse quickly when citizen-facing error rates climb. Restoring the last good revision stops the bleeding while the bad version remains available for forensic comparison without serving production traffic.
Increasing the canary weight to 100% spreads the defective revision to everyone and accelerates error-budget burn instead of containing it.
Disabling CloudWatch so the error budget "stops counting" removes signal without restoring correct behavior for citizens.
Deleting the DynamoDB table shared by both versions is destructive data loss, not a traffic rollback, and can outage both old and new code paths.
Exam caveat: Canary without rollback criteria is incomplete. Associate questions expect alias/traffic reversal guided by metrics and logs.
Operational check: Immediately shift the alias to the last good version, verify error rate and synthetic transactions recover, keep alarms enabled, and capture version IDs in the incident record before the next canary attempt. Keep the civic/municipal context in mind: fee and records APIs should fail closed to the last known-good revision rather than "push through" a burning canary.