mediummultiple choiceObjective-mapped

A static website uses an Amazon S3 bucket as the origin for an Amazon CloudFront distribution. The team accidentally configured the S3 bucket policy to allow s3:GetObject to Principal "*", so objects are accessible via direct S3 URLs. They want to ensure objects are retrievable only through CloudFront. What is the best corrective action?

Question 1mediummultiple choice
Full question →

A static website uses an Amazon S3 bucket as the origin for an Amazon CloudFront distribution. The team accidentally configured the S3 bucket policy to allow s3:GetObject to Principal "*", so objects are accessible via direct S3 URLs. They want to ensure objects are retrievable only through CloudFront. What is the best corrective action?

Answer choices

Why each option matters

Good practice is not just finding the correct option. The wrong answers often show the exact trap the exam wants you to fall into.

A

Best answer

Remove public access from the bucket and update the bucket policy to allow GetObject only from CloudFront using the distribution’s SourceArn (and use CloudFront origin access control or origin access identity).

Restricting the bucket policy to CloudFront’s principal with a SourceArn condition prevents direct S3 access while enabling CloudFront.

B

Distractor review

Enable S3 static website hosting and disable CloudFront, because website hosting blocks direct object URL access.

S3 website hosting often requires specific configuration and does not inherently provide origin-only access controls for security.

C

Distractor review

Add a WAF rule that rate-limits requests to the S3 bucket domain to make direct access impractical.

WAF typically applies at CloudFront/web front ends; rate limiting does not provide guaranteed access restriction at the bucket.

D

Distractor review

Turn on S3 object versioning so that attackers cannot read previous objects.

Versioning affects recovery and deletion semantics, not whether objects are publicly readable via S3.

Common exam trap

Common exam trap: authentication is not authorization

Logging in proves the user can authenticate. It does not automatically mean the user is allowed to enter privileged or configuration mode. Watch for AAA authorization, privilege level and command authorization details.

Technical deep dive

How to think about this question

This kind of question is testing the difference between identity and permission. A user may successfully log in to a router because authentication is working, but still fail to enter configuration mode because authorization is missing, misconfigured or mapped to a lower privilege level.

KKey Concepts to Remember

  • Authentication checks who the user is.
  • Authorization controls what the user is allowed to do after login.
  • Privilege levels affect access to EXEC and configuration commands.
  • AAA, TACACS+ and RADIUS can separate login success from command access.

TExam Day Tips

  • Do not assume successful login means full administrative access.
  • Look for words such as cannot enter configuration mode, privilege level, authorization or command access.
  • Separate login problems from permission problems before choosing the answer.

Related practice questions

Related SAA-C03 practice-question pages

Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.

More questions from this exam

Keep practising from the same exam bank, or move into a focused topic page if this question exposed a weak area.

FAQ

Questions learners often ask

What does this SAA-C03 question test?

Authentication checks who the user is.

What is the correct answer to this question?

The correct answer is: Remove public access from the bucket and update the bucket policy to allow GetObject only from CloudFront using the distribution’s SourceArn (and use CloudFront origin access control or origin access identity). — The right way to prevent direct S3 access while still serving through CloudFront is to change the S3 bucket policy to only permit CloudFront to read objects. This is typically done by removing public principals, then allowing s3:GetObject for the CloudFront origin principal (using CloudFront origin access control or origin access identity) and scoping access with a condition like aws:SourceArn matching the specific distribution. With this configuration, direct S3 URLs are denied because requests from the public principal do not match the CloudFront principal/source restrictions. Static website hosting is not a reliable access control mechanism for origin-only retrieval and can still expose objects depending on configuration. WAF rate limiting targets the CloudFront/WAF layer and doesn’t enforce S3 authorization; attackers could still access S3 if the bucket policy allows it. Object versioning doesn’t address read permissions; it only helps with recovery and rollback, not confidentiality.

What should I do if I get this SAA-C03 question wrong?

Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.

Discussion

Loading comments…

Sign in to join the discussion.