SOA-C02 Networking and Content Delivery Practice Question
A company is using Amazon CloudFront with an S3 bucket as the origin. The S3 bucket contains sensitive data that should only be accessible via CloudFront. The SysOps administrator has configured an Origin Access Identity (OAI) and updated the bucket policy to allow access only to the OAI. However, users are still able to access the S3 bucket directly via the S3 URL. What is the most likely reason?
⚠ Common exam trap
SOA-C02 often tests the misconception that configuring OAI alone secures the bucket, when in fact an existing public bucket policy statement can still allow direct access, and candidates must identify that as the root cause.
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 bucket policy allows public read access in addition to the OAI access.
The most likely reason users can still access the S3 bucket directly is that the bucket policy contains a statement granting public read access (e.g., 'Principal': '*') in addition to the OAI allow statement. Even with OAI configured, an explicit public allow overrides the restriction. The bucket policy must be reviewed to remove any public access grants.
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 bucket policy does not include a condition to require the OAI.
Why it's wrong here
The OAI mechanism restricts access by setting the bucket policy's Principal to the OAI's Amazon Resource Name (ARN), which acts as an identity that CloudFront impersonates when fetching origin objects. A separate condition key is not needed because the Principal element itself already restricts access to only that identity, so omitting a condition causes no security gap. Even if a condition were added, it would be redundant; the failure to restrict direct S3 access stems from granting permissions permissively, not from a missing condition.
- ✓
The bucket policy allows public read access in addition to the OAI access.
Why this is correct
If the bucket policy includes an allow statement for s3:GetObject with Principal: "*", every internet user who knows the object's direct S3 URL can read it without using CloudFront. This is a common misconfiguration when administrators add the OAI allow rule but forget to remove the public read rule, leaving two paths to the content. The correct policy must only permit the OAI principal and, if needed, explicitly deny all other principals to prevent bypass.
- ✗
The OAI is not properly associated with the CloudFront distribution.
Why it's wrong here
A misassociated OAI would cause CloudFront to receive 403 Forbidden responses because the bucket would not recognize the OAI as an authorized caller, breaking the distribution entirely. The scenario reports that objects are accessible directly from S3, which indicates that the OAI association works (CloudFront is serving content) but that the bucket erroneously grants broader permissions than intended. Since the administrator stated the OAI was configured correctly and CloudFront delivers content, the origin association is not the source of the security exposure.
- ✗
The S3 bucket is configured as a static website.
Why it's wrong here
Static website hosting on S3 exposes a separate website endpoint (e.g., bucket.s3-website-region.amazonaws.com) that does not support OAI-style authentication; however, enabling it does not automatically make objects public—the bucket policy still governs access. If the policy allows only the CloudFront OAI, the website endpoint will deny anonymous requests, so static hosting alone cannot be used to bypass CloudFront. The underlying problem in this scenario is that the bucket policy also grants public read access, which affects both endpoints, not the mere fact that website hosting is enabled.
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.