A parameter increase for Lambda memory is required on an existing municipal SAM application. How should that change be released to the managed environment?
Select an answer to reveal the explanation.
Short Explanation
Change the recipe card, then bake the next batch from that card. Bump memory in SAM and ship a change set. Console-only edits make the kitchen lie about the recipe.
Full Explanation
A parameter increase for Lambda memory on an existing municipal SAM application should be made in the SAM template and released through a CloudFormation change set rather than click-ops drift. Updating existing templates keeps configuration changes under IaC control so the live function matches Git. Console-only memory edits create drift that the next stack update may silently revert or conflict with—poor Domain 3 Task 4 practice.
Changing memory only in the Lambda console and leaving the SAM template at the old value fails because the managed environment diverges from the template. Deleting the entire stack and recreating it from scratch for every memory tweak fails conceptually as unnecessary downtime and risk for a parameter change. Editing memory in production with the console, then copying the number into a wiki page fails by using wikis as a non-executable source of truth.
Exam caveat: memory changes can alter cost and CPU allocation proportionally—validate in test with representative loads before production change sets. Operational check: edit the SAM memory property, review the change set for the function configuration update only, deploy to test, confirm CloudWatch metrics, then promote the same template change to production.