CloudFormation DeletionPolicy: Retain S3 Buckets When Stack Is Deleted
Exhibit
Refer to the exhibit.
Resources:
MyBucket:
Type: AWS::S3::Bucket
Properties:
BucketName: !Sub "${AWS::StackName}-mybucket-${AWS::Region}"
VersioningConfiguration:
Status: Enabled
DeletionPolicy: RetainA DevOps engineer deploys the CloudFormation snippet shown in the exhibit. After the stack is deleted, the engineer checks for the S3 bucket. Which statement best describes the outcome?
⚠ Common exam trap
It's easy for candidates to assume stack deletion always removes all resources, overlooking that the DeletionPolicy attribute can explicitly override that behavior for supported resource types like S3 buckets.
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
✓
The bucket is retained (not deleted) after the stack deletion.
S3 bucket versioning has no bearing on this stack's deletion mechanics since the bucket uses DeletionPolicy: Retain, so CloudFormation never attempts to delete the physical bucket. More generally, versioning is a bucket-level data-protection feature; it does not, by itself, cause a CloudFormation stack deletion to fail. However, note that CloudFormation does NOT automatically empty a bucket's object versions and delete markers before deleting it -- if DeletionPolicy were Delete (the default) and the bucket were non-empty (including having any object versions), the stack deletion would fail with a 'bucket not empty' error, requiring a custom resource or manual emptying first. Because this stack uses Retain, the deletion action is never attempted, so the bucket -- and any versioned objects in it -- persists after the stack is deleted.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The bucket is deleted because the stack deletion overrides the DeletionPolicy.
Why it's wrong here
This statement reverses the actual precedence. CloudFormation's DeletionPolicy attribute is evaluated as part of the stack deletion operation and is the final authority on whether a physical resource is removed; a plain stack deletion cannot override it. With 'Retain' set, CloudFormation deliberately skips the bucket deletion, so the bucket is preserved despite the stack being successfully deleted.
- ✓
The bucket is retained (not deleted) after the stack deletion.
Why this is correct
When a CloudFormation stack that contains an AWS::S3::Bucket with DeletionPolicy: Retain is deleted, the template's deletion intent is to leave that bucket in place. The bucket, including any objects and versions, remains in your AWS account and is no longer under CloudFormation's management. The stack itself shows DELETE_COMPLETE because CloudFormation treats the Retain policy as a successful completion of the resource deletion step, even though no physical deletion occurred.
- ✗
The stack deletion fails because the bucket has versioning enabled.
Why it's wrong here
S3 bucket versioning has no bearing on CloudFormation stack deletion mechanics. Versioning is a bucket-level data-protection feature; it does not lock the bucket against deletion of the bucket itself, nor does it cause CloudFormation to fail a stack deletion. In the absence of a Retain policy, CloudFormation can delete a versioned bucket by purging all object versions and delete markers before issuing the DELETE_BUCKET call. More importantly, because this stack uses Retain, the deletion action is never attempted, so versioning cannot trigger a failure.
- ✗
The bucket is deleted along with the stack because the DeletionPolicy is not supported for S3 buckets.
Why it's wrong here
This claim is factually incorrect because DeletionPolicy is explicitly supported for AWS::S3::Bucket and is widely used for exactly this purpose. The CloudFormation documentation lists S3::Bucket as a resource that supports the Retain value, and the default (no policy) is Delete. Defining 'DeletionPolicy: Retain' on the bucket is the standard way to prevent data loss when a stack is removed; therefore the bucket is preserved, not deleted.
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
Courseiva writes every DOP-C02 question from scratch — 1,298 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. 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.