SCS-C02 Infrastructure Security Practice Question

A company wants to restrict access to an Amazon S3 bucket so that only users from a specific AWS account can upload objects. Which policy mechanism should be used?

⚠ Common exam trap

A common mix-up: candidates confuse IAM policies with resource-based policies, thinking an IAM policy can be attached to an S3 bucket, or they mistakenly believe bucket ACLs or pre-signed URLs can enforce account-level restrictions.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Create a bucket policy with a condition that checks the aws:SourceAccount condition key.

A bucket policy with the `aws:SourceAccount` condition key allows you to restrict access to a specific AWS account. When users from the allowed account upload objects, the condition evaluates the source account ID, ensuring only requests originating from that account are permitted. This is the recommended approach for cross-account access control in S3, as it directly enforces the account-level restriction at the bucket policy level.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Create a bucket policy with a condition that checks the aws:SourceAccount condition key.
Why this is correct
A bucket policy with an aws:SourceAccount condition key evaluates the account ID of the IAM principal that signs the request and is enforced by S3 when the bucket is accessed. This condition is evaluated against the requester's account number, allowing you to allow or deny access based on that account without specifying individual user ARNs. It is the recommended approach because it uses a resource-based policy that directly supports condition keys, and it ensures all requests from unintended accounts are rejected.
✗
Attach an IAM policy to the bucket that denies access to all users except those from the allowed account.
Why it's wrong here
IAM policies are identity-based and can be attached only to IAM users, groups, or roles—not to S3 buckets. Even if you attempted to attach an IAM policy to a bucket, S3 would ignore it, and the policy would not affect bucket access. Moreover, the requirement to restrict based on source account would require a condition key evaluation in the policy, but IAM policies do not natively evaluate the source account of the requester relative to a bucket. Thus, this approach is both invalid as a deployment mechanism and ineffective for the account restriction goal.
✗
Generate a pre-signed URL for each upload request.
Why it's wrong here
Pre-signed URLs are generated by an authorized user and grant time-limited access to a specific S3 object or operation, but they do not inspect who is using them. The URL contains a signature that authenticates the request, but it does not include or evaluate the AWS account of the requester; anyone with the URL can access the resource during the validity window. Therefore, pre-signed URLs are useful for delegating temporary access, but they cannot enforce a source-account restriction, making them unsuitable for this requirement.
✗
Configure the bucket ACL to grant access only to the allowed account's canonical user ID.
Why it's wrong here
Bucket ACLs allow access to be granted to specific canonical user IDs or AWS accounts, but they operate on a simplified permission model and do not support condition keys such as aws:SourceAccount. ACLs evaluate only the grantee's identity, not any context about the request origin, so they cannot distinguish between a request coming from an allowed account versus another account. Additionally, ACLs are a legacy access control mechanism that AWS recommends against using for complex restrictions, preferring bucket policies or IAM policies. Therefore, an ACL cannot enforce the required source-account check.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

SCS-C02 Infrastructure Security Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question