DVA-C02 Security 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 server access logging.

  Why it's wrong here

  Enabling S3 server access logging records all requests made to the bucket, capturing details like source IP, requester, and operation type in log files that can be stored in another bucket. While this is valuable for auditing and post-incident analysis, logging has no effect on the bucket's authorization logic; it merely writes log objects. It does not alter the bucket policy, ACLs, or Block Public Access settings, so it cannot prevent anonymous users from reading objects. Therefore, it does not ensure the bucket is not public.

• ✗

  Enable versioning on the bucket.

  Why it's wrong here

  Enabling versioning on the bucket causes S3 to retain multiple versions of each object, allowing you to preserve, retrieve, and restore previous states of an object. This is a data-protection and disaster-recovery feature that guards against accidental deletion or overwriting, but it does not change how access is evaluated. Whether a bucket is public depends entirely on its policy, ACLs, and Block Public Access settings, none of which are affected by versioning. A public bucket still serves all versions to any authenticated or anonymous requester who is allowed. Thus, versioning is not a valid method to restrict public access.

• ✗

  Enable default encryption on the bucket.

  Why it's wrong here

  Enabling default encryption on the bucket ensures that every new object is automatically encrypted at rest using S3-managed keys (SSE-S3) or AWS KMS keys, protecting the data from unauthorized access at the storage layer. However, encryption is not an access control mechanism; it does not evaluate permissions or block requests. If the bucket is public, an anonymous user can still decrypt and retrieve objects because the encryption keys are managed by AWS and granted to authorized users based on IAM/policy evaluation. Encryption protects against data exposure if storage media is lost or accessed outside S3, but it does nothing to make the bucket private.

• ✓

  Review the bucket policy to ensure it does not allow public access.

  Why this is correct

  Reviewing the bucket policy is a direct and necessary step because a bucket policy with a Principal of '*' and actions such as s3:GetObject or s3:ListBucket grants public read access to everyone. Even if the bucket ACLs and other settings appear restrictive, such a policy statement can make all objects publicly accessible. By auditing and removing any statement that grants access to 'Principal: *' or does not restrict access to specific AWS accounts, the developer can confirm that the bucket no longer publicly exposes objects. This complements Block Public Access, which provides a defensive override, but the policy itself is the actual source of public access.

• ✓

  Enable S3 Block Public Access settings on the bucket.

  Why this is correct

  Enabling S3 Block Public Access settings on the bucket is a robust preventive measure that applies four independent controls: blocking new public ACLs, ignoring existing public ACLs, blocking new public bucket policies, and restricting access to only AWS services and authorized principals. These settings act as an explicit 'deny' that overrides any bucket policy or ACL statement that would allow public access, regardless of whether the statement is intentional or accidental. When all four settings are enabled, no public access can be granted via any mechanism, making the bucket definitively private. This is especially valuable in an environment with many users where a misconfigured policy might otherwise go unnoticed.

Go deeper

Related to this question