DOP-C02 Security and Compliance Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Enable S3 Versioning on the bucket.

  Why it's wrong here

  Versioning ensures that multiple versions of an object are preserved whenever an object is overwritten or deleted, providing protection against accidental data loss and enabling recovery to prior states. Yet versioning operates entirely within the data plane and has no bearing on the IAM or bucket-policy evaluation that determines whether anonymous principals can access the bucket. Enabling it does not revoke any existing public permissions, so the bucket remains exposed to the public while simply retaining historical copies of objects.

• ✓

  Enable S3 Block Public Access at the bucket level.

  Why this is correct

  Amazon S3 Block Public Access provides a bucket-level setting that, when enabled, overrides all other public-access grants by ignoring bucket policies and object ACLs that allow public access, including those that grant access to `*`. This control is evaluated at the edge before any policy or ACL decision and is not overridable by explicit allow statements, making it a highly effective preventative measure. Because it is a native access control, enabling it immediately blocks both existing and future public exposure without requiring you to rewrite the bucket policy.

• ✗

  Enable S3 Server Access Logging.

  Why it's wrong here

  S3 Server Access Logging records object-level requests made to the bucket, capturing details like requester, request time, action, and response status, which is valuable for auditing and forensic analysis. However, logging is a passive observational feature; it does not enforce any authorization decisions or modify the bucket's access control configuration. Consequently, it cannot prevent public access from granting anonymous users the ability to read or write objects.

• ✓

  Configure a bucket policy that explicitly denies anonymous access.

  Why this is correct

  By adding a bucket policy statement with an `Effect` of `Deny` and a `Principal` of `*` (or a condition statement using `aws:PrincipalType` equal to `Anonymous`), you can explicitly refuse all requests from unauthenticated users. In AWS authorization, an explicit deny always overrides any allow, regardless of whether the bucket policy or an ACL provides the public grant, so this works as a targeted safeguard. However, this approach only covers the bucket policy layer; it does not automatically block public access granted through object ACLs or other mechanisms unless those are also addressed.

• ✗

  Configure a lifecycle policy to delete objects.

  Why it's wrong here

  Lifecycle policies automate the transition or expiration of objects based on age, for example to archive or delete old versions, which helps manage storage costs and data retention. They are scheduled administrative actions executed on the object itself and do not affect the bucket's permissions or the evaluation of whether an anonymous requester is authorized. Thus, a lifecycle rule cannot stop the public from accessing currently exposed objects; it only eventually removes data according to time-based rules.

Go deeper

Related to this question