SCS-C02 Data Protection 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.

• ✗

  {"Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "*", "Condition": {"Bool": {"aws:SecureTransport": "true"}}}

  Why it's wrong here

  This policy denies all S3 actions when the aws:SecureTransport condition key evaluates to true, which is the exact opposite of the intended protection. Since aws:SecureTransport is true for HTTPS requests, this deny statement blocks legitimate encrypted traffic and effectively leaves only insecure HTTP requests unblocked. It thus fails to protect data in transit and actively prevents secure access to the bucket.

• ✓

  {"Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "*", "Condition": {"Bool": {"aws:SecureTransport": "false"}}}

  Why this is correct

  This policy correctly denies S3 actions when aws:SecureTransport is false, meaning it blocks all HTTP requests that do not use TLS. The aws:SecureTransport key is true only for requests made over HTTPS, so this conditional deny rejects any insecure request while allowing encrypted traffic. This is the AWS-recommended bucket policy pattern for enforcing encryption in transit and satisfies the requirement.

• ✗

  {"Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "*", "Condition": {"Null": {"s3:x-amz-server-side-encryption": "true"}}}

  Why it's wrong here

  This policy attempts to enforce encryption at rest rather than in transit by denying requests when the s3:x-amz-server-side-encryption header is absent (Null true). The condition key checks for the presence of a server-side encryption header, not for whether the request is sent over HTTPS, so it does not address data-in-transit protection. Even an HTTP request could include that header, so insecure transport would not be blocked.

• ✗

  {"Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "*"}

  Why it's wrong here

  This bucket policy denies all S3 actions without any condition key, which makes it far too restrictive for the stated requirement. It would block both HTTPS and HTTP requests, rendering the bucket completely inaccessible to all principals. Such a policy prevents all legitimate use and does not selectively target insecure transmission, so it fails the need to enforce TLS while preserving secure access.

Go deeper

Related to this question