SCS-C02 Infrastructure Security Practice Question

A security engineer is reviewing the following IAM policy attached to an S3 bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/*",
      "Condition": {
        "IpAddress": {

"aws:SourceIp": "10.0.0.0/8"

}
      }
    }
  ]
}

The bucket contains sensitive data and should only be accessible from the corporate network (CIDR 10.0.0.0/8). However, the engineer is concerned that this policy might not be effective. What is the primary security concern with this policy?

⚠ Common exam trap

The trap here is that candidates focus on the IP restriction condition and assume it makes the policy secure, overlooking the fact that `"Principal": "*"` still makes the bucket publicly accessible to any user within that IP range, which is a direct violation of AWS shared responsibility and least privilege principles.

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

✓

The policy grants public access to the bucket because the Principal is "*", allowing anyone from the specified IP range to access objects.

The bucket policy uses `"Principal": "*"` combined with `"Effect": "Allow"`, which explicitly grants public access to anyone who meets the condition. While the condition restricts access to the `10.0.0.0/8` IP range, the policy itself is still a public bucket policy — it allows any authenticated or unauthenticated user from that IP range to read objects. This violates the principle of least privilege and exposes sensitive data to any user on the corporate network, not just authorized IAM roles or users.

Answer analysis

Option-by-option breakdown

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

✗
The bucket policy does not include a Deny statement for requests outside the IP range, so the default allow might still permit access from other IPs.
Why it's wrong here
This misreads IAM evaluation logic: the default is an implicit deny, not an allow. Since the only Allow statement is conditioned on aws:SourceIp, any request that falls outside the specified IP range does not match the condition and cannot be authorized by this policy, regardless of whether an explicit Deny is present. Adding a Deny for other IPs is redundant and does not change the outcome; the policy is already restrictive by IP range.
✓
The policy grants public access to the bucket because the Principal is "*", allowing anyone from the specified IP range to access objects.
Why this is correct
The policy sets Principal to '*' in a bucket policy, which means every principal—including unauthenticated anonymous users—is included in the scope of the statement. The condition on aws:SourceIp narrows the network source to a specific IP CIDR, but it does not require any AWS credentials, identity, or account relationship. As a result, any person or service whose traffic originates from that IP range can read objects in the bucket, making the bucket effectively public to that entire network.
✗
The condition key aws:SourceIp only evaluates the IP address of the client, but if the request comes through a proxy, the IP might not match.
Why it's wrong here
While it is true that aws:SourceIp is evaluated using the source IP of the request and proxy servers can alter that IP, this does not undermine the principal finding that the policy grants overly broad access. The condition still permits every request from the specified range, regardless of whether the requester is authenticated or anonymous. Proxy-related IP mismatches are a separate operational concern, not the core security flaw; the central issue is the combination of Principal '*' with a relatively large, shared corporate IP range.
✗
The policy uses s3:GetObject but does not include s3:ListBucket, so users cannot see the object list, but they can guess object keys.
Why it's wrong here
The lack of s3:ListBucket does prevent a caller from enumerating object keys, but it does not prevent access to objects whose keys are known or guessed. Because s3:GetObject is already granted, anyone in the allowed IP range can directly retrieve any object if they know its key, which is still a serious data exposure. This is a secondary observation; the primary concern remains that the policy uses Principal '*', creating effectively public access to the bucket's objects for that IP range.

Visual reference

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

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question