A regional bank hires three audit firms that all need short-lived read-only access to transaction logs in the bank's AWS account. Compliance requires prevention of confused-deputy access, a hard cap on maximum permissions, and no long-term keys. What access design meets these needs with least privilege?

The correct design uses STS-based cross-account role assumption so auditors obtain temporary credentials with no long-term keys to manage, while read-only scoping enforces least privilege for transaction logs, short session duration enforces short-lived access, external ID binds the trust policy to the specific third party to prevent confused-deputy substitution, and permissions boundary provides an independent hard cap that limits maximum effective permissions even if identity policies grow. The design without external ID fails on confused-deputy prevention because scoped policy, boundary and short duration still leave the trust policy trusting only an account ID that any other customer of that auditor could potentially exploit via role assumption. The design with only a scoped inline policy and external ID fails on maximum cap because an identity policy alone is not a boundary and can drift upward without a separate guardrail ceiling. The design allowing long session duration fails on the short-lived requirement because extended temporary credentials widen the blast radius of leaked sessions despite correct trust and cap controls. The exam caveat is to distinguish scoping policies from boundaries and external ID from MFA or tags, since questions often test which control limits who can assume trust versus which control limits what permissions can become effective. The practical check is to review CloudTrail AssumeRole events for external ID mismatch denials, validate effective permissions with IAM Access Analyzer, and confirm the role maximum session duration is kept short, such as the one-hour default, for audit roles.