IAM Advanced via SDK Best Practices

Q: What's the single most common delegated-admin mistake?

Granting iam:CreateRole without also requiring the iam:PermissionsBoundary condition. Without it, a delegated admin can simply create an unbounded role and skip the safety cap entirely.

Q: What's the fastest way to verify a policy change didn't break anything?

Run SimulatePrincipalPolicy against the specific actions and resources your workload needs, before and after the change, and compare the EvalDecision values.

Policy review cadence and least-privilege enforcement patterns for advanced IAM setups - permission boundaries, cross-account trust, and org-wide guardrails.

Each rule is stated positively with a one-line reason and how to enforce it via the SDK.

How to Use This List

Walk it top to bottom when standing up delegated admin, cross-account, or org-wide IAM controls.
Treat each unchecked box as a finding to fix or consciously accept with a documented reason.
Categories are ordered by leverage - evaluation-model literacy first, then delegation controls, then ongoing auditing.
Re-run the auditing categories on a recurring cadence, not just once at setup.
Wire the checkable rules into CI, an ADR, or a scheduled Lambda so they don't silently regress.

A - Evaluation Model Literacy

Remember explicit Deny always wins. No Allow anywhere in the stack can override an explicit Deny - design guardrails around this, not against it.
Treat boundaries and SCPs as ceilings, never grants. An Allow in a boundary or SCP does nothing without a matching Allow in an identity-based or resource-based policy.
Check all five policy layers before trusting a single one. Identity-based, resource-based, permission boundary, SCP, and session policy must all agree for a request to succeed.
Simulate before you deploy. SimulatePrincipalPolicy catches a missing Allow or an unexpected Deny before it reaches production.
Document every required wildcard. When Resource: "*" is genuinely necessary, note why so a reviewer doesn't mistake it for laziness.

