SOA-C02 Networking and Content Delivery Practice Question
A company has a CloudFront distribution with an S3 bucket as the origin. The S3 bucket contains sensitive data that should only be accessible through CloudFront. Which configuration is required to ensure that direct access to the S3 bucket is blocked?
⚠ Common exam trap
SOA-C02 often tests the misconception that CloudFront IP ranges or IAM roles are sufficient to secure S3 origins, when in fact an OAI (or OAC) with a bucket policy is required to block direct access.
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
✓
Create an Origin Access Identity (OAI) and add a bucket policy that grants access only to the OAI
The correct configuration is to create an Origin Access Identity (OAI) and grant it access via the S3 bucket policy. An OAI is a special CloudFront user that can be associated with a distribution. By updating the S3 bucket policy to allow only the OAI to perform s3:GetObject, you ensure that objects are only accessible through CloudFront. This effectively blocks direct public access to the bucket while allowing CloudFront to serve the content.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Attach an IAM role to CloudFront that allows S3 access
Why it's wrong here
CloudFront does not support using an IAM role as the origin identity for S3. IAM roles are designed for principals like EC2 instances or Lambda functions, not for a managed CDN service making origin fetch calls. The only native way to authenticate CloudFront to an S3 origin is via an Origin Access Identity (OAI) or the newer Origin Access Control (OAC). Attaching an IAM role to CloudFront is therefore not a valid configuration and would not resolve private S3 access.
- ✗
Set the S3 bucket policy to deny all access except from CloudFront's IP ranges
Why it's wrong here
CloudFront publishes its IP ranges, but these ranges are shared by all AWS customers and are subject to change without notice. A bucket policy that allows access only from CloudFront IP ranges is both overly broad and fragile, because any client can use those IPs, and an outdated range list would break distribution. More importantly, it does not authenticate that the request came from your CloudFront distribution; it only checks the source IP. The correct approach is to use an OAI in the bucket policy to grant access to a specific, verifiable CloudFront identity.
- ✓
Create an Origin Access Identity (OAI) and add a bucket policy that grants access only to the OAI
Why this is correct
An Origin Access Identity (OAI) is a special virtual identity that CloudFront uses to fetch objects from your S3 bucket. After creating an OAI and associating it with the distribution, you update the bucket policy to allow s3:GetObject for that OAI principal and deny all other direct S3 access. This ensures viewers can only access content through CloudFront, while the S3 bucket remains private. This is the AWS-recommended mechanism for securing S3 origins and avoids the pitfalls of IP-based or public-bucket policies.
- ✗
Use signed URLs for all requests
Why it's wrong here
Signed URLs control who can access content through CloudFront by requiring time-limited, cryptographically signed requests. They do not, however, alter the S3 bucket's own permissions; if the bucket is public or has a permissive bucket policy, users can bypass CloudFront entirely and hit the S3 endpoint directly. To prevent direct access, you must restrict the bucket policy to the CloudFront OAI, not rely solely on signed URLs. Signed URLs are a client-access control feature, not an origin-access security control.
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 →
Same concept, more angles
2 more ways this is tested on SOA-C02
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Refer to the exhibit. An S3 bucket policy is configured for a CloudFront distribution using an OAI. The policy allows the OAI to get objects. Additionally, it allows anyone from the IP range 203.0.113.0/24 to get objects directly. Users from other IPs report they can still access objects directly via S3 URLs. What is the most likely cause?
hard- A.The policy allows public access from the specified IP range, overriding the OAI restriction.
- B.The OAI is not correctly associated with the CloudFront distribution.
- C.The CloudFront distribution is using a custom origin instead of S3.
- ✓ D.The S3 bucket has a bucket ACL that grants public read access.
Why D: The most likely cause is a bucket ACL granting public read access, which operates independently of the bucket policy. Even if the bucket policy restricts access to the OAI and the 203.0.113.0/24 range, a public-read ACL on the bucket or its objects allows anyone to GET objects directly via S3 URLs, bypassing the policy's IP restriction.
Variation 2. Which TWO methods can be used to secure an S3 bucket that is used as an origin for Amazon CloudFront? (Select two.)
medium- ✓ A.Write a bucket policy that allows only the CloudFront distribution’s OAI.
- B.Use bucket ACLs to grant public read access.
- C.Enable S3 server-side encryption.
- ✓ D.Configure an origin access identity (OAI) and restrict bucket access.
- E.Generate pre-signed URLs for all objects.
Why A: Option A is correct because a bucket policy can explicitly allow s3:GetObject only to the CloudFront origin access identity (OAI) principal, effectively blocking direct public access while permitting CloudFront to fetch objects. Option D is correct because configuring an OAI and then restricting bucket access (via the bucket policy or ACLs) is the standard mechanism that ties the S3 origin to the specific CloudFront distribution, preventing users from bypassing CloudFront. Option B is incorrect because granting public read access via bucket ACLs exposes the bucket directly and defeats the purpose of securing the origin. Option C is incorrect because server-side encryption protects data at rest but does not restrict who can retrieve objects from the bucket. Option E is incorrect because pre-signed URLs are for granting time-limited access to individual objects, not for securing a CloudFront origin, and they would not integrate with CloudFront's OAI model.
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.