S3 access control: SAA-C03 study notes and practice questions
What to know about S3 access control for the SAA-C03 exam, from the Design Secure Architectures domain (30% of the exam guide), then 2 free questions to test it. Part of the SAA-C03 study guide.
S3 access questions usually describe who should (and shouldn’t) reach the data, and ask for the simplest control that enforces it. Learn the layers and what each one is for.
The layers
S3 Block Public Access, at the account or bucket level, overrides any policy or ACL that would make data public. It is on by default for new buckets. Turning it on at the account level is the quickest way to guarantee nothing is public.
Object Ownership set to “Bucket owner enforced” (the default for new buckets) turns ACLs off, so access is controlled only by policies. AWS recommends leaving ACLs off.
Bucket policies are resource-based: they can grant other accounts access, require conditions (a VPC endpoint, an IP range, TLS, an organization ID), or deny anything that doesn’t match.
IAM policies grant your own users and roles access. Within one account, an allow in either the IAM policy or the bucket policy is enough (unless something denies).
Presigned URLs give anyone holding the URL temporary access to one object, with the permissions of whoever signed it. Good for “let a customer download their invoice for 15 minutes”.
S3 Access Points give each application or team its own named endpoint with its own policy, which keeps one huge bucket policy manageable.
Origin access control (OAC) lets CloudFront read from a private bucket, and the bucket policy allows only that distribution. OAC replaces the older origin access identity and supports SSE-KMS.
How to choose
The scenario says
Look for
“Make sure no bucket in the account can ever be public”
Block Public Access at the account level (plus an SCP to stop it being changed)
“Users must only reach the files through CloudFront”
OAC and a bucket policy that allows the distribution
“Give a user temporary access to one object without an AWS account”
A presigned URL
“Only allow access from our VPC”
A bucket policy condition on aws:SourceVpce with a gateway endpoint
“Another account needs read access”
A bucket policy naming that account (and an IAM policy in that account)
“Many teams with different access to one bucket”
Access points
Common traps
Making the bucket public to serve a website through CloudFront. Keep it private and use OAC.
Using ACLs for new designs. The exam treats policies as the modern answer.
Presigned URLs outliving the signer. A URL signed with temporary role credentials stops working when those credentials expire, even if the URL’s own expiry is later.
A media company stores downloadable reports in an Amazon S3 bucket and serves them to customers through an Amazon CloudFront distribution.
Every object is encrypted with SSE-KMS using a customer managed key. A penetration test found that the reports can still be downloaded directly from the bucket's S3 URL.
The company must make the objects readable only through this one distribution, without changing how the objects are encrypted.
What should a solutions architect do?
Choose one answer.
AA. Create an origin access identity (OAI) for the distribution, grant the OAI s3:GetObject in the bucket policy, and remove all other public access.
BB. Use origin access control, allow the CloudFront service principal for this distribution in the bucket and key policies, and block public access.
CC. Turn on static website hosting, point CloudFront at the website endpoint, and have the bucket policy allow reads only with a secret header.
DD. Require CloudFront signed URLs through a trusted key group on the distribution, and keep the existing bucket policy that allows public reads.
Show the answer and explanation
Answer: B
A. Wrong: An OAI can restrict a bucket to CloudFront, but it does not support objects encrypted with SSE-KMS, so CloudFront could not read these reports. Origin access control replaced OAI and supports SSE-KMS when the key policy allows CloudFront. Learn more: Restrict access to an Amazon S3 origin (opens in a new tab)
B. Right: Correct. Origin access control signs CloudFront's requests to S3 and supports SSE-KMS. The bucket policy and the KMS key policy allow the cloudfront.amazonaws.com principal only when AWS:SourceArn is this distribution, and Block Public Access stops direct downloads. Learn more: Restrict access to an Amazon S3 origin (opens in a new tab)
C. Wrong: A website endpoint can only be a custom origin, so neither origin access control nor OAI can be used. The bucket policy must still allow anonymous reads, protected only by a header value that anyone who learns it can send. Origin access control on the REST endpoint is the recommended approach. Learn more: Hosting a static website using Amazon S3 (opens in a new tab)
Origin access control (OAC) is the AWS-recommended way to make an S3 bucket readable only through a CloudFront distribution. Unlike the older origin access identity, OAC supports SSE-KMS: the key policy must allow the CloudFront service principal, scoped to the distribution with AWS:SourceArn, just like the bucket policy. Signed URLs and website endpoints do not stop direct access to the bucket.
Both policies name the same distribution, so CloudFront can read and decrypt the objects while a direct S3 request is refused.
A marketing company has one AWS account with about 300 Amazon S3 buckets, and teams create new buckets every week.
Team leads have full permissions on their own buckets, including editing bucket policies, ACLs and bucket-level settings. After a competitor's data leak, the company wants to guarantee that no bucket, existing or future, can be made public, whatever a team lead changes.
Which solution meets this requirement with the LEAST effort?
Choose one answer.
AA. Turn on all four S3 Block Public Access settings at the account level, and allow only the security team to change account-level settings.
BB. Run a script that turns on all four Block Public Access settings on each existing bucket, and ask teams to keep them on for new buckets.
CC. Deploy the AWS Config s3-bucket-public-read-prohibited rule with automatic remediation that removes public statements from bucket policies.
DD. Set Object Ownership to bucket owner enforced on every bucket, so that ACLs are disabled and can no longer grant any public access.
Show the answer and explanation
Answer: A
A. Right: Correct. Account-level Block Public Access applies to every current and future bucket, and S3 uses the most restrictive of the account and bucket settings. A team lead who edits a bucket policy or bucket setting cannot undo it without s3:PutAccountPublicAccessBlock. Learn more: Blocking public access to your Amazon S3 storage (opens in a new tab)
B. Wrong: Bucket-level settings can be turned off by anyone with s3:PutBucketPublicAccessBlock on that bucket, which the team leads have. It also relies on teams for every new bucket. The account-level setting cannot be overridden from a bucket. Learn more: Blocking public access to your Amazon S3 storage (opens in a new tab)
C. Wrong: This detects public buckets and fixes them after the fact, so a bucket can be public for a while before remediation runs. The company needs a guarantee, which calls for a preventive control. Account-level Block Public Access gives that. Learn more: s3-bucket-public-read-prohibited (opens in a new tab)
S3 Block Public Access at the account level applies to all buckets the account owns, now and in future, and overrides any bucket policy, ACL or bucket-level setting that would allow public access. Changing it needs s3:PutAccountPublicAccessBlock, which can be kept from bucket owners. Detective rules and per-bucket settings leave gaps.
Want more on S3 access control? The 5 full-length practice sets have 10 more S3 access control questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →