A developer notices that an S3 bucket used for static website hosting returns 403 Forbidden for anonymous requests. The bucket policy allows s3:GetObject for Principal "*". What is the most likely issue?
Amazon S3 Block Public Access settings provide a crucial security control designed to prevent unintended public exposure of S3 buckets and objects. These settings, configurable at both the account and bucket level, explicitly override all other access control mechanisms, including permissive bucket policies and object ACLs, that would otherwise grant public access. If these Block Public Access settings are enabled, they will effectively block all public access to the static website, regardless of any correctly configured bucket policies or ACLs intended to allow public reads.
Why this answer
D is correct because S3 Block Public Access settings, when enabled at the account or bucket level, override any bucket policy or ACL that grants public access. Even though the bucket policy allows s3:GetObject for Principal "*", the Block Public Access settings explicitly deny all public requests, resulting in a 403 Forbidden error for anonymous users.
Exam trap
The trap here is that candidates often assume a bucket policy granting public access is sufficient, overlooking the S3 Block Public Access settings which silently override such policies and cause 403 errors.
How to eliminate wrong answers
Option A is wrong because server access logging is a feature for logging requests to the bucket, not a permission control; it does not affect whether requests are allowed or denied. Option B is wrong because the bucket policy already grants public read access via Principal "*", and while ACLs can also grant public read, the bucket policy takes precedence; the issue is not the ACL but an overriding deny. Option C is wrong because the question states the bucket policy is attached and allows s3:GetObject, so the policy is correctly associated; the problem lies with a separate security mechanism.