SOA-C02 Networking and Content Delivery Practice Question
A company has an Amazon CloudFront distribution with an S3 bucket as origin. The bucket contains sensitive data. Which configuration ensures that users access the content only through CloudFront and not directly via the S3 URL?
⚠ Common exam trap
The trap is assuming that signed URLs or Block Public Access alone secure the origin — candidates forget that without an OAI/OAC and a restrictive bucket policy, the S3 URL remains directly reachable.
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
✓
Configure an Origin Access Identity (OAI) in CloudFront and update the bucket policy
An Origin Access Identity (OAI) is a special CloudFront user that the distribution uses to fetch objects from the S3 bucket. By updating the bucket policy to grant read access only to that OAI and removing public access, direct requests to the S3 URL are denied while CloudFront can still serve the content. This is the standard AWS pattern for locking an S3 origin behind CloudFront.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable S3 server-side encryption
Why it's wrong here
Enabling S3 server-side encryption (SSE-S3, SSE-KMS, or SSE-C) encrypts objects at rest in the S3 bucket, but it does nothing to restrict which principals or origins can read the objects. A bucket that grants public read access or has no bucket policy restricting the origin will still allow direct S3 GET requests and CloudFront fetches, because encryption protects the stored bytes, not the access path. You would still need an OAI or bucket policy to enforce exclusive CloudFront delivery.
- ✓
Configure an Origin Access Identity (OAI) in CloudFront and update the bucket policy
Why this is correct
An Origin Access Identity is a special CloudFront principal that S3 recognizes; after creating it, you attach it to your distribution and rewrite the bucket policy to grant s3:GetObject only to that OAI's canonical user ID. This makes the bucket private to everyone except CloudFront, so users cannot bypass CloudFront by hitting the S3 endpoint directly. Combined with the distribution's behavior, it is the standard way to force all traffic through CloudFront for a private S3 origin.
- ✗
Use CloudFront signed URLs or signed cookies
Why it's wrong here
CloudFront signed URLs and signed cookies restrict user access to the distribution's URLs by requiring a signature from an account that owns a CloudFront private key, but they do not change the S3 bucket's permissions. If the bucket policy still permits anonymous or direct GET requests, then a user can retrieve the object straight from the S3 endpoint and never present a signed URL, completely bypassing CloudFront. Signed URLs are an application-level access control layer that should be combined with an OAI-protected bucket, not used in place of origin access restrictions.
- ✗
Enable S3 Block Public Access on the bucket
Why it's wrong here
S3 Block Public Access is a set of account- or bucket-level controls that reject public bucket policies and public object ACLs, so it can prevent anonymous internet access to the bucket. However, enabling it does not magically grant CloudFront permission to read objects; the distribution still receives 403 Access Denied unless an OAI and an explicit allow policy are configured. Moreover, if you block public policies after previously depending on a public read policy, even CloudFront will lose access unless you add the OAI-specific policy within the bounds of Block Public Access.
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.