DOP-C02 Security and Compliance Practice Question

Exhibit

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "10.0.0.0/24"
        }
      }
    },
    {
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::example-bucket/confidential/*",
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}

Refer to the exhibit. An IAM policy is attached to a user. The user requests an object from the 'example-bucket' bucket, specifically from the 'confidential' folder, over HTTP (not HTTPS). The source IP is within the 10.0.0.0/24 range. What will be the result of this request?

⚠ Common exam trap

DOP-C02 often tests the misconception that an Allow with matching IP or resource conditions can override an explicit Deny, when in fact explicit Deny always wins — candidates must remember the evaluation order.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Denied, because the request uses HTTP and the Deny statement blocks it.

The IAM policy includes a Deny statement that blocks s3:GetObject when the request is not over HTTPS (aws:SecureTransport is false). Since the request uses HTTP, the condition evaluates to true and the explicit Deny overrides any Allow. Therefore the request is denied regardless of the source IP being in the allowed range.

Answer analysis

Option-by-option breakdown

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

✗
Denied, because the user does not have s3:GetObject permission on the confidential folder.
Why it's wrong here
The request is not being denied because of a missing s3:GetObject permission on the confidential folder. If the policy includes an Allow statement granting that permission, the permission exists; however, the explicit Deny statement with the condition aws:SecureTransport = false takes precedence. IAM evaluation logic dictates that any explicit Deny overrides all Allow statements, so an HTTP request is blocked even when the user possesses the necessary S3 permission.
✗
Allowed, because the Deny statement only applies to HTTPS.
Why it's wrong here
This option incorrectly reverses the actual condition in the Deny statement. The policy's Deny includes a Bool condition checking that aws:SecureTransport is false, meaning the Deny applies only to HTTP requests, not HTTPS. An HTTPS request sets SecureTransport to true, so it would not match the Deny's condition and would not be blocked by this statement. Therefore, saying the Deny only applies to HTTPS is factually wrong and confuses the security control's intent.
✗
Allowed, because the source IP is within the allowed range.
Why it's wrong here
Even if the user's source IP falls within the range allowed by the Allow statement, that does not bypass the explicit Deny. In AWS IAM, an explicit Deny always overrides an Allow, regardless of how specific the Allow's conditions are. The Deny here is based on the transport protocol (HTTP vs. HTTPS), not on the source IP, so a matching IP address cannot rescue a request made over HTTP; the request is denied before the IP condition is evaluated.
✓
Denied, because the request uses HTTP and the Deny statement blocks it.
Why this is correct
This is correct because an HTTP request sets the aws:SecureTransport context key to false, and the Deny statement is scoped to exactly that condition. The policy likely contains an Allow for the S3 action on the folder, but the explicit Deny for non-secure transport takes precedence under AWS's evaluation logic. As a result, the user's GET request over HTTP is denied, while the same request sent over HTTPS would be allowed if the other permissions match.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

DOP-C02 Security and Compliance Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question