mediumFoundationSymptom-first#iam#role#propagation#eventual-consistency

New IAM role says 'not authorized' — propagation delay

Freshly created role fails with AccessDenied/not authorized

Likely source:configurationsecurity

Focused incident mode — strips away everything but this runbook.

Symptoms

  • Freshly created role fails with AccessDenied/not authorized
  • Same calls succeed minutes later without any change
  • Issue appears right after a role or policy was created/updated

IAM is eventually consistent — 95%+ of 'not authorized' moments after a role/policy change are just propagation, not misconfiguration. Wait-and-retry is the correct first move; dig deeper only if it persists for tens of minutes.

Evidence to grab

Collect these artifacts before you change anything — they prove (or rule out) each cause.

  • Role existence

    aws iam get-role --role-name <ROLE-NAME>

  • Policies attached

    aws iam list-attached-role-policies --role-name <ROLE-NAME> --no-cli-pager

Diagnostic flow

Run the steps in order, marking each claim confirmed or refuted. The evidence you gather feeds the ranked causes below.

Guided decision tree is ready.

Steps with commands, expected output, and pass/fail branches.

Ranked root causes

Evidence checklist

  • Failure began at the moment the role or policy was created
  • Retries succeed seconds/minutes later without changes

Confirm before fixing

aws iam get-role --role-name <ROLE-NAME> --query 'Role.CreateDate' && date -u
READ

Compare role age to first failure time

Fix

sleep 30 && aws sts get-caller-identity
READ

Wait out the propagation window and re-test

Expected: Identity resolves (no error)

Resolution runbook

Apply from top to bottom after the cause is confirmed. Review every command before running it — risk tags are shown on each.

1
aws iam get-role --role-name <ROLE-NAME>
READ

Confirm the role exists

2
aws iam list-attached-role-policies --role-name <ROLE-NAME>
READ

Confirm policies are attached and correct

3
sleep 30 && <retry-the-failing-command>
READ

Retry after the consistency window

4
aws sts get-caller-identity
READ

Confirm the session now resolves as expected

Prevention

  • Build a small settle delay into pipeline steps that create roles then use them.
  • Do not cache credentials longer than the IAM change window in long-lived workers.
  • Pre-create roles ahead of releases that reference them.

Related runbooks

Same stack, same failure family — worth a skim.

sts:AssumeRole failure — cross-account or service role switch deniedhigh

App or pipeline fails with 'not authorized to perform sts:AssumeRole'

AWSIntermediate3 causes
Open runbook
AccessDenied on S3 from an EC2 instancehigh

aws s3 ls s3://<BUCKET>/ fails with AccessDenied on the instance

AWSFoundation3 causes
Open runbook
Lambda execution role not authorized — invoke failshigh

Invoke returns 403 'The provided execution role does not have permissions'

AWSFoundation3 causes
Open runbook

Commands marked READ CHANGE DESTRUCTIVE — never run DESTRUCTIVE commands against production data you cannot restore. Copy → verify → execute.