SAA-C03 Design Secure Architectures Practice Question
Your team hosts a private web app on an S3 bucket and serves it through CloudFront using a modern Origin Access Control (OAC). After deployment, users receive HTTP 403 from CloudFront with the S3 origin error "AccessDenied".
Which S3 bucket policy change best aligns with CloudFront OAC so the distribution can fetch objects privately?
⚠ Common exam trap
Many candidates confuse Origin Access Control (OAC) with the older Origin Access Identity (OAI) and incorrectly select an OAI-based policy (Option D), or they assume that bucket owner permissions automatically extend to CloudFront (Option B), failing to recognize that OAC requires an explicit service principal-based policy with a source ARN condition.
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
✓
Allow the CloudFront service principal cloudfront.amazonaws.com to perform s3:GetObject, and scope access with a condition on AWS:SourceArn matching your CloudFront distribution ARN.
CloudFront Origin Access Control (OAC) requires an explicit S3 bucket policy that allows the CloudFront service principal (`cloudfront.amazonaws.com`) to perform `s3:GetObject`, and the recommended best practice is to scope the permission using a condition on `AWS:SourceArn` matching the specific CloudFront distribution ARN. This ensures that only requests originating from that distribution can access the bucket objects, preventing unauthorized access from other sources.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Allow the CloudFront service principal cloudfront.amazonaws.com to perform s3:GetObject, and scope access with a condition on AWS:SourceArn matching your CloudFront distribution ARN.
Why this is correct
With CloudFront OAC, the request to S3 is authorized using the CloudFront service principal. Granting s3:GetObject to cloudfront.amazonaws.com and constraining it with AWS:SourceArn to the specific distribution is the standard secure pattern for private S3 origins.
- ✗
Allow only the S3 bucket owner account to perform s3:GetObject without any condition, so CloudFront can inherit access automatically.
Why it's wrong here
CloudFront does not “inherit” the bucket owner’s permissions. S3 must authorize the actual caller (the CloudFront service principal for OAC). A policy that only references the bucket owner principal (without allowing cloudfront.amazonaws.com) will not authorize CloudFront OAC requests.
When this WOULD be correct
This option would be correct if the question asked about a scenario where the S3 bucket is publicly accessible and no CloudFront origin access control is needed, such as when serving static assets directly from S3 without CloudFront.
- ✗
Add a policy statement that denies s3:GetObject when the request does not include the header CloudFront-Viewer-Country.
Why it's wrong here
The presence of that header is not what authorizes CloudFront OAC to access S3 objects. AccessDenied indicates the bucket policy is missing (or does not match) the required allow for the CloudFront principal and expected conditions (such as AWS:SourceArn).
When this WOULD be correct
This option would be correct in a scenario where you need to restrict access to your S3 content based on viewer's country, such as when serving content only to specific countries for licensing or compliance reasons, and you want to deny access from other countries.
- ✗
Grant s3:GetObject permission to an Origin Access Identity (OAI) canonical user ID even though you are using Origin Access Control (OAC).
Why it's wrong here
OAI and OAC use different authorization mechanisms. When using OAC, S3 expects authorization from the CloudFront service principal (with appropriate conditions). An OAI canonical user ID condition will not match OAC requests and will not fix the AccessDenied error.
When this WOULD be correct
If the question stated that the distribution uses an Origin Access Identity (OAI) instead of OAC, then granting s3:GetObject permission to the OAI's canonical user ID would be correct. For example: 'You configured CloudFront with an OAI to restrict access to an S3 bucket. Which bucket policy allows CloudFront to fetch objects?'
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The SAA-C03 exam frequently reuses these exact scenarios with slightly different constraints.
✓Allow the CloudFront service principal cloudfront.amazonaws.com to perform s3:GetObject, and scope access with a condition on AWS:SourceArn matching your CloudFront distribution ARN.Correct answer▾
Why this is correct
With CloudFront OAC, the request to S3 is authorized using the CloudFront service principal. Granting s3:GetObject to cloudfront.amazonaws.com and constraining it with AWS:SourceArn to the specific distribution is the standard secure pattern for private S3 origins.
✗Allow only the S3 bucket owner account to perform s3:GetObject without any condition, so CloudFront can inherit access automatically.Wrong answer — click to see why▾
Why this is wrong here
CloudFront OAC does not automatically inherit permissions from the bucket owner; it requires an explicit bucket policy that allows the CloudFront service principal with a condition on the source ARN. Option B lacks this condition and principal, so it would not grant CloudFront access.
★ When this WOULD be the correct answer
This option would be correct if the question asked about a scenario where the S3 bucket is publicly accessible and no CloudFront origin access control is needed, such as when serving static assets directly from S3 without CloudFront.
Why candidates choose this
Candidates may mistakenly think that CloudFront inherits the bucket owner's permissions automatically, not realizing that OAC requires an explicit policy statement with the CloudFront service principal and source ARN condition.
✗Add a policy statement that denies s3:GetObject when the request does not include the header CloudFront-Viewer-Country.Wrong answer — click to see why▾
Why this is wrong here
This option is wrong because CloudFront OAC does not use headers like CloudFront-Viewer-Country for authentication; the 403 error is due to missing permissions for CloudFront to access S3, not due to missing headers.
★ When this WOULD be the correct answer
This option would be correct in a scenario where you need to restrict access to your S3 content based on viewer's country, such as when serving content only to specific countries for licensing or compliance reasons, and you want to deny access from other countries.
Why candidates choose this
Candidates might think that adding a header-based condition could resolve the access issue, misunderstanding that the 403 is about authorization, not about missing headers for geo-restriction.
✗Grant s3:GetObject permission to an Origin Access Identity (OAI) canonical user ID even though you are using Origin Access Control (OAC).Wrong answer — click to see why▾
Why this is wrong here
The question specifies using Origin Access Control (OAC), not Origin Access Identity (OAI). OAI uses a canonical user ID, but OAC uses the CloudFront service principal with a source ARN condition. Granting permissions to an OAI canonical user ID does not work with OAC, so the distribution will still receive 403 errors.
★ When this WOULD be the correct answer
If the question stated that the distribution uses an Origin Access Identity (OAI) instead of OAC, then granting s3:GetObject permission to the OAI's canonical user ID would be correct. For example: 'You configured CloudFront with an OAI to restrict access to an S3 bucket. Which bucket policy allows CloudFront to fetch objects?'
Why candidates choose this
Candidates may confuse OAI with OAC, or think that any identity-based access works similarly. They might recall that OAI uses canonical user IDs and assume it applies to OAC as well, not realizing OAC uses a different authorization mechanism.
Analysis generated from the official SAA-C03blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
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 SAA-C03 question is part of Courseiva's 302-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 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.