REFERENCE GUIDE
Role assumption, trust policy, and session scope
Assuming a role exchanges one identity context for a temporary session governed by a trust policy and permissions.
Also known as: STS · AssumeRole
Mechanism
Assuming a role exchanges one identity context for a temporary session governed by a trust policy and permissions. The caller must satisfy the trust relationship and any applicable caller-side authorization. External IDs, MFA, source identity, tags, and organization conditions can narrow who may obtain the session.
Practical method
Identify the caller and target role. Read the trust policy separately from the role permission policies. Map every condition to the actual request context. In the authorized lab, obtain a bounded session and verify its identity and one harmless permitted action.
caller authorization + role trust conditions -> session
session permissions remain constrained by its policies and limits
Interpreting evidence
A successful assume-role operation establishes session acquisition. Impact depends on the effective permissions of that session, not the role name.
Pitfalls and limits
Trusting an account principal does not always mean trusting every identity unconditionally. Session policies can reduce permissions. Chained role sessions have distinct duration limits and context propagation rules.