SCS-C02 Identity and Access Management Practice Question
A security administrator is designing a cross-account access strategy. The administrator needs to allow users in Account A to assume an IAM role in Account B to access an S3 bucket. Which TWO of the following statements are true regarding this configuration?
⚠ Common exam trap
Test-takers frequently confuse where the trust policy is defined (it must be on the role in the target account, not in the source account) and assuming that direct IAM user permissions on the S3 bucket are required instead of using the assumed role's 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 users in Account A must have an IAM policy that allows the sts:AssumeRole action for the role ARN in Account B.
For an IAM user in Account A to assume a role in Account B, the user must be explicitly granted permission to call the sts:AssumeRole API action against the role's Amazon Resource Name (ARN). This is done by attaching an IAM policy to the user (or a group/role the user belongs to) that includes the sts:AssumeRole action and specifies the target role ARN as the resource. Without this permission, the user cannot initiate the cross-account role assumption, even if the role's trust policy allows it.
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 users in Account A must have an IAM policy that allows the sts:AssumeRole action for the role ARN in Account B.
Why this is correct
The IAM users in Account A must have an identity-based policy that explicitly grants the sts:AssumeRole action against the role ARN in Account B. Without this allow, the AssumeRole API call is denied even if the trust policy in Account B permits the user, because IAM policies are evaluated by default-deny. The policy should specify the exact role ARN in the Resource element, for example arn:aws:iam::AccountB:role/CrossAccountRole.
- ✗
The trust policy for the role must be defined in Account A.
Why it's wrong here
The trust policy is a resource-based policy that is attached to the IAM role in Account B, the account that owns the role. It cannot be defined in Account A because Account A does not own the role resource; resource-based policies must be created in the account where the resource resides. The trust policy in Account B specifies which principals, such as the IAM users in Account A, are allowed to assume that role.
- ✗
The S3 bucket policy must grant access to the IAM users in Account A.
Why it's wrong here
When a user in Account A assumes a role in Account B, the resulting session uses the role's identity and permissions, not the user's original IAM identity. Therefore, the S3 bucket policy in Account B should grant the role ARN (e.g., arn:aws:iam::AccountB:role/CrossAccountRole) as the Principal, not the individual IAM user ARNs. If the bucket policy only references the users, the assumed-role session will be denied because the role is the principal making the request.
- ✓
The role in Account B must have a trust policy that allows the IAM users in Account A to assume the role.
Why this is correct
The trust policy on the role in Account B is the resource-based policy that defines the trust relationship for cross-account access. It must explicitly allow the IAM users from Account A (or the entire Account A as a principal) to perform sts:AssumeRole on the role. Without such a trust policy, the role will reject any assume-role call, regardless of the user's own IAM permissions—both the identity policy and the trust policy are required.
- ✗
The IAM users in Account A must have cross-account permissions on the S3 bucket in Account B.
Why it's wrong here
The IAM users in Account A do not access the S3 bucket directly; they assume the role in Account B, and that role carries the S3 permissions via its attached identity policy. The role's permissions are the sole determinant of access to the bucket for the assumed-role session. Consequently, the users do not need any cross-account S3 bucket permissions—only the sts:AssumeRole permission on their own policy.
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
Related to this question
About these practice questions
One of 1,205 original SCS-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SCS-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SCS-C02 exam.