Use CloudFront OAC plus a bucket policy that allows only the OAC, and a WAF IP-set ACL
Short answer
B CloudFront OAC with a bucket policy allowing only the OAC, plus a WAF IP-set web ACL on the distribution.
Question
Key Takeaways
OAC (the modern successor to OAI) lets the bucket policy grant access exclusively to CloudFront, preventing direct S3-URL access. WAF IP-set rules filter by source IP at the distribution. A bucket policy using cloudfront.amazonaws.com with aws:SourceIp (A) does not guarantee traffic came via CloudFront and is not the recommended pattern; security groups (C) do not apply to S3; S3 access points (D) do not enforce IP allowlists at the edge like WAF. B is correct.
To serve an S3 static site only to specified IPs and block direct S3-URL access, create a CloudFront Origin Access Control (OAC) and set the bucket policy to allow access solely from that OAC—closing direct S3 access. Then attach an AWS WAF web ACL with an IP-set rule to the distribution to permit only the specified source IPs. This satisfies both requirements: private origin and IP restriction at the edge.
Common mistake: Using a bucket policy with cloudfront.amazonaws.com principal + aws:SourceIp (A)—that grants by service principal and does not truly lock access to only your distribution, and SourceIp there is unreliable for ensuring CloudFront-only. Using security groups (C)—S3 is not in a VPC and has no security groups. D's access point does not provide IP-set filtering like WAF.
Expert Analysis
Why the Answer Is Correct
Origin Access Control lets the S3 bucket policy grant access exclusively to the specific CloudFront distribution, eliminating direct S3-URL access. A WAF web ACL with an IP-set rule attached to the distribution then restricts who can reach the site to the specified IP addresses. Together they meet both constraints at the edge and origin.
Why the Other Options Are Wrong
A uses a bucket policy with the cloudfront.amazonaws.com service principal plus aws:SourceIp, which does not guarantee requests arrived via your distribution and is not the recommended lock pattern. C proposes security groups, but S3 is not VPC-resident and has no security groups. D uses an S3 access point, which does not provide edge IP-set filtering like WAF. B is correct.
Community Comment Notes
Community voted B (100). Commenters explained why A fails (service-principal + SourceIp does not ensure CloudFront-only access). B was confirmed as OAC + bucket policy restricted to OAC + WAF IP set.
Official Reference
- https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html
- https://docs.aws.amazon.com/waf/latest/developerguide/ip-sets-managing.html
These links open the official vendor documentation in a new tab.
Community Votes
100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 3 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 3
-
5409b91 👍 7 Answered BWhy Not Other Options? Option A: Specifying cloudfront.amazonaws.com as the principal with aws:SourceIp condition key in the bucket policy does not ensure that access is only through CloudFront, as it does not tie the access to a specific CloudFront distribution. Option C: Security groups cannot be used to control access to S3 buckets; they are used for controlling access to EC2 instances, among other resources. This approach would not meet the requirement. Option D: Using an S3 bucket access point is unnecessary when OACs and bucket policies can effectively manage the access requirements. Also, access points are more relevant for complex access control scenarios and do not inherently solve the issue of restricting direct S3 access via CloudFront.
-
Certified101 👍 2 Answered BB is correct
-
navid1365 👍 1 Answered BB is the correct answer
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.