Account A owns an S3 bucket. A team in Account B needs to be able to run GetObject and PutObject against a specific prefix in that bucket, using their own IAM role in Account B, without Account A creating any IAM users for Account B's team. Which mechanism directly grants this cross-account access?
- An S3 Access Control List (ACL) granting Account B's root user FULL_CONTROL over the bucket
- An IAM permissions boundary attached to Account B's role
- S3 Object Lock configured in Governance mode on the prefix
- A bucket policy on Account A's bucket that names Account B's IAM role ARN as principal and allows the required actions on that prefix
Why D? And why not the others?
Correct answer: D. A bucket policy on Account A's bucket that names Account B's IAM role ARN as principal and allows the required actions on that prefix
A bucket policy is a resource-based policy attached to the bucket itself, so the bucket's owning account can name a principal in another account, such as a specific IAM role ARN, and grant that principal the exact actions and resources needed, including a scoped prefix, entirely from the S3 side without creating any IAM users in the other account. This is the standard way to grant cross-account access to S3 data. An ACL granting a whole other account's root user full control is far broader than the requirement and cannot be scoped to a prefix or to specific API actions the way a policy can, and modern buckets disable ACLs by default besides. A permissions boundary only limits what an IAM principal can be granted within its own account; it cannot itself grant access to a resource owned by a different account. Object Lock governs whether objects can be deleted or overwritten during a retention period and has nothing to do with granting read or write access across accounts.
Source: AWS S3 docs: Bucket policies for Amazon S3