Protecting an S3 bucket from deletion by leaked long-term credentials using Object Lock

Answer Correct answer: A — Isolate data in a security-team account, enable S3 Versioning and Object Lock with 1-year retention, and replicate existing and future objects under WORM.

A company has an application that stores data in a single Amazon S3 bucket. The company must keep all data for 1 year. The company’s security team is concerned that an attacker could gain access to the AWS account through leaked long-term credentials. Which solution will ensure that existing and future objects in the S3 bucket are protected?

  1. Create a new AWS account that is accessible only to the security team through an assumed role. Create an S3 bucket in the new account. Enable S3 Versioning and S3 Object Lock. Configure a default retention period of 1 year. Set up replication from the existing S3 bucket to the new S3 bucket. Create an S3 Batch Replication job to copy all existing data. Correct Answer
  2. Use the s3-bucket-versioning-enabled AWS Config managed rule. Configure an automatic remediation action that uses an AWS Lambda function to enable S3 Versioning and MFA Delete on noncompliant resources. Add an S3 Lifecycle rule to delete objects after 1 year.
  3. Explicitly deny bucket creation from all users and roles except for an AWS Service Catalog launch constraint role. Define a Service Catalog product for the creation of the S3 bucket to force S3 Versioning and MFA Delete to be enabled. Authorize users to launch the product when they need to create an S3 bucket.
  4. Enable Amazon GuardDuty with the S3 protection feature for the account and the AWS Region. Add an S3 Lifecycle rule to delete objects after 1 year.

Community Votes

A
71%
D
29%

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

Community Insight

S3 Object Lock (WORM) prevents deletion or overwrite for the retention period even by a user with valid credentials, so isolating data in a locked bucket neutralizes the risk of leaked long-term credentials better than detection-only or MFA-delete controls.

To protect existing and future objects against an attacker holding leaked credentials, isolate the data in a security-team account and apply S3 Object Lock with a 1-year retention. Replicate from the source bucket (including a Batch Replication job for existing objects) so WORM protection covers all data regardless of who holds credentials.

Relying on GuardDuty (Option D) — it only detects suspicious S3 activity; it does not prevent an attacker with valid credentials from deleting or overwriting objects.

Community Discussion (13 comments)

nharaz 👍 8 Selected: A
S3 Object Lock - prevents objects from being deleted or overwritten for a fixed amount of time or indefinitely, adding a layer of protection against malicious or accidental deletion. Replication - to a new account limits the risk of a single point of compromise; even if attackers gain access to the original account, they cannot alter or delete the locked objects in the replicated bucket. Versioning - keeps multiple versions of an object in an S3 bucket, providing additional security and recovery options.
career360guru 👍 5 Selected: D
Option D is the only option that addresses security risk. Option A is not addressing this - Replicating existing bucket to another bucket does not eliminate the risk due to original bucket credential leak.
0b43291 👍 2 Selected: A
Option A, the company can effectively isolate sensitive data in a separate, secure account with strict access controls, while ensuring that both existing and future data are protected against unauthorized access, deletion, or modification, even if the original account's credentials are compromised. The other options do not provide the same level of protection or have limitations: Option B relies on AWS Config and automatic remediation, which may not be effective if the attacker gains access to the account and disables or modifies these configurations. Option C focuses on controlling bucket creation but does not address the protection of existing data or objects in the current bucket. Option D relies on Amazon GuardDuty, which is a threat detection service and does not provide the same level of data protection as S3 Versioning and Object Lock.
AzureDP900 👍 1
The correct answer to this question is Option C. Explicitly denying bucket creation from all users and roles except for an AWS Service Catalog launch constraint role, defining a Service Catalog product for the creation of the S3 bucket, and forcing S3 Versioning and MFA Delete ensures that existing and future objects in the S3 bucket are protected. This option provides explicit access controls for S3 bucket creation and forces S3 versioning and MFA Delete on noncompliant resources, making it the most suitable solution to address the security concerns of the company. Option A is not the best choice because creating a new AWS account can introduce complexity and create a single point of failure. While Options B and D offer some benefits, they do not provide explicit access controls for S3 bucket creation, which is essential for protecting sensitive data.
AloraCloud 👍 1
Eliminate C & D
vip2 👍 1 Selected: A
A assume role to provide short-term credential
TonytheTiger 👍 2 Selected: A
Option A: Amazon S3 now allows you to enable S3 Object Lock for existing buckets with just a few clicks and to enable S3 Replication for buckets using S3 Object Lock https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-s3-enabling-object-lock-buckets/#:~:text=To%20lock%20existing%20objects%2C%20you,of%20objects%20at%20a%20time.
Dgix 👍 2 Selected: A
The question is, as so often, misleading. None of the alternatives deal with _access_, only with modification.
bjexamprep 👍 2
The question is looking for solution for “concerned that an attacker could gain access to the AWS account through leaked long-term credentials”. None of the answer is addressing the concern of “Access” Through “leaked long-term credentials”. The is question doesn’t mention anything about data loss concerns, while, all the answers are providing protection for deleting the data.
TheCloudGuruu 👍 2 Selected: D
Answer is D. It's the only one that specifically addresses the issue. The question never said only the security team needs access.
kejam 👍 2 Selected: A
https://repost.aws/knowledge-center/s3-cross-account-replication-object-lock
duriselvan 👍 3
A ans : https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html
alexis123456 👍 1
Correct Answer is A

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

Option A directly addresses the threat: an attacker with leaked long-term credentials could otherwise delete or overwrite data. By replicating into a separate security-team account and enabling S3 Object Lock with a 1-year default retention, objects become immutable for that period even to a credential holder. S3 Versioning plus Batch Replication brings both existing and future objects under protection.

Why the Other Options Are Wrong

Option B and C depend on MFA Delete or Service Catalog constraints, which add friction but are not as absolute as WORM retention and still leave windows where valid credentials can act. Option D (GuardDuty) is detect-only and cannot prevent deletion. The security team's concern is prevention, not detection.

Community Comment Notes

nharaz (likes 8) explains Object Lock prevents deletion/overwrite and replication covers existing data. career360guru (likes 5) argues D is the only option addressing the security risk and that replicating does not remove the original-bucket credential risk — a fair caveat, but Object Lock's immutability is the stronger control for the stated goal.

Official Reference

Related Analysis

Practice All SAP-C02 Questions

Access 85 questions with complete answers and detailed explanations.

View Full SAP-C02 Practice Test →

← Back to SAP-C02 Study Guide