After a bad Lambda alias traffic shift for a municipal payments function, CloudWatch shows error spikes. How should operations roll back quickly using existing versioning?
Select an answer to reveal the explanation.
Short Explanation
Aliases are light switches for versions. Flip the alias back to last night's good bulb—or reverse the Beanstalk/CodeDeploy cut—and the bad release stops answering citizens. Deleting the function or silencing alarms is panic, not rollback.
Full Explanation
Municipal payments Lambdas should be published as immutable versions and invoked through aliases (or equivalent traffic-shifting constructs on Beanstalk/CodeDeploy). When CloudWatch shows error spikes after a bad alias traffic shift, the fastest rollback is to retarget the alias to the previously successful version—or reverse the platform traffic shift—so the last known-good revision serves citizens again without rewriting code under pressure. Versioning exists precisely so operations can restore a numbered revision in seconds.
Deleting the Lambda and recreating it from memory discards version history and invites configuration drift during an incident. Increasing memory alone does not undo defective business logic; memory tuning is a performance lever, not a rollback mechanism. Disabling CloudWatch alarms hides the signal without restoring correct payment behavior and lengthens mean time to recovery for fee-bearing workloads.
Exam caveat: know the difference between publishing a new version, shifting alias weights (including canary), and rolling an alias pointer back; rollback is an alias/traffic action, not a delete-and-hope.
Operational check: during a payments incident, confirm which version the alias currently targets, shift it back to the prior good version, verify error rates and synthetic payment checks recover, and leave alarms enabled so you can prove the rollback worked for auditors and finance.