DOP-C02 SDLC Automation Practice Question
A developer is using AWS CloudFormation to deploy a stack that includes an AWS Lambda function. The Lambda function code is stored in an S3 bucket. The CloudFormation template references the S3 bucket and object key. The developer wants to update the Lambda function code by uploading a new zip file to S3 and then updating the stack. The developer updates the S3 object with a new version, but the stack update does not automatically use the new code. What should the developer do to ensure the stack update uses the new code?
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Upload the new code to a different S3 key or specify a new version ID in the CloudFormation template.
CloudFormation only detects changes to S3 objects if the S3 key or version changes. By uploading the new code with a different key or specifying a new version ID in the template, CloudFormation will recognize the change and update the Lambda function. Option A is incorrect because S3 event notifications do not automatically trigger stack updates for code changes; they are typically used for other automation. Option B is incorrect because stack policies control whether resources can be updated, but they do not cause CloudFormation to detect the code change; the template reference itself must indicate a new version. Option C is incorrect because deleting and recreating the stack is unnecessary and disruptive; a simple stack update with a new version ID is sufficient.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable S3 event notifications to trigger a CloudFormation stack update when the object is updated.
Why it's wrong here
S3 event notifications can invoke Lambda functions or SNS topics, but CloudFormation has no native trigger to act on such events. Even if you built custom automation to call UpdateStack, CloudFormation would still compare the template's declared S3 key and version to what was previously deployed—since those haven't changed, it would report 'no updates to perform' despite the new object content. The notification would not cause the template to change, so this approach fails to force the stack to recognize the new code.
- ✗
Modify the CloudFormation stack policy to allow updates to the Lambda function.
Why it's wrong here
A CloudFormation stack policy is an IAM-like policy that controls which resources can be updated during a stack update; it does not influence how CloudFormation detects resource changes. If the template still references the same S3 key without a version ID, CloudFormation treats the resource as unchanged regardless of the stack policy's permissions. The core issue here is that CloudFormation only tracks declarative properties listed in the template, not the underlying S3 object's content, so authorizing the update does not make it happen.
- ✗
Delete the stack and recreate it with the new code.
Why it's wrong here
Deleting and recreating the stack is an unnecessarily destructive approach that removes all resources managed by the stack, causing downtime and potentially losing data or configuration for stateful services. A stack update that changes the S3 key or specifies an S3ObjectVersion will trigger CloudFormation to replace or update the Lambda function's code while leaving other resources intact. This also preserves the stack's change history, rollback capabilities, and any associated resource dependencies.
- ✓
Upload the new code to a different S3 key or specify a new version ID in the CloudFormation template.
Why this is correct
CloudFormation tracks the AWS::Lambda::Function Code property using the literal values of S3Bucket, S3Key, and optionally S3ObjectVersion. Uploading new code to a different S3 key—or to the same key with a new object version ID—makes one of those template properties change, so a stack update sees a diff and refreshes the Lambda function's code. This is the standard practice because CloudFormation does not automatically compare content hashes or ETags; it relies on explicit property changes. If you reuse the same key and do not specify a version (or S3 versioning is disabled), CloudFormation will not detect the update and the function continues running old code.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
One of 1,298 original DOP-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.