How to Update Lambda Code in CloudFormation When the S3 Zip Changes?

Why the Answer Is Correct

CloudFormation compares the previous and current template to decide whether a resource needs updating. For AWS::Lambda::Function, the code is identified solely by the S3Bucket, S3Key, and S3Version properties in the Code block. If you overwrite the zip file in the bucket but keep the same object key and no version ID, the template is byte-for-byte identical, so CloudFormation concludes nothing changed and skips the Lambda update. Changing the S3 object key (e.g., lambda-v2.zip) or pinning a new S3 object version forces a template diff, causing CloudFormation to deploy the new code. Comment [1] confirms this: 'You have to change the S3 Object Key and the Version every time you update the code.'

Why the Other Options Are Wrong

A is incorrect because a Lambda alias only routes invocations to a published version; it does not alter the CloudFormation template, so the stack update still sees no changes and the new zip is never deployed. C is wrong because uploading the zip to a different bucket accomplishes nothing unless you also edit the template's S3Bucket value — and at that point you are effectively doing B with extra effort. D is unrelated: a code signing configuration validates that deployment packages are signed by trusted publishers but has no effect on change detection or deployment triggering.

Community Comment Notes

Comments [1] and [3] both back answer B, with [3] noting the practical pattern of 'giving a new object key when loading the new zip file.' Comment [2] votes for A but concedes that 'B could also fit in this situation,' objecting only that manually editing the key/version is annoying for frequent deployments — a valid operational concern solved by CI/CD pipelines that inject unique keys or version IDs automatically. The vote distribution (B: 67 vs A: 33) and the technical reasoning align firmly with B as the correct answer.