Let the business-unit IAM user assume the top-level account role via an sts:AssumeRole policy
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?
Community Votes
75% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
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.
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.
Community Discussion (4 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.