Identity and Access Management
Policy evaluation, in order
Every request is evaluated against: explicit deny anywhere (identity policy, resource policy, SCP, permission boundary, session policy) → SCPs, which must allow → an allow in the identity policy or resource policy → permission boundary and session policy, which must also allow. Two rules cover most questions: an explicit deny always wins, and permission boundaries and SCPs never grant anything - they only cap what identity policies can grant.
SCPs apply to every principal in a member account, including the root user, but not to the management account and not to service-linked roles. They are the tool for organization-wide guardrails such as region restriction or blocking iam:CreateUser.
Roles, trust, and the confused deputy
A role carries two policies: the trust policy (who may assume it) and the permission policy (what it can do). Cross-account access requires the trust policy to allow the caller and the caller's identity policy to allow sts:AssumeRole. For third parties require an ExternalId; for AWS services acting on your behalf, scope with aws:SourceAccount and aws:SourceArn, or aws:PrincipalOrgID for your own organization.
Least privilege at scale
IAM Access Analyzer finds resources shared outside your zone of trust, generates policies from CloudTrail history, flags unused permissions, and validates policies. Attribute-based access control using aws:PrincipalTag and aws:ResourceTag conditions scales better than per-team roles. IAM Identity Center with SAML/OIDC federation is the answer for human workforce access; long-lived IAM users with access keys are always the wrong answer. Lock the root user down with MFA and no access keys.
Traps
A permission boundary alone grants nothing. Same-account access succeeds if either the identity policy or the resource policy allows it; cross-account needs both. aws:MultiFactorAuthPresent is only present for temporary credentials from an MFA-authenticated session, so attaching it to long-term keys silently denies.
Worked example: a role in account A must read a bucket in account B. Attach an identity policy allowing s3:GetObject on the bucket ARN, and add a bucket policy in B naming arn:aws:iam::A:role/Reader - plus a KMS key policy grant if objects are SSE-KMS encrypted. Missing the KMS grant is the most common wrong answer.