Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For AWS DVA-C02 candidates, confusion often lies in how S3 Lifecycle rules handle versioned buckets—specifically the difference between expiring current versions versus deleting noncurrent versions. In production, it’s critical to leverage lifecycle policies correctly so that objects are truly and permanently deleted after the retention period without building extra Lambda triggers that increase complexity and cost. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
TechNova Solutions is developing a web application that stores user-uploaded documents. The application requires versioned storage of all files in an Amazon S3 bucket to protect against accidental data loss. For compliance, all object versions must be permanently deleted exactly 1 year after their creation date. TechNova’s lead developer has enabled versioning on the S3 bucket. What should the developer do next to automate the data retention requirement?
The Requirement: #
Implement a solution that permanently deletes all versions of objects exactly 1 year after they are created in an S3 versioned bucket.
The Options #
- A) Create an S3 Lifecycle rule on the bucket. Configure it to expire the current versions of objects and permanently delete noncurrent versions 1 year after object creation.
- B) Create an event notification for all object creation events on the bucket. Configure the notification to trigger a Lambda function that checks the object creation date and deletes the object if older than 1 year.
- C) Create an event notification for all object removal events on the bucket. Configure the notification to trigger a Lambda function that checks the object creation date and deletes the object if older than 1 year.
- D) Create an S3 Lifecycle rule on the bucket. Configure it to delete expired object delete markers and permanently delete noncurrent versions 1 year after object creation.
Google adsense #
leave a comment:
Correct Answer #
A)
Quick Insight: The Developer Imperative #
When working with versioned S3 buckets, lifecycle policies can be configured both to expire current versions and to permanently delete previous (noncurrent) versions, making it the cleanest, most automated approach. Relying on Lambda triggers to check object ages adds unnecessary operational overhead and complexity.
Content Locked: The Expert Analysis #
You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?
The Expert’s Analysis #
Correct Answer #
Option A
The Winning Logic #
Option A is the correct choice because S3 Lifecycle policies natively support versioned buckets by allowing separate rules to:
- Expire “current” object versions after a specified number of days (here, 365 days).
- Permanently delete older, noncurrent object versions after the same interval.
This leverages built-in S3 functionality, minimizing complexity and cost while meeting retention exactly. It avoids the overhead and latency introduced by Lambda event-driven deletion approaches. Also, Lambda-based solutions in options B and C lack a reliable way to routinely evaluate all objects’ ages without additional scheduling or scanning logic, which is inefficient.
The Trap (Distractor Analysis): #
- Why not B?
Triggering a Lambda function on every object creation to check age later doesn’t make sense—objects are new on creation and wouldn’t be deleted immediately. You’d need scheduled triggers or DynamoDB state tracking, which greatly complicates designs. - Why not C?
Object removal events occur after deletions, so triggering a check on removal is counterintuitive and won’t handle primary deletion logic. - Why not D?
Deleting expired delete markers only applies when versioned deletes are used, but doesn’t cover expiring current versions. This option misses the core need to expire the current version after one year.
The Technical Blueprint #
aws s3api put-bucket-lifecycle-configuration \
--bucket technova-docs-bucket \
--lifecycle-configuration '{
"Rules": [
{
"ID": "ExpireCurrentVersions",
"Status": "Enabled",
"Filter": {},
"Expiration": {
"Days": 365
},
"NoncurrentVersionExpiration": {
"NoncurrentDays": 365
}
}
]
}'
This JSON snippet for AWS CLI sets up a lifecycle rule where both current and noncurrent versions are expired after 365 days.
The Comparative Analysis #
| Option | API Complexity | Performance | Use Case |
|---|---|---|---|
| A | Low - native lifecycle API | High - automated, no compute overhead | Best - automatic deletion after a year |
| B | High - requires Lambda coding and event handling | Moderate - Lambda invocation latency and cost | Overcomplicated for this use case |
| C | High - incorrect event trigger | Low - triggers unexpected | Not suitable for retention enforcement |
| D | Medium - lifecycle rule but incomplete | Moderate - partial cleanup only | Doesn’t expire current versions properly |
Real-World Application (Practitioner Insight) #
Exam Rule #
For the exam, always pick S3 Lifecycle policies when you see aging/deletion requirements in versioned buckets.
Real World #
In actual production, Lambda-based solutions are sometimes used when business logic requires additional validation before deletion, but for simple retention like this, lifecycle rules are idiomatic, cost-effective, and reliable.
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.