SAA-C03 Design Secure Architectures Practice Question
You serve private reports stored in an S3 bucket through CloudFront. After a recent change, users report that they can access the S3 object URLs directly (bypassing CloudFront), which violates your design. You want to ensure S3 objects are readable only through CloudFront using Origin Access Control (OAC), even if someone guesses the S3 URL. Which update best enforces this at the S3 bucket level?
⚠ Common exam trap
Many candidates think CloudFront signed URLs alone are sufficient for security, but without a restrictive bucket policy, the S3 bucket remains publicly accessible, allowing direct URL access to bypass CloudFront.
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
✓
Add a bucket policy Allow for s3:GetObject only when the principal is cloudfront.amazonaws.com and aws:SourceArn matches your CloudFront distribution ARN, while blocking public access.
It uses an S3 bucket policy that grants s3:GetObject access only when the principal is cloudfront.amazonaws.com and the aws:SourceArn matches the CloudFront distribution ARN. This ensures that only CloudFront, using Origin Access Control (OAC), can retrieve objects, blocking direct S3 URL access even if the URL is guessed. Blocking public access at the bucket level further prevents any anonymous or public reads.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Add a bucket policy Allow for s3:GetObject only when the principal is cloudfront.amazonaws.com and aws:SourceArn matches your CloudFront distribution ARN, while blocking public access.
Why this is correct
CloudFront Origin Access Control (OAC) uses a service principal (cloudfront.amazonaws.com) to sign requests to S3. By adding a bucket policy that grants s3:GetObject only when the principal is cloudfront.amazonaws.com and aws:SourceArn matches your CloudFront distribution ARN, you ensure only that distribution can read objects. Blocking all public access with the S3 Block Public Access setting removes any other path, so a user who discovers the raw S3 URL cannot retrieve the object without going through CloudFront.
- ✗
Enable an S3 bucket lifecycle policy to transition objects to Glacier, so public S3 URLs become inaccessible.
Why it's wrong here
An S3 lifecycle policy changes storage class over time but never modifies the access-control policy. Objects still in the Standard or Intelligent-Tiering class remain directly readable via public URLs, and even after transition to Glacier, a direct GET returns an InvalidObjectState error until a restore is performed, which is an availability change, not a security boundary. The bucket policy still allows public access, so any user with s3:RestoreObject permission could restore and retrieve the object; lifecycle transitions are for cost management, not access control.
- ✗
Rely only on CloudFront signed URLs validation; do not change the S3 bucket policy.
Why it's wrong here
CloudFront signed URLs authenticate users at the CloudFront edge, but they do nothing to the S3 bucket's own permissions. If the bucket has a public-read bucket policy or ACL, the raw s3.amazonaws.com URL still works without any signature because the S3 service sees a different request than CloudFront. To make signed URLs truly effective, you must pair them with an origin access control policy that denies direct S3 access to everyone except the CloudFront distribution.
- ✗
Add a WAF rule on CloudFront to block requests that contain "amazonaws.com" in the URL path.
Why it's wrong here
AWS WAF attaches to CloudFront distributions or Application Load Balancers, so it can only inspect traffic that reaches those endpoints. A user can bypass CloudFront entirely by going to the S3 bucket's regional endpoint, and WAF will never see that request. Furthermore, the condition looks for 'amazonaws.com' in the URL path, but the path is the object key (e.g., /reports/q1.pdf), and the hostname for a CloudFront URL is like d111111abcdef8.cloudfront.net, so this rule would not match the intended request pattern.
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
Courseiva writes every SAA-C03 question from scratch — 935 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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 SAA-C03 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 SAA-C03 exam.