Identity and Access Management
The evaluation funnel
Every request passes through layers, and an explicit Deny anywhere wins. Top-down: SCPs (Organizations) → resource-based policy → permission boundary and session policy (they intersect, they never grant) → identity-based policy. In the same account, an allow from either the identity policy or the resource policy is generally enough; for cross-account access you need both an identity policy in the caller's account and a resource/trust policy in the owner's account. SCPs and permission boundaries cap permissions - they never grant them - and SCPs do not apply to the management account.
A role's trust policy is a resource policy answering "who may assume me." For third parties, require an ExternalId to defeat the confused deputy problem. Sessions default to one hour, are capped at twelve, and role chaining resets to one hour - a frequent distractor in long-running automation questions.
Federation and hygiene
Workforce SSO belongs in IAM Identity Center; customer-facing identity belongs in Cognito; EC2 gets roles through instance profiles and EKS through IRSA or Pod Identity, so no long-term keys exist. Use Access Analyzer to find resources shared externally, credential reports and Access Advisor to prune unused permissions, and attribute-based access control with aws:PrincipalTag to scale policies.
Worked example
A role in account A must read a bucket in account B. Attach an identity policy in A allowing s3:GetObject on the bucket ARN, and add a bucket policy in B naming the role ARN as principal. Forgetting either side is the classic wrong answer.
Rule of thumb
Draw the funnel and ask at each layer: is there a deny, and does this layer allow? Anything not explicitly allowed is denied.