DOP-C02 Resilient Cloud Solutions Practice Question
A company runs a static website on Amazon S3 with public read access. The website content is stored in an S3 bucket and served through an Amazon CloudFront distribution for better performance and security. Recently, the company noticed that some users are accessing the S3 bucket directly via the S3 endpoint, bypassing CloudFront. This increases costs and exposes the bucket to potential attacks. The company wants to ensure that all access to the website goes through CloudFront only. Which solution should the company implement?
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) in CloudFront and update the S3 bucket policy to allow only the OAI to read objects.
To restrict access to the S3 bucket only through CloudFront, use an origin access identity (OAI) and a bucket policy that allows only the OAI. This way, direct access via S3 URL is denied.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Set the S3 bucket policy to deny all requests that do not come from the CloudFront distribution's IP addresses.
Why it's wrong here
CloudFront's public IP ranges are not static and change regularly as edge locations scale; relying on a deny list of IPs is brittle and can break when ranges change. A request originating from within a CloudFront IP range is not proof of identity—any client with the right source IP, or even a malicious actor using CloudFront as a proxy, could pass the check. The OAI mechanism uses a signed identity rather than IP-based conditions, which is why the correct solution grants explicit permission to a unique CloudFront principal.
- ✗
Configure the S3 bucket to use AWS WAF to block requests that do not have a custom header set by CloudFront.
Why it's wrong here
AWS WAF cannot be attached directly to an S3 bucket; it operates at CloudFront, Application Load Balancer, or API Gateway, never at the S3 origin. If you configure a custom header in CloudFront via Lambda@Edge, a direct request to the S3 website endpoint bypasses CloudFront entirely, so the WAF rule is never evaluated and the bucket remains publicly readable. The only way to enforce that all access goes through CloudFront is to lock the bucket down at the origin level using an OAI (or OAC), not by layering WAF rules at the edge.
- ✓
Create an origin access identity (OAI) in CloudFront and update the S3 bucket policy to allow only the OAI to read objects.
Why this is correct
Creating an origin access identity (OAI) in CloudFront and updating the bucket policy to permit only that OAI to read objects is the correct approach. The OAI is a special CloudFront user that validates requests to the S3 origin with AWS Signature Version 4, and the bucket policy grants s3:GetObject permission exclusively to this principal. This blocks any request that does not come through the CloudFront distribution, while still allowing the static content to be publicly served to end users via CloudFront.
- ✗
Change the S3 bucket to be private and use presigned URLs for all requests.
Why it's wrong here
Presigned URLs are temporary, signed links that grant time-limited access to private S3 objects, but they require an application to generate and distribute them—something a purely static website hosted on S3 does not have. Even if such a generator were added, presigned URLs point directly to the S3 endpoint, bypassing CloudFront, so they neither route traffic through the distribution nor preserve CloudFront caching, security, or logging benefits. The correct origin-restriction mechanism is OAI/OAC, not a wholesale switch to presigned URLs.
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 DOP-C02 question is part of Courseiva's 1,298-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 by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DOP-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 DOP-C02 exam.