SOA-C02 Networking and Content Delivery Practice Question

Exhibit

Refer to the exhibit.
```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::my-bucket/*",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": "192.0.2.0/24"
                }
            }
        }
    ]
}
```

Refer to the exhibit. This bucket policy is attached to an S3 bucket that is used as an origin for a CloudFront distribution. Users are reporting Access Denied errors when accessing objects via the CloudFront URL. What is the MOST likely cause?

⚠ Common exam trap

SOA-C02 often tests whether candidates understand that CloudFront requests to S3 originate from CloudFront's IPs, not the viewer's — so IP-based bucket policy conditions break CloudFront origins.

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 condition restricts access to a specific IP range, but CloudFront requests come from its own IP addresses.

The bucket policy condition restricts access to a specific IP range (likely the corporate CIDR), but CloudFront fetches objects from its own globally distributed edge IP addresses, not the end user's IP. CloudFront forwards the viewer's IP in the X-Forwarded-For header, but the actual TCP connection to S3 originates from CloudFront's IPs, so the IpAddress condition blocks all CloudFront requests, causing Access 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.

✗
The condition is missing the aws:SourceVpce condition for VPC endpoints.
Why it's wrong here
The aws:SourceVpce condition is only used to restrict requests from a specific VPC endpoint to S3. CloudFront does not access S3 through a VPC endpoint; it ingests objects over the public internet using its origin-facing IP addresses, and ultimately the OAI. Therefore, this condition is not missing here because adding it would not solve the problem; CloudFront requests would still be blocked by the IP range condition. The missing element is instead proper auth via OAI/OAC or a condition based on the CloudFront distribution.
✗
The bucket policy does not grant access to the CloudFront service principal.
Why it's wrong here
CloudFront is commonly configured to access S3 via an Origin Access Identity (OAI), which is an IAM principal that S3 recognizes natively in bucket policies. The bucket policy can grant access to that OAI by principal ARN or canonical user ID, so a separate CloudFront service principal is unnecessary. Since CloudFront does not use a service principal in this scenario, the statement is not the issue; the overly restrictive aws:SourceIp condition is what denies CloudFront's origin requests.
✗
The resource ARN is missing the bucket ARN for the bucket itself.
Why it's wrong here
For s3:GetObject actions, the resource ARN should specify the bucket objects using a wildcard, such as arn:aws:s3:::bucket/*. The bucket ARN without the slash applies to bucket-level actions like s3:ListBucket, which are not needed for CloudFront to fetch objects. Therefore, the resource is correctly scoped to all objects, and the denial happens because the IP condition is evaluated before any resource match; CloudFront's source IPs do not match the allowed range.
✓
The condition restricts access to a specific IP range, but CloudFront requests come from its own IP addresses.
Why this is correct
The bucket policy includes a condition that allows requests only from a specific IP address range. When CloudFront fetches the object from the S3 origin, the request originates from CloudFront's edge server IP addresses, not from the viewer's IP. These CloudFront addresses are not in the allowed range, so S3 denies the GET request. The correct fix is to either remove the IP restriction or replace it with an OAI/OAC and a condition that specifically identifies the CloudFront distribution.

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

SOA-C02 Networking and Content Delivery Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question