Free SAA-C03 practice scenarios: S3 bucket policies

Controlling who reaches your objects — public-access blocks, policy conditions, cross-account grants and presigned URLs. Six scenarios, SAA-C03, 2026 edition.

Try 6 free S3 access-control scenarios in the exam's own style — every answer explained, no sign-up.

Straight to the 6 free questions ↓

S3 access control is a dense corner of the secure-architectures domain, and the exam tests it with requirements that each map to one specific mechanism. Learn which control answers which requirement and these scenarios become fast, reliable marks.

The guarantee: Block Public Access

When the requirement is an account-wide guarantee that nothing can ever be public, the answer is S3 Block Public Access. It overrides any ACL or bucket policy that would grant public access, for every bucket now and in future — a single setting that no later team can accidentally undo. Per-bucket deny policies solve a narrower version of the same problem but must be maintained everywhere and can be edited away.

The bucket policy: one control, every request

A bucket policy is resource-based, so it applies to every request to the bucket regardless of who makes it — which is why it, not an identity policy, is the exam’s answer for account-wide rules. Three conditions recur:

Enforce encryption → Deny s3:PutObject when the server-side-encryption header is absent, so a non-encrypting upload is rejected rather than silently stored.
Enforce TLS → Deny all actions when aws:SecureTransport is false, refusing any plain-HTTP request.
Restrict to a VPC endpoint → Deny unless aws:sourceVpce matches the named endpoint, so only in-network traffic reaches the bucket.

Notice the pattern: each is an explicit Deny with a condition. Deny is airtight where an allow-only phrasing can leak through a separate grant.

Cross-account access

To let a principal in another account act on your bucket, add a bucket policy naming that account’s role — the direct, least-privilege grant. The distractors all overreach: making the bucket public to serve one account, copying data to duplicate it, or sharing root credentials. Cross-account object access is a resource policy naming the other side, nothing more.

When an unauthenticated user needs one object for a limited time without the object becoming public, the answer is a presigned URL. It carries signed, expiring permission for that single object. Turning on public read, minting an IAM user, or emailing the file each fail some part of “one object, temporary, still private”.

How to use the six scenarios below

Answer each one before opening the explanation, and when you miss, name the requirement that decided it — “account-wide guarantee”, “reject unencrypted”, “only over HTTPS”, “another account”, “only through the endpoint”, “temporary and private”. Every explanation states that constraint and then dismantles the distractors, which are usually real S3 features answering a slightly different requirement. For the domain overview, see Design Secure Architectures.

The layers controlling access to an Amazon S3 bucket: S3 Block Public Access as an account and bucket-level guard that overrides any public grant, a resource-based bucket policy that can require encryption and TLS and can grant cross-account access to a named principal, identity-based IAM policies on the callers, and presigned URLs granting time-limited access to a single object without making it public.

6 free SAA-C03 practice questions

Answers and explanations — no email wall

SAA-C03 Question 1 of 6

An audit finds that several S3 buckets were accidentally made public through bucket ACLs and policies. The company wants a single guarantee that no bucket in the account can be exposed publicly, regardless of any policy a team later writes. What should a solutions architect enable?

Answer: A — S3 Block Public Access at the account level.

S3 Block Public Access, set at the account level, overrides any ACL or bucket policy that would grant public access — one setting that guarantees the outcome for every current and future bucket. Why not the others: a per-bucket deny policy has to be written and maintained on each bucket and can be edited away, so it is not the account-wide guarantee asked for. Default encryption protects data at rest, not who can reach it. Versioning helps you recover objects, not restrict access. When the requirement is 'nothing can be public, account-wide', it is Block Public Access.

SAA-C03 Question 2 of 6

A company requires that every object written to a bucket is encrypted at rest, and wants uploads that do not request encryption to be rejected rather than silently stored unencrypted. How can a bucket policy enforce this?

Answer: A — Deny s3:PutObject when the request lacks the server-side-encryption header.

A bucket policy with a Deny on s3:PutObject conditioned on the absence of the encryption header rejects any non-encrypting upload outright — exactly the 'reject rather than store' behaviour required. Why not the others: default encryption would encrypt the object anyway, but it does not reject the request, so it fails the explicit 'reject' requirement. An identity policy only governs your own IAM principals and misses any other caller with access. Block Public Access is about exposure, not encryption. The resource-based bucket policy is the one control that applies to every request to the bucket.

SAA-C03 Question 3 of 6