{
  "Sid": "RequireEncryptedRead",
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::acme-reports/*",
  "Condition": {
    "StringEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }
  }
}

B - Delegated Admin & Permission Boundaries

Never grant iam:CreateRole without a boundary condition. Require iam:PermissionsBoundary to match your approved boundary ARN, or a delegated admin can create an unbounded role.
Deny iam:DeleteRolePermissionsBoundary for delegated roles. Without this, an admin can create a properly-bounded role and strip the boundary off right after.
Size the boundary to the team's broadest legitimate need. An overly narrow boundary just generates constant escalation requests, undermining the point of delegating.
Never let a delegated admin edit the boundary policy itself. Withhold iam:CreatePolicyVersion on the boundary's ARN, or they can widen their own ceiling.
Pair every boundary with a real identity-based policy. A boundary alone grants nothing - the role still needs its own scoped Allow to do anything.

# --- Python (boto3) ---
# Good: CreateRole call includes the required boundary ARN.
iam.create_role(RoleName="team-service-role",
                AssumeRolePolicyDocument=trust_doc,
                PermissionsBoundary=boundary_arn)

// --- TypeScript (AWS SDK v3) ---
// Good: CreateRoleCommand includes the required boundary ARN.
await iam.send(new CreateRoleCommand({
  RoleName: "team-service-role",
  AssumeRolePolicyDocument: trustDoc,
  PermissionsBoundary: boundaryArn,
}));

C - Cross-Account Trust

Always require sts:ExternalId for third-party trust relationships. It defends against the confused deputy problem when a vendor's role ARN could otherwise be reused by an unrelated party.
Scope Principal to a specific role ARN when you know the caller. An account-root principal is looser than necessary when only one role in that account should assume yours.
Keep the trust policy and permissions policy conceptually separate. One governs who can assume the role, the other governs what it can do - manage them as two distinct decisions.
Prefer a resource-based policy for one-directional sharing. Skip role assumption entirely when the ask is just "let this account read this bucket."
Refresh assumed-role credentials via a provider, not a static client. Manually built clients with copied credentials won't refresh after the session expires (default one hour).

D - Org-Wide Guardrails (SCPs)

Never detach FullAWSAccess without an equivalent replacement. SCPs never grant access, so removing the default without a substitute drops the account to zero effective permissions.
Remember SCPs restrict the root user too. Unlike most IAM constructs, an SCP applies to the account's root user exactly like any other principal.
Test every SCP change in a sandbox OU first. An SCP attached to a live OU takes effect immediately and can silently break legitimate workloads org-wide.
Exclude control-plane actions from broad Deny statements. Use NotAction to keep iam:*, sts:*, and organizations:* working when restricting a service or region elsewhere.
Don't rely on SCPs to restrict the management account. SCPs never apply to the management account by design - use other controls there.

E - Continuous Auditing

Run Access Analyzer's unused-access findings on a schedule. It's a continuous scan, not a one-time report - re-check it as part of a recurring security review.
Review, don't auto-apply, unused-access recommendations. A permission unused in the lookback window might still back a legitimate infrequent task.
Paginate ListFindingsV2 for accounts with many roles. A single call may not return every finding - use the boto3 paginator or loop on nextToken.
Set unusedAccessAge to match your real review cadence. Too short a window flags normal infrequent access as noise; start around 90 days.
Archive, don't ignore, findings you've reviewed and accepted. Archiving records the decision explicitly so it stops resurfacing on every scan.

FAQs

Why is evaluation-model literacy listed first?

Because every other category assumes you already know that boundaries and SCPs are ceilings, not grants, and that explicit Deny always wins. Getting this wrong makes every downstream control confusing to debug.

What's the single most common delegated-admin mistake?

Granting iam:CreateRole without also requiring the iam:PermissionsBoundary condition. Without it, a delegated admin can simply create an unbounded role and skip the safety cap entirely.

Why require ExternalId even for a trusted vendor?

It protects against the confused deputy problem - a scenario where an intermediary service with its own trusted access could be tricked into assuming your role on behalf of an unrelated party, not the vendor being untrustworthy per se.

Is a resource-based policy always simpler than role assumption?

For one-directional, resource-scoped sharing, usually yes - there's no session lifecycle to manage. Role assumption is still preferable when you need a distinct, auditable permission set that differs from the caller's own identity.

What happens if I detach the default FullAWSAccess SCP by mistake?

Every account under that OU drops to zero effective permissions, since SCPs never grant access on their own - everything falls to implicit Deny until a replacement Allow is attached.

Do SCPs protect the AWS Organizations management account?

No. The management account is exempt from all SCPs by design, so other controls (IAM policies, monitoring, alerting) need to cover it.

How often should unused-access findings be reviewed?

On a recurring cadence tied to your security review cycle, not once. The analyzer runs continuously, so new findings appear as access ages past the configured window.

Should I trust an unused-access recommendation and remove the permission immediately?

Review with the resource owner first. A permission unused within the lookback window can still back a legitimate quarterly or annual task that the window didn't capture.

Why test SCP changes in a sandbox OU before rolling out broadly?

Because an SCP takes effect immediately once attached to a live OU, and a misconfigured Deny can block legitimate operations account-wide with no warning period.

What's the fastest way to verify a policy change didn't break anything?

Run SimulatePrincipalPolicy against the specific actions and resources your workload needs, before and after the change, and compare the EvalDecision values.

Should permission boundaries and SCPs ever contain identical rules?

Not necessarily - a boundary caps one role or user, while an SCP caps an entire account or OU. They're often layered together but solve different scope problems.

How do I keep these rules from silently regressing over time?

Wire the checkable ones into CI (policy linting, boundary-condition checks) or a recurring Lambda that re-runs Access Analyzer and posts findings somewhere visible, rather than relying on memory.

IAM's Policy Evaluation Logic - the model these rules protect.
Permission Boundaries for Delegated Admin - category B in depth.
Cross-Account Roles & Resource-Based Policies - category C in depth.
Service Control Policies (SCPs) via Organizations - category D in depth.
IAM Access Analyzer for Unused Access - category E in depth.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).