Let the business-unit IAM user assume the top-level account role via an sts:AssumeRole policy

SCS-C02 By islever Editorial Last updated

Design, implement, and troubleshoot authorization for AWS resources.

Short answer

A Attach a policy to the business-unit IAM user allowing sts:AssumeRole on the top-level account role.

Question

A company has an organization in AWS Organizations that includes dedicated accounts for each of its business units. The company is collecting all AWS CloudTrail logs from the accounts in a single Amazon S3 bucket in the top-level account. The company’s IT governance team has access to the top-level account. A security engineer needs to allow each business unit to access its own CloudTrail logs. The security engineer creates an IAM role in the top-level account for each of the other accounts. For each role, the security engineer creates an IAM policy to allow read-only permissions to objects in the S3 bucket with the prefix of the respective logs. Which action must the security engineer take in each business unit account to allow an IAM user in that account to read the logs?
  1. Attach a policy to the IAM user to allow the user to assume the role that was created in the top-level account. Specify the role’s ARN in the policy. Correct Answer
  2. Create an SCP that grants permissions to the top-level account.
  3. Use the root account of the business unit account to assume the role that was created in the top-level account. Specify the role’s ARN in the policy.
  4. Forward the credentials of the IAM role in the top-level account to the IAM user in the business unit account.

Key Takeaways

Cross-account access follows the standard assume-role pattern: the BU user gets a policy allowing sts:AssumeRole on the top-level role (A), then assumes it to read its prefixed logs. An SCP (B) governs org permissions, not user-to-role assumption. Using the BU root account (C) is an anti-pattern and unnecessary. Sharing role credentials (D) is insecure and not how cross-account access works. A is correct.

Centralized CloudTrail logs sit in a top-level account S3 bucket, with a per-business-unit IAM role (and prefix-scoped read policy) created there. To let a business-unit IAM user read that BU's logs, attach a policy to the user granting sts:AssumeRole on the respective top-level role's ARN; the user then assumes the role and inherits the prefix-scoped S3 read permissions. No SCP, root, or credential sharing is needed.

Common mistake: Creating an SCP (B)—SCPs set guardrails for accounts, they do not grant a user the ability to assume a role. Using the business-unit root account to assume the role (C)—root use violates best practice and is unnecessary. Forwarding role credentials (D)—you never share static credentials; you assume the role via STS. A is the correct pattern.

Expert Analysis

Why the Answer Is Correct

The established cross-account pattern is: the business-unit IAM user is given a policy allowing sts:AssumeRole on the top-level account role (whose trust policy permits the BU account), then assumes that role to obtain the prefix-scoped read permissions on the centralized S3 logs. This grants each BU access only to its own logs without sharing credentials.

Why the Other Options Are Wrong

B (SCP) manages account-level guardrails, not user-to-role assumption. C uses the business-unit root account, which is an anti-pattern and unnecessary. D forwards role credentials, which is insecure and not how cross-account access works—you assume the role via STS, you do not hand over credentials. A is correct.

Community Comment Notes

Community voted A (75), with C a 25 minority. Commenters showed the sts:AssumeRole policy on the user pointing at the top-level role ARN as the mechanism, and noted cross-account role assumption is the intended pattern. A confirmed.

Official Reference

https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html

This link opens the official vendor documentation in a new tab.

Community Votes

A
75%
C
25%

75% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 4 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 4

  1. AWSLoverLoverLoverLoverLover 👍 1 Answered A
    A. Attach a policy to the IAM user to allow the user to assume the role that was created in the top-level account. Specify the role’s ARN in the policy. Explanation: The IAM role in the top-level account is created to allow read-only access to specific CloudTrail logs. To allow an IAM user in a business unit account to access the logs, the user must assume the role in the top-level account. An IAM policy must be attached to the IAM user in the business unit account, allowing them to assume the role using the role's Amazon Resource Name (ARN).
  2. woonsi 👍 1 Answered A
    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::123456789012:role/BusinessUnitLogsAccess" } ] }
  3. phmeeeee 👍 1 Answered A
    A - the user needs permissions to assume the IAM role in the top-level account.
  4. Bachhu 👍 1 Answered C
    Cross account role.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Preserve EC2 forensic evidence by isolating first, then capturing memory before stopping the instance

S-grade

Grant the report Lambda Security Hub read-only access because findings are already in Security Hub

S-grade

Deny inbound MySQL 3306 and allow outbound TLS 443 with ephemeral return in a custom NACL

S-grade

Prepare a PHI/public-bucket audit with Macie, Audit Manager, and Security Hub FSBP

S-grade

← Back to SCS-C02 Study Guide