A security standard mandates that all access to an S3 bucket must use HTTPS; any request over plain HTTP must be refused. Which bucket policy condition enforces this?

Answer: A — Deny all actions when aws:SecureTransport is false.

A Deny statement conditioned on aws:SecureTransport being false refuses every non-HTTPS request while leaving normal HTTPS access untouched — the standard, robust way to mandate TLS on a bucket. Why not the others: writing it as an allow-only-when-true is fragile because a separate allow elsewhere could still let an HTTP request through; the explicit deny is airtight. MFA governs authentication strength, not transport encryption. Access logging records requests but blocks nothing. Enforcing transport security is an explicit deny on insecure transport.

SAA-C03 Question 4 of 6

An application in AWS account B must read objects from a bucket owned by account A. What is the most direct way to grant this cross-account access?

Answer: A — Add a bucket policy in account A granting the account B role read access to the bucket.

A bucket policy is resource-based and can name a principal in another account, so granting the account B role read access on account A's bucket is the direct, least-privilege cross-account grant. Why not the others: making the bucket public exposes it to the entire internet to solve access for one account. Scheduled copying duplicates data and storage cost and introduces staleness for what should be a direct read. Sharing root credentials is a severe security violation and grants far more than read access. Cross-account object access is a bucket policy naming the other account's principal.

SAA-C03 Question 5 of 6

A company wants objects in a sensitive bucket to be reachable only by requests originating from a specific VPC endpoint, and blocked from anywhere else. Which approach meets this?

Answer: A — A bucket policy that denies access unless the request comes through the specified VPC endpoint (aws:sourceVpce).

A bucket policy can condition access on aws:sourceVpce, denying any request that does not arrive through the named VPC endpoint — precisely 'only from this endpoint, nowhere else'. Why not the others: S3 is a regional service and buckets do not live inside a VPC, so you cannot move it in or give it a subnet IP. Security groups attach to elastic network interfaces, not to S3 buckets, so they cannot gate bucket access. Restricting a bucket to an endpoint is a bucket-policy condition on the source VPC endpoint.

SAA-C03 Question 6 of 6

A user who is not authenticated to AWS needs to download one private object for a limited time, without the object being made public. What should a solutions architect use?

Answer: A — A presigned URL for the object with a short expiry.

A presigned URL embeds time-limited, signed permission to access one specific object, so an unauthenticated user can download it until the URL expires while the object itself stays private. Why not the others: making the object public exposes it to everyone and is hard to fully reverse. Creating an IAM user for an external person is heavy and inappropriate for a one-off download. Emailing the object may breach size limits and loses the controlled, expiring access the presigned URL provides. Temporary access to one private object without exposure is a presigned URL.

That is exactly how every question in the course works — answer, explanation, why-not. The real set continues in the practice player: 10 free questions, no sign-up.

Continue with the 10 free questions →

Those 6 questions were the start.

The exam does not test whether you recognise a term — it tests whether you can rule out three plausible answers under time pressure. That is what the explanations above are for, and there are 780 more questions built exactly like them.

Collecting questions yourself

Scattered across forums, of unknown age
Answer keys without reasoning
No idea which domain you are weak in

Practising with a system

780 questions in 12 full tests, SAA-C03 (2026)
Every option explained — including the wrong ones
Readiness per exam domain, and drills for your weakest

Start free — 10 questions

Straight into the player. No account, no email.

Frequently asked questions

Bucket policy or IAM policy — which controls S3 access?

Both can. An IAM (identity-based) policy says what a principal may do; a bucket (resource-based) policy says who may act on the bucket and can name principals in other accounts. For account-wide requirements like enforcing encryption, TLS or cross-account access, the exam usually wants the bucket policy because it applies to every request to the bucket.

Does Block Public Access override my bucket policy?

Yes. S3 Block Public Access takes precedence over any ACL or bucket policy that would grant public access, which is exactly why it is the right answer when the requirement is a guarantee that nothing can be exposed publicly.

Are these real exam questions?

No. They are original scenarios written for this page in the exam's style and difficulty. Reproducing real exam items violates the AWS certification agreement and can cost a candidate their certification — ours come with the reasoning attached instead.

What is the one-line takeaway?

Guarantee no exposure with Block Public Access; enforce encryption, TLS and endpoint-only access with bucket-policy conditions; grant cross-account with a bucket policy; and share one object privately with a presigned URL.

Updated for SAA-C03 (July 2026). The sample questions above are our own work in the style of the exam — not real exam items. The exam itself is set and marked by the certification body.