Use per-project S3 Lifecycle expiration after 60 days to purge project data cost-effectively

Design and implement controls to manage the lifecycle of data at rest. Evaluate the compliance of AWS resources.
Answer Correct answer: C — per-project S3 Lifecycle configurations that expire objects after 60 days delete data cost-effectively at project end.

A company is developing a mechanism that will help data scientists use Amazon SageMaker to read, process, and output data to an Amazon S3 bucket. Data scientists will have access to a dedicated S3 prefix for each of their projects. The company will implement bucket policies that use the dedicated S3 prefixes to restrict access to the S3 objects. The projects can last up to 60 days. The company's security team mandates that data cannot remain in the S3 bucket after the end of the projects that use the data. Which solution will meet these requirements MOST cost-effectively?

  1. Create an AWS Lambda function to identify and delete objects in the S3 bucket that have not been accessed for 60 days. Create an Amazon EventBridge scheduled rule that runs every day to invoke the Lambda function.
  2. Create a new S3 bucket. Configure the new S3 bucket to use S3 Intelligent-Tiering. Copy the objects to the new S3 bucket.
  3. Create an S3 Lifecycle configuration for each S3 bucket prefix for each project. Set the S3 Lifecycle configurations to expire objects after 60 days. Correct Answer
  4. Create an AWS Lambda function to delete objects that have not been accessed for 60 days. Create an S3 event notification for S3 Intelligent-Tiering automatic archival events to invoke the Lambda function.

Community Votes

C
100%

100% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

S3 Lifecycle expiration is a native, zero-compute way to delete objects after a set age, directly enforcing the 'data cannot remain after the project' rule per prefix. A Lambda/EventBridge cleanup (A/D) adds ongoing compute cost and operational overhead, and Intelligent-Tiering (B) only changes storage class, it does not delete.

Each data-science project gets a dedicated S3 prefix and must not leave data in the bucket after the project ends (up to 60 days). The most cost-effective control is an S3 Lifecycle configuration on each project prefix that expires (deletes) objects 60 days after creation, automatically removing data at project end without custom code, functions, or tiering.

Building a Lambda + EventBridge scheduled job (option A) or Lambda on Intelligent-Tiering events (option D) to delete by last-access—more cost and complexity than a Lifecycle rule, and last-access tracking is not the same as project-end. Option B copies to a new bucket with Intelligent-Tiering, which stores rather than deletes.

Community Discussion (10 comments)

rishikeshshukla7777 👍 5
anyone given exam in this week or last week can anyone confirm is this question is good for practise or required more question ?
ion_gee 👍 1 Selected: C
C makes the most sense
ale_brd_111 👍 1 Selected: C
no brainer C.
Gzuis 👍 1
my vote is for C
nublit 👍 1 Selected: C
C for sure
sarcactus 👍 1 Selected: C
C is the correct one. https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-configuration-examples.html#lifecycle-config-conceptual-ex3
anasbakla 👍 2
C is the answer
anasbakla 👍 1
Me too
awssecuritynewbie 👍 1 Selected: C
C makes sense you need to remove the data after 60 day so lifecycle will do that.
jabilrn 👍 1
C for me

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

An S3 Lifecycle configuration per project prefix with an expiration of 60 days automatically deletes objects at the project boundary, satisfying the security mandate cost-effectively with no running infrastructure. This is the native, lowest-cost mechanism for time-based deletion.

Why the Other Options Are Wrong

A and D invoke Lambda (on a schedule or on tiering events) to delete by access age, adding compute cost and maintenance versus a Lifecycle rule, and 'not accessed for 60 days' is not the same as 'project ended.' B copies data to a new bucket with Intelligent-Tiering, which changes storage class but does not remove data. C is the purpose-built, cost-free expiration control.

Community Comment Notes

Community voted C (100). Commenters called it a straightforward Lifecycle-expiration case and linked the lifecycle-config examples doc. The policy mandate (no data after project end, up to 60 days) maps exactly to per-prefix expiration.

Official Reference

Related Analysis

← Back to SCS-C02 Study Guide