SCS-C02 Cross-account access Practice Question

A company has an S3 bucket policy that allows cross-account access for a specific IAM role in another account. The bucket policy includes a Principal element with the ARN of the role. However, users in the other account that assume the role are unable to access the bucket. Which of the following is the MOST likely cause?

⚠ Common exam trap

Candidates often forget that the IAM role itself needs both a trust policy and a permissions policy. The bucket policy grants access to the role, but the role must also have the required permissions.

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

✓

The IAM role does not have a permissions policy granting s3:GetObject on the bucket.

For cross-account access using an S3 bucket policy, the IAM role in the trusted account must have a permissions policy that grants the necessary S3 actions (e.g., s3:GetObject). Without this policy, even if the bucket policy allows the role, the role itself does not have permission to perform the action. Options B, C, and D are less likely: B is possible but not the most common; C is incorrect because the trust policy allows users to assume the role, not the S3 service; D is incorrect because role ARNs are valid principals in S3 bucket policies.

Answer analysis

Option-by-option breakdown

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

✓
The IAM role does not have a permissions policy granting s3:GetObject on the bucket.
Why this is correct
In cross-account S3 access, the requesting IAM role must have an identity-based permissions policy that explicitly allows s3:GetObject on the specific bucket. The bucket policy alone is insufficient; if the role lacks the necessary IAM permissions, the request is denied even when the bucket policy states that access is allowed. This missing permissions policy is the most common root cause when a role cannot read from a bucket it was supposedly granted access to.
✗
The bucket policy has an explicit Deny statement that overrides the Allow.
Why it's wrong here
An explicit Deny statement in a bucket policy would indeed override any Allow and cause an AccessDenied error. However, such a Deny is a deliberate and explicit configuration that would be visible in the policy, whereas the more likely oversight is a missing IAM permissions policy on the role. Without evidence of a Deny, this is not the probable cause of the access failure described in the scenario.
✗
The role's trust policy does not allow the S3 service to assume the role.
Why it's wrong here
A trust policy governs which principals are allowed to call sts:AssumeRole on the IAM role, effectively controlling who can obtain the role's credentials. The S3 service does not assume IAM roles directly; a user or an AWS resource (like an EC2 instance) first assumes the role and then uses its temporary credentials to call S3. Therefore, the trust policy's content is not the reason for a failed S3 GetObject request, unless the user attempting to assume the role is not permitted.
✗
The bucket policy uses the role ARN in the Principal element instead of the AWS account ID.
Why it's wrong here
Using an IAM role ARN as the Principal in an S3 bucket policy is a valid pattern for cross-account access. When the Principal is set to a role ARN, the policy grants access specifically to that role, and AWS will still evaluate the role's permissions policy alongside this bucket policy. Therefore, the role ARN in the Principal element does not cause a failure; it actually narrows the grant to that individual role rather than the entire account.

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 Cross-account access Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question