SOA-C02 Networking and Content Delivery Practice Question
A company uses Amazon CloudFront to serve static content from an S3 bucket. The S3 bucket is configured as an origin with RestrictBucketAccess set to Yes, and the origin access identity (OAI) is configured. Users can access the content via CloudFront, but direct S3 URLs return Access Denied. However, some users report that they can still access the content directly via S3 URLs. What is the most likely reason?
⚠ Common exam trap
SOA-C02 often tests the misconception that configuring OAI and RestrictBucketAccess automatically blocks all direct S3 access, ignoring the possibility of a permissive bucket policy that overrides these settings.
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 S3 bucket policy allows public read access in addition to the OAI.
The most likely reason users can still access content directly via S3 URLs is that the S3 bucket policy allows public read access in addition to the OAI. Even though CloudFront is configured with OAI and RestrictBucketAccess, if the bucket policy grants public read permissions (e.g., via a statement with Principal: "*"), then direct S3 access remains possible. The OAI only restricts access when the bucket policy explicitly denies public access and allows only the OAI.
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 OAI is not properly associated with the CloudFront distribution.
Why it's wrong here
The scenario explicitly states that the OAI is configured, so an improper association cannot be the cause. If the OAI were missing or misassociated, CloudFront's origin requests to S3 would fail with 403 Access Denied, but the user's issue is that direct S3 access also works, not that CloudFront fails. Therefore, this option contradicts the given facts.
- ✓
The S3 bucket policy allows public read access in addition to the OAI.
Why this is correct
The OAI only authenticates CloudFront to S3; it does not automatically override a bucket policy that grants `s3:GetObject` to the public. If the bucket policy includes an `Allow` for `*` (or `AllPrincipals`), any user can access objects directly via the S3 bucket URL or website endpoint, entirely bypassing CloudFront. This explains the reported behavior: CloudFront works via the OAI, but the bucket remains publicly readable, so the security requirement is violated.
- ✗
The CloudFront distribution is using a custom origin instead of S3.
Why it's wrong here
The question explicitly identifies the origin as an S3 bucket configured with an OAI, ruling out a custom origin. A custom origin would use an alternative domain name (like an EC2 load balancer or an S3 website endpoint) and would not support OAI at all, since OAI is an S3-specific feature. If a custom origin were in use, the problem would manifest as inability to configure OAI, not as public access through the S3 URL.
- ✗
CloudFront is using pre-signed URLs that are being shared.
Why it's wrong here
Pre-signed URLs are query-string credentials used to grant temporary access to specific S3 objects, and they have nothing to do with CloudFront's OAI origin authentication. With OAI, CloudFront signs its own requests to S3 using its identity, and the distribution's URLs contain no pre-signed parameters. Sharing pre-signed URLs could allow external access to individual objects, but it would not make the entire S3 bucket publicly reachable via the plain bucket URL, so this does not match the symptom.
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
Related to this question
About these practice questions
This SOA-C02 question is part of Courseiva's 1,169-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
This SOA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SOA-C02 exam.