A central security account must review CloudTrail logs stored in several department AWS accounts without sharing long-term access keys with those departments. What IAM pattern enables that cross-account access?
Select an answer to reveal the explanation.
Short Explanation
Cross-account roles are like a visitor badge that expires — the security team assumes a role in each department account for a short time instead of collecting permanent keys. No sticky notes with passwords, just temporary, auditable access.
Full Explanation
Cross-account IAM roles that allow a central security account to assume temporary access into department accounts enable review of CloudTrail logs without sharing long-term access keys. Cross-account roles are like visitor badges that expire — security assumes a role briefly for auditable access instead of collecting permanent keys. Embedding each department's root password in a shared spreadsheet is unsafe and non-scalable. Turning off IAM and using only security groups cannot authorize API access to logs. Creating identical IAM users with the same password in every account multiplies standing credentials. Distractors fail by spreading root secrets, by misunderstanding security groups as IAM replacements, or by cloning shared users. Exam caveat: design trust policies carefully so only the security account (or specific principals) may assume the role, and log AssumeRole extensively. Operational check: create a read-only log-review role in each department account, trust the security account, require MFA for assumption if policy dictates, grant least privilege to the log bucket, test assumption from the security account, and revoke trust quickly if an account leaves the organization model.