IAM — Master This

What we're doing: Read a real policy statement as the four elements it is built from.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": "arn:aws:s3:::reports-bucket/*",
      "Condition": {
        "IpAddress": { "aws:SourceIp": "203.0.113.0/24" }
      }
    }
  ]
}

5

Effect is Allow — IAM defaults to deny, so this statement exists to open a specific door.

6

Action lists exactly two API operations — not a wildcard, not "all S3 actions."

7

Resource scopes to one bucket by ARN, not every bucket in the account.

9

Condition narrows further: even a matching identity/action/resource is denied outside this IP range.

Why this works: Reading any IAM policy is the same four-question exercise: who, what, on which resource, under what condition. A statement missing Condition simply has no extra restriction — it is not a different kind of policy.

What we're doing: See a role built from two different policy types working together: a trust policy controlling who can assume it, and an identity-based policy controlling what it can do once assumed.

// 1. Trust policy — who may assume this role
{
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": { "StringEquals": { "sts:ExternalId": "deploy-2026" } }
  }]
}

// 2. Identity-based policy — what it can do once assumed
{
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:PutObject"],
    "Resource": "arn:aws:s3:::deploy-artifacts/*"
  }]
}

3

The trust policy is attached to the role, controlling who may call AssumeRole on it — nothing about S3 yet.

12

The identity-based policy is attached to the same role, controlling what it can do after someone has assumed it.

Why this works: A role always has exactly one trust policy (who may assume it) and any number of identity-based policies (what it can do). Confusing the two is the single most common source of "AccessDenied when assuming a role that clearly has S3 permissions."

What we're doing: Compare a long-lived IAM user credential to the temporary credentials a role assumption returns.

# IAM user: a long-lived access key, valid until manually rotated or deleted
$ aws configure list
access_key     AKIAIOSFODNN7EXAMPLE     shared-credentials-file

# Role assumption: temporary credentials with a built-in expiry
$ aws sts assume-role --role-arn arn:aws:iam::111122223333:role/ci-deploy \
    --role-session-name build-4821 --query Credentials
{
  "AccessKeyId": "ASIAIOSFODNN7EXAMPLE",
  "Expiration": "2026-08-21T15:42:00Z"
}

2

The IAM user access key has no expiry field — it stays valid until someone acts to rotate or delete it.

6

The assumed-role credential starts with ASIA (not AKIA) and always carries an Expiration timestamp.

Why this works: The access-key prefix is a real, visible signal: AKIA marks a long-lived IAM user key, ASIA marks temporary credentials from a role assumption — useful for spotting a long-lived key where a role should have been used instead.

What we're doing: Trace a request through both the default-deny rule and an explicit deny that overrides an otherwise-valid allow.

// Identity-based policy attached to the role: broad read access
{
  "Statement": [{ "Effect": "Allow", "Action": "s3:*", "Resource": "*" }]
}

// SCP attached at the OU level: blocks deletion everywhere, no exceptions
{
  "Statement": [{
    "Effect": "Deny",
    "Action": "s3:DeleteObject",
    "Resource": "*"
  }]
}

3

This Allow is broad — s3:* on every resource — and would normally permit deletes too.

12

This Deny is narrower in scope (just DeleteObject) but wins anyway: an explicit Deny always overrides any Allow, from any policy source.

Why this works: The role can still read and write S3 objects freely — only DeleteObject is blocked, and only because of the explicit Deny, not because the identity-based policy changed at all.

What we're doing: Compare a wildcard Resource ARN against an exact one, and see what each actually matches.

// Wildcard: matches every object in every bucket the account owns
{ "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::*/*" }

// Exact: matches only objects under this one prefix, in this one bucket
{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports-bucket/2026/*"
}

2

Two wildcards — bucket name and object key are both "*" — so this matches literally every object in the account.

7

One wildcard, scoped to a single bucket and a single year-prefix — the ARN itself does the narrowing, no extra Condition needed.

Why this works: A wildcard's position matters as much as its presence — "*/*" and "reports-bucket/2026/*" are both technically wildcards, but they authorize wildly different amounts of access.

What we're doing: Create an analyzer and read back a finding — the shape every Access Analyzer capability shares: create once, review findings on a schedule.

# 1. Create the analyzer once (account- or organization-scoped)
$ aws accessanalyzer create-analyzer --analyzer-name prod-external --type ACCOUNT

# 2. Review findings — repeated, on a schedule, not a one-time check
$ aws accessanalyzer list-findings --analyzer-arn arn:aws:access-analyzer:eu-west-1:111122223333:analyzer/prod-external
{
  "findings": [
    { "resource": "arn:aws:s3:::reports-bucket", "isPublic": true, "action": ["s3:GetObject"] }
  ]
}

2

The analyzer is created once and then runs continuously — it is not a one-off scan.

6

Each finding names the exact resource, whether it is public, and which actions are exposed — specific enough to act on directly.

Why this works: Access Analyzer's value is in the schedule, not the single check — a bucket policy edited next month to add public access generates a fresh finding automatically, without anyone remembering to re-run a scan.