SAP-C02 Continuous Improvement for Existing Solutions Practice Question

A company uses AWS CloudFormation to manage infrastructure. They have a stack that creates an S3 bucket and a Lambda function that processes objects uploaded to the bucket. Recently, updates to the Lambda code caused the stack update to fail because the S3 bucket already existed in the account. What is the most efficient way to allow future updates without error?

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

✓

Use AWS CloudFormation resource import to bring the existing bucket into the stack.

The stack update failed because the S3 bucket already existed, likely due to it being removed from the template and then added back. By using AWS CloudFormation resource import, you can bring the existing bucket into the stack's management, preventing CloudFormation from attempting to create it again. This resolves the immediate error and allows future updates without conflict. DeletionPolicy Retain only prevents deletion, not creation conflicts.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Use AWS CloudFormation resource import to bring the existing bucket into the stack.
Why this is correct
AWS CloudFormation resource import allows you to bring existing resources under the management of a CloudFormation stack. Importing the existing S3 bucket means CloudFormation recognizes it and will not try to create it again during future updates, thus avoiding the 'resource already exists' error.
✗
Set the DeletionPolicy attribute to Retain on the S3 bucket resource in the CloudFormation template.
Why it's wrong here
Setting DeletionPolicy to Retain only protects the bucket from being deleted when the resource is removed from the template. It does not prevent CloudFormation from trying to create a new bucket with the same name if the resource is added back later, so the error would still occur.
✗
Use a custom resource to check if the bucket exists before creation.
Why it's wrong here
A custom resource could run code to check bucket existence, but it does not resolve the root cause: the stack update fails because CloudFormation attempts to recreate a bucket that already exists, and a custom resource does not alter CloudFormation’s own resource-handling behaviour for the `AWS::S3::Bucket` resource. This option is tempting because custom resources are designed to perform ad-hoc operations (like pre-flight checks) during stack operations, and in a scenario where you needed to conditionally skip resource creation based on external state, a custom resource would be the correct choice.
✗
Manually delete the S3 bucket before each stack update.
Why it's wrong here
Manually deleting the bucket before each update is inefficient, risky, and not a scalable solution. It also may result in data loss.

Visual reference

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

SAP-C02 Continuous Improvement for Existing Solutions Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question