SCS-C02 Infrastructure Security Practice Question

Exhibit

Refer to the exhibit.

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

Refer to the exhibit. The bucket policy allows access from a specific IP range and denies access over HTTP. A user from IP 198.51.100.5 makes a GET request over HTTPS. What will happen?

⚠ Common exam trap

A common mix-up: candidates assume that because the Deny condition is not triggered (due to HTTPS), the request must be allowed, overlooking the fact that the request still fails the IP-based Allow condition, leading to an implicit Deny.

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 no explicit allow matches the request.

In AWS S3 bucket policies, an explicit Deny always overrides any Allow, but the request must first match a Deny condition. Here, the Deny condition applies to HTTP requests, but the request is HTTPS, so the Deny does not apply. However, the bucket policy only allows access from a specific IP range, and the user's IP (198.51.100.5) is not within that allowed range. Since no explicit Allow matches the request, the default implicit Deny applies, resulting in access being denied.

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 of the explicit Deny statement.
Why it's wrong here
The explicit Deny statement in this bucket policy is conditional: it denies requests only when aws:SecureTransport is false. Since the request is made over HTTPS, aws:SecureTransport is true, so the Deny condition evaluates to false and that statement does not apply. Therefore, the denial is not caused by this explicit Deny; the request is instead blocked because no Allow statement matches.
✗
Allowed because the request is over HTTPS.
Why it's wrong here
HTTPS only ensures that the request does not trigger the conditional Deny that blocks non-secure transport; it does not, by itself, create an authorization to access the object. To be allowed, the request must also satisfy the conditions of an Allow statement. Here, the Allow statement is restricted by aws:SourceIp to a specific IP range, and since the request's source IP is outside that range, the Allow condition is not met. Thus, using HTTPS is not sufficient for access.
✗
Allowed because the Deny condition is not satisfied.
Why it's wrong here
When the Deny condition is not satisfied, AWS policy evaluation simply proceeds to check for applicable Allow statements; it does not treat the absence of a Deny as an Allow. The bucket policy's only Allow statement requires the source IP to be within the designated range, which this request does not satisfy. Without any other Allow statement applying, the request fails the explicit allow check and is denied by the default implicit deny. So the request is not allowed merely because the Deny condition is not met.
✓
Denied because no explicit allow matches the request.
Why this is correct
The explicit Deny statement is skipped because the request uses HTTPS and thereby satisfies the secure-transport condition, but that only removes a blocking rule. The sole Allow statement, however, is conditioned on the request's source IP being in the specified allowed range, and this request's source IP does not fall within that range. Since the request does not match the condition of any Allow statement, no explicit allow applies, and AWS IAM falls back to the default implicit deny. The request is denied for exactly that reason: no explicit allow matches it.

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

SCS-C02 Infrastructure Security Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question