SOA-C02 Networking and Content Delivery Practice Question
A company uses Amazon CloudFront to serve content from an S3 bucket. The bucket is configured as an origin with Origin Access Control (OAC). Users report that they can access the content via CloudFront but also directly via the S3 bucket URL. How can the company restrict direct access to the S3 bucket?
⚠ Common exam trap
SOA-C02 often tests whether candidates know that enabling OAC alone is insufficient — the S3 bucket policy must also be updated to deny direct access, and candidates frequently pick 'switch to OAI' thinking it is a security fix rather than a legacy alternative.
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
✓
Update the S3 bucket policy to deny access to any principal other than the CloudFront service.
With Origin Access Control (OAC), CloudFront signs requests to S3, and the S3 bucket policy must be updated to allow only the CloudFront distribution (via the cloudfront.amazonaws.com service principal with a condition on the distribution ARN) and deny all other principals. This blocks direct access via the S3 URL while preserving CloudFront access.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Disable OAC and use Origin Access Identity (OAI) instead.
Why it's wrong here
OAI is the older predecessor to OAC and also depends on a bucket policy that grants the CloudFront distribution access. Merely switching from OAC to OAI does not add any additional restriction—if the existing bucket policy does not explicitly deny non-CloudFront principals, direct S3 URLs remain accessible. Additionally, OAI authenticates via a canonical user ID, which is less precise than OAC's service-principal-based authentication and does nothing to prevent anonymous or IAM user access to the bucket.
- ✗
Use pre-signed URLs for all S3 requests.
Why it's wrong here
Pre-signed URLs only add temporary query-string authentication for specific objects; they do not modify the bucket policy or IAM permissions that govern direct S3 access. If the bucket policy still allows public or authenticated access, users can bypass CloudFront entirely and access objects via the S3 endpoint. Moreover, generating pre-signed URLs for every request is operationally heavy and undermines CloudFront's edge-caching benefits, because the signed URL is tied to the S3 origin rather than the CloudFront distribution.
- ✗
Remove the bucket policy and rely on ACLs.
Why it's wrong here
Removing the bucket policy would revoke the explicit grant that permits CloudFront's service principal to read the origin bucket, so CloudFront fetches would fail with 403 Access Denied. Furthermore, S3 ACLs are typically disabled under the default Object Ownership setting (BucketOwnerEnforced) for newer buckets, and even if enabled, ACLs are not a viable way to block all non-CloudFront access because they only grant cross-account or canonical user permissions, not a deny rule. Without a bucket policy, there is no way to express a conditional deny that targets every principal except CloudFront, making this option both ineffective and disruptive.
- ✓
Update the S3 bucket policy to deny access to any principal other than the CloudFront service.
Why this is correct
This is correct because the S3 bucket policy can include an explicit deny statement that applies to any principal other than the CloudFront service, effectively closing the direct access path. By using a condition such as `aws:SourceArn` or `aws:SourceAccount`, the policy can allow only CloudFront while denying all other IAM users, roles, and anonymous requests. This approach is the recommended companion to OAC because it ensures that the bucket is not publicly accessible, and any attempt to access the object via the S3 website or REST endpoint is rejected before returning content.
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
One of 1,169 original SOA-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.