Cross-Account S3 Access Denied: How to Fix

• ✓ A.The target account has not attached an IAM policy granting the user or role s3:PutObject
• B.The bucket has an S3 ACL that denies the target account
• C.The bucket policy does not allow s3:PutObject for the target account
• D.The bucket is encrypted with SSE-KMS and the target account lacks KMS permissions

Why A: Option A is correct because cross-account S3 access requires both a bucket policy that grants the target account principal (or a resource-based policy) AND an IAM policy in the target account that explicitly allows the user or role to perform the s3:PutObject action. Without the target account's IAM policy, the request is denied even if the bucket policy permits it, as the target account's principal lacks the necessary permissions to make the call.

• A.An S3 bucket policy in Account B that allows the IAM user's ARN.
• ✓ B.An IAM policy in Account A allowing access to the S3 bucket, and a bucket policy in Account B allowing the IAM user.
• C.An IAM policy in Account A allowing access, and a bucket ACL in Account B granting access to the IAM user.
• D.Create an IAM role in Account B that the user can assume, and attach a bucket policy allowing the role.

Why B: Option B is correct because cross-account S3 access requires two policies: an IAM policy in the source account (Account A) granting the user permission to perform S3 actions on the bucket, and a bucket policy in the target account (Account B) that explicitly allows the IAM user's ARN. The bucket policy acts as a resource-based policy that delegates access to the external principal, while the IAM policy authorizes the user to make the request. Without both, the request will be denied by either the source account's implicit deny or the target account's default deny.

• A.No additional steps are needed; the bucket policy alone is sufficient.
• ✓ B.The administrator of Account B must attach an IAM policy to the user that allows the required S3 actions.
• C.Create a new IAM role in Account B and have the user assume the role.
• D.Enable S3 ACLs on the bucket and grant write access to the Account B user.

Why B: Option B is correct because cross-account access to S3 requires both a resource-based policy (the bucket policy in Account A) and a user-based policy (an IAM identity-based policy in Account B). The bucket policy grants permissions to the Account B user, but that user cannot perform actions unless their own account explicitly allows those actions via an IAM policy. Without this, the request is denied by the user's own account's implicit deny, even if the bucket policy permits it.

• A.Add the developer's IAM user ARN to the bucket policy in Account A.
• B.Configure a VPC endpoint for S3 in Account A and attach it to the bucket policy.
• ✓ C.Ensure the bucket policy grants the necessary permissions to the IAM role ARN from Account B.
• D.Create an IAM user in Account A and grant it S3 access, then share the credentials with the developer.

Why C: The correct answer is C: Ensure the bucket policy grants the necessary permissions to the IAM role ARN from Account B. The developer is able to assume the IAM role in Account B, but the role itself does not have access to the S3 bucket because the bucket policy in Account A does not explicitly grant permissions to the role ARN. The bucket policy must include a statement allowing the role (e.g., arn:aws:iam::AccountB:role/RoleName) to perform the required actions on the bucket. Option A is incorrect because adding the developer's IAM user ARN to the bucket policy is unnecessary; the access is via the assumed role. Option B is incorrect because a VPC endpoint is not required for cross-account S3 access. Option D is incorrect because it bypasses the cross-account role setup and is less secure.