A developer is implementing a serverless application by using AWS CloudFormation to provision Amazon S3 web hosting. Amazon API Gateway, and AWS Lambda functions. The Lambda function source code is zi

Question

Options

• ACreate a new Lambda function alias before updating the CloudFormation stack.
• BChange the S3 object key or the S3 version in the CloudFormation template before updating the
• CUpload the zipped source code to another S3 bucket before updating the CioudFormation stack.
• DAssociate a cade signing configuration with the Lambda function before updating the

• A
  9% (5)
• B
  84% (49)
• C
  2% (1)
• D
  5% (3)

Explanation

CloudFormation only updates a Lambda function when it detects a change in the template itself - if the S3 object key stays the same, CloudFormation sees no difference and skips the update, even if the zip file contents changed. Option B fixes this by changing either the S3 key (e.g., including a version hash or timestamp in the filename like function-v2.zip) or the S3 object version ID, signaling to CloudFormation that something changed and triggering a real deployment.

• A is wrong - Creating an alias is for traffic routing/versioning after deployment; it doesn't cause CloudFormation to detect or deploy new code.
• C is wrong - Moving the zip to a different bucket doesn't help unless the key or version reference in the template also changes; same root problem persists.
• D is wrong - Code signing is a security feature to verify code integrity; it has no effect on whether CloudFormation detects or deploys updated code.

Memory tip: Think of CloudFormation as a diff engine - it only acts on what changed in the template. If the S3 key/version in your template looks identical, CloudFormation assumes nothing changed. Always version your deployment artifacts (e.g., my-function-${git-sha}.zip) so the template reference changes with every release.

No community discussion yet for this question.