AWS IAM Cheatsheet and Policy JSON Inspector

The policy language version. Always set it to "2012-10-17" — it is not a date you pick, it unlocks policy variables and the modern grammar.

⚠ Gotcha: Omitting Version defaults to the legacy "2008-10-17" which silently disables policy variables like ${aws:username}.

"Version": "2012-10-17"

The array (or single object) holding one or more permission statements. Everything else lives inside it.

"Statement": [ { "Effect": "Allow", "Action": "s3:GetObject", "Resource": "*" } ]

Either "Allow" or "Deny" for the statement. Deny always overrides any Allow that matches the same request.

"Effect": "Allow"

"Effect": "Deny"

The list of API operations the statement covers, in service:Operation form. Supports wildcards.

⚠ Gotcha: Action matching is case-insensitive, but stick to the documented casing (s3:GetObject) so policies stay greppable.

"Action": "s3:GetObject"

"Action": ["s3:GetObject", "s3:PutObject"]

"Action": "s3:Get*"

Match every action EXCEPT the ones listed. Powerful and dangerous — with Effect Allow it grants everything else.

⚠ Gotcha: A common breach pattern: "Allow" + NotAction iam:* on Resource "*" hands out near-admin while looking restrictive.

"Effect": "Deny", "NotAction": "s3:*", "Resource": "*"

The ARN(s) the statement applies to. Required in identity-based policies; "*" means every resource of the action.

"Resource": "arn:aws:s3:::my-bucket/*"

"Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"]

Match every resource EXCEPT the listed ARNs. Same blast-radius warning as NotAction.

"Effect": "Deny", "Action": "s3:DeleteObject", "NotResource": "arn:aws:s3:::archive/*"

WHO the statement applies to. Only valid in resource-based and trust policies, never in identity-based policies.

⚠ Gotcha: Putting Principal in a user/role-attached policy is a silent no-op — IAM ignores it. Use a resource policy instead.

"Principal": { "AWS": "arn:aws:iam::123456789012:root" }

"Principal": { "Service": "lambda.amazonaws.com" }

"Principal": "*"

Optional block of key/operator/value tests that must all pass for the statement to take effect.

"Condition": { "StringEquals": { "aws:PrincipalTag/team": "data" } }

An optional statement identifier (label). Purely for your own readability and for targeting a statement in a policy diff.

⚠ Gotcha: Sid must be unique within a policy. In resource policies it is also how you reference a statement in API calls.

"Sid": "AllowReadOnlyBucketAccess"

Use * and ? inside an action: s3:* (all S3), s3:Get* (all reads), s3:Describe?able (single char). Scope before you ship.

"Action": "s3:*"

"Action": "ec2:Describe*"

"Action": "*"

Wildcards work inside an ARN too: arn:aws:s3:::logs-*/* matches every object in every logs- prefixed bucket.

"Resource": "arn:aws:s3:::logs-*/*"

"Resource": "arn:aws:dynamodb:*:123456789012:table/app-*"

arn:partition:service:region:account-id:resource. Global services (IAM, S3) leave region empty; the account-id is your 12-digit number.

⚠ Gotcha: partition is aws for commercial, aws-cn for China regions, aws-us-gov for GovCloud. Copy-pasting a us-east-1 ARN into China silently fails.

arn:aws:service:region:account-id:resource-type/resource-id

Identifies an IAM user. Region is empty because IAM is global; path (here /) is part of the ARN.

arn:aws:iam::123456789012:user/lilei

arn:aws:iam::123456789012:user/eng/backend/lilei

Identifies an IAM role — what you reference in a trust policy or assume-role call.

arn:aws:iam::123456789012:role/MyAppRole

arn:aws:iam::123456789012:role/aws-service-role/...

After assume-role your identity is an sts assumed-role ARN, NOT the role ARN — the format differs and trips up Condition matching.

⚠ Gotcha: To match an assumed session in a Condition use ArnLike with arn:aws:sts::ACCT:assumed-role/RoleName/*, not the iam role ARN.

arn:aws:sts::123456789012:assumed-role/MyAppRole/session-name

The bucket and its objects are TWO different ARNs. Bucket-level actions (ListBucket) need the bucket ARN; object actions need the /* ARN.

⚠ Gotcha: The #1 S3 policy bug: granting s3:GetObject on arn:aws:s3:::bucket (no /*) — it matches nothing.

arn:aws:s3:::my-bucket

arn:aws:s3:::my-bucket/*

arn:aws:s3:::my-bucket/logs/2026/*

Identifies a Lambda function; appending :version or :alias pins a specific deploy target.

arn:aws:lambda:us-east-1:123456789012:function:my-fn

arn:aws:lambda:us-east-1:123456789012:function:my-fn:prod

arn:aws:iam::ACCT:root means "the whole account". In a trust policy it delegates trust to the account so its IAM admins can grant access.

⚠ Gotcha: root in a Principal does NOT mean the root user — it means "any principal in that account that is also granted by an IAM policy".

"Principal": { "AWS": "arn:aws:iam::123456789012:root" }

AWS services act through a service principal like ec2.amazonaws.com — used in trust policies so the service can assume a role.

"Principal": { "Service": "ec2.amazonaws.com" }

"Principal": { "Service": "lambda.amazonaws.com" }

Use ArnLike or wildcards to match a family of ARNs, e.g. every function under a prefix or every role in an account.

arn:aws:lambda:*:123456789012:function:billing-*

arn:aws:iam::123456789012:role/ci-*

Exact, case-sensitive string match (or its negation) on a condition key. The workhorse operator for tag and value checks.

"StringEquals": { "aws:PrincipalTag/team": "data" }

"StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }

String match that allows * and ? wildcards — use this, not StringEquals, when the value contains a wildcard.

⚠ Gotcha: StringEquals does NOT expand wildcards. "StringEquals: prefix*" matches the literal string "prefix*" and almost always fails.

"StringLike": { "s3:prefix": "home/${aws:username}/*" }

Compare a condition key against an ARN pattern. ArnLike allows wildcards; prefer it for aws:SourceArn checks.

"ArnLike": { "aws:SourceArn": "arn:aws:s3:::my-bucket" }

"ArnLike": { "aws:PrincipalArn": "arn:aws:iam::*:role/ci-*" }

True/false test. The classic use is requiring MFA or requiring requests over TLS.

"Bool": { "aws:MultiFactorAuthPresent": "true" }

"Bool": { "aws:SecureTransport": "false" }

Restrict by source CIDR using the aws:SourceIp key. Only meaningful for requests not routed through a VPC endpoint.

⚠ Gotcha: aws:SourceIp is the PUBLIC IP. From inside a VPC via a gateway/interface endpoint the request has no public IP and this condition denies it.

"IpAddress": { "aws:SourceIp": ["203.0.113.0/24", "198.51.100.42/32"] }

Time-bound a statement using ISO-8601 UTC timestamps against aws:CurrentTime — handy for temporary contractor access.

"DateLessThan": { "aws:CurrentTime": "2026-12-31T23:59:59Z" }

Numeric comparisons, e.g. capping a requested S3 multipart size or an STS session duration.

"NumericLessThanEquals": { "s3:max-keys": "100" }

Test whether a key is present (false) or absent (true) in the request. Use it to require that a tag was supplied at all.

"Null": { "aws:RequestTag/project": "false" }

Attribute-based access control (ABAC): grant access only when the caller tag matches the resource tag — scales without per-resource policies.

"StringEquals": { "aws:ResourceTag/team": "${aws:PrincipalTag/team}" }

Control tagging itself: force which tag keys may be set on create, and which values are allowed.

"StringEquals": { "aws:RequestTag/env": ["dev", "staging", "prod"] }

"ForAllValues:StringEquals": { "aws:TagKeys": ["env", "owner"] }

Restrict a resource policy to principals from your AWS Organization — much safer than enumerating account IDs.

"StringEquals": { "aws:PrincipalOrgID": "o-abc123xyz" }

Set operators for multi-valued keys. ForAllValues: every value in the request is in your list. ForAnyValue: at least one is.

⚠ Gotcha: ForAllValues also passes when the key is ABSENT — pair it with a Null check if presence is mandatory.

"ForAllValues:StringEquals": { "dynamodb:Attributes": ["id", "name"] }

Append IfExists so a condition only applies when the key is present in the request, and is skipped otherwise.

"Bool": { "aws:MultiFactorAuthPresentIfExists": "true" }

"StringEqualsIfExists": { "ec2:InstanceType": "t3.micro" }

Print the account, ARN, and user ID for the current credentials. The "who am I in IAM" check — run it before anything destructive.

aws sts get-caller-identity

aws sts get-caller-identity --query Arn --output text

Return details for the calling IAM user (or a named one): ARN, user ID, path, creation date.

⚠ Gotcha: Fails if you are authenticated as a ROLE, not a user — assumed-role sessions have no IAM user. Use get-caller-identity instead.

aws iam get-user

aws iam get-user --user-name lilei

List every IAM user in the account with ARN and creation date.

aws iam list-users

aws iam list-users --query "Users[].UserName" --output text

Create a role with a trust policy (the JSON that says WHO may assume it). The trust policy is mandatory.

⚠ Gotcha: A wrong principal ARN or missing condition in trust.json is the most common "AccessDenied when assuming role" root cause.

aws iam create-role --role-name MyAppRole --assume-role-policy-document file://trust.json

Attach a managed policy (AWS or customer) to a role. Managed policies are reusable and versioned.

aws iam attach-role-policy --role-name MyAppRole --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

aws iam list-attached-role-policies --role-name MyAppRole

Embed an INLINE policy directly on a role. Inline policies have a 1:1 lifecycle with the role — deleted with it.

⚠ Gotcha: Inline policies do not show up in list-attached-role-policies. Use list-role-policies to find them.

aws iam put-role-policy --role-name MyAppRole --policy-name s3-inline --policy-document file://inline.json

Create a reusable customer-managed policy from a JSON document so the same permissions attach to many principals.

⚠ Gotcha: Each managed policy keeps at most 5 versions. create-policy-version past 5 fails — delete an old one or set --set-as-default.

aws iam create-policy --policy-name S3ReadMyBucket --policy-document file://policy.json

Test whether a user/role WOULD be allowed an action on a resource without actually performing it. The IAM debugger.

aws iam simulate-principal-policy --policy-source-arn arn:aws:iam::123456789012:role/MyAppRole --action-names s3:GetObject --resource-arns arn:aws:s3:::my-bucket/key

List the MANAGED policies attached to a role. Pair with list-role-policies for the inline ones.

aws iam list-attached-role-policies --role-name MyAppRole

aws iam list-role-policies --role-name MyAppRole

Generate a new long-lived access key (AKID + secret) for an IAM user. The secret is shown ONCE — save it now.

⚠ Gotcha: Prefer SSO or assume-role over long-lived keys. If you must, rotate every 90 days and delete the old key.

aws iam create-access-key --user-name lilei

aws iam delete-access-key --user-name lilei --access-key-id AKIA...

List a user’s access keys (ID, status, creation date) — metadata only, never the secret.

⚠ Gotcha: A user can hold at most TWO keys. That limit exists so you can rotate: create new, deploy, delete old.

aws iam list-access-keys --user-name lilei

Set an access key Active or Inactive without deleting it — the safe first step when rotating or investigating a leak.

aws iam update-access-key --user-name lilei --access-key-id AKIA... --status Inactive

Show when/where a key was last used (date, region, service). The "is this key dead?" check before deleting.

aws iam get-access-key-last-used --access-key-id AKIAIOSFODNN7EXAMPLE

Generate, then get-credential-report, a CSV of every user’s key age, MFA status, and last-used data. Audit gold.

⚠ Gotcha: Generation is async — call generate, wait for COMPLETE, then get to read the base64 CSV. Reports cache for 4 hours.

aws iam generate-credential-report

aws iam get-credential-report --query Content --output text | base64 --decode

Dump the entire IAM model — every user, group, role, policy, and attachment — in one JSON blob for offline audit.

⚠ Gotcha: Huge on real accounts. Pipe to a file and analyze with jq rather than scrolling the terminal.

aws iam get-account-authorization-details > iam-dump.json

aws iam get-account-authorization-details --filter Role

Attach a permissions boundary to a role — a ceiling that caps the effective permissions no matter what policies are attached.

aws iam put-role-permissions-boundary --role-name DevRole --permissions-boundary arn:aws:iam::aws:policy/PowerUserAccess

Attach tags to a role or user — the foundation of ABAC and of cost/ownership tracking.

aws iam tag-role --role-name MyAppRole --tags Key=team,Value=data

aws iam tag-user --user-name lilei --tags Key=owner,Value=lilei

List all roles in the account; use --path-prefix to skip the noisy service-linked roles.

aws iam list-roles --query "Roles[].RoleName" --output text

aws iam list-roles --path-prefix /aws-service-role/

Read the actual JSON document of a managed policy. You must first get-policy to find the DefaultVersionId.

aws iam get-policy --policy-arn arn:aws:iam::123:policy/S3ReadMyBucket

aws iam get-policy-version --policy-arn arn:aws:iam::123:policy/S3ReadMyBucket --version-id v3

Full access to every service and action (Allow "*" on "*"). The keys to the kingdom — grant to almost no one.

⚠ Gotcha: Even admins should assume an admin ROLE with MFA rather than carry AdministratorAccess on a daily-use user.

arn:aws:iam::aws:policy/AdministratorAccess

Full access to everything EXCEPT IAM and Organizations. The usual grant for developers who should not manage users/roles.

arn:aws:iam::aws:policy/PowerUserAccess

Read/list/describe across nearly all services. Good default for auditors and dashboards — but it CAN read secrets and object data.

⚠ Gotcha: ReadOnlyAccess includes s3:GetObject and secretsmanager:GetSecretValue. For "metadata only" use ViewOnlyAccess instead.

arn:aws:iam::aws:policy/ReadOnlyAccess

List and describe resource metadata only — no GetObject, no secret reads. Safer than ReadOnlyAccess for broad visibility.

arn:aws:iam::aws:policy/job-function/ViewOnlyAccess

Read-only access to configuration metadata across services — the policy auditors and tools like Prowler/ScoutSuite expect.

arn:aws:iam::aws:policy/SecurityAudit

Manage (or just read) IAM users, roles, and policies. IAMFullAccess effectively means privilege escalation — treat as admin.

arn:aws:iam::aws:policy/IAMFullAccess

arn:aws:iam::aws:policy/IAMReadOnlyAccess

Service-scoped S3 access. FullAccess is broad (every bucket); prefer a custom policy scoped to specific bucket ARNs.

arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

arn:aws:iam::aws:policy/AmazonS3FullAccess

Full EC2 plus the related VPC, ELB, CloudWatch, and Auto Scaling actions needed to actually run instances.

arn:aws:iam::aws:policy/AmazonEC2FullAccess

Manage Lambda functions plus the supporting CloudWatch Logs, S3, and event-source actions.

arn:aws:iam::aws:policy/AWSLambda_FullAccess

AWS ships role-aligned managed policies under arn:aws:iam::aws:policy/job-function/ — Billing, NetworkAdministrator, DatabaseAdministrator, etc.

arn:aws:iam::aws:policy/job-function/Billing

arn:aws:iam::aws:policy/job-function/NetworkAdministrator

A role’s trust policy is a resource policy with Action sts:AssumeRole and a Principal saying who may assume it.

{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:root" }, "Action": "sts:AssumeRole" }

Let EC2 instances assume the role via an instance profile by trusting ec2.amazonaws.com.

{ "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" }

The execution role every Lambda needs — trust lambda.amazonaws.com so the service can run your function.

{ "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "sts:AssumeRole" }

Trust another account’s root (or a specific role) so its principals can assume this role — the standard cross-account access pattern.

⚠ Gotcha: Both sides are required: the trust policy here AND an sts:AssumeRole grant on the caller’s side.

{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::999988887777:role/CiDeployer" }, "Action": "sts:AssumeRole" }

For third-party (SaaS) cross-account roles, require a Condition on sts:ExternalId so a vendor cannot be tricked into accessing the wrong customer.

"Condition": { "StringEquals": { "sts:ExternalId": "unique-customer-token-abc123" } }

Federate CI without long-lived keys: trust an OIDC provider and AssumeRoleWithWebIdentity, scoping by repo/branch via the token sub claim.

"Condition": { "StringLike": { "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:ref:refs/heads/main" } }

Add a Bool condition on aws:MultiFactorAuthPresent to the trust policy so the role can only be assumed by an MFA-authenticated session.

"Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }

Get temporary credentials for a role from the CLI. Returns an AKID, secret, AND a session token — export all three.

⚠ Gotcha: Forgetting AWS_SESSION_TOKEN is the #1 assume-role failure. Default session is 1h; role chaining caps at 1h regardless of --duration-seconds.

aws sts assume-role --role-arn arn:aws:iam::123456789012:role/MyAppRole --role-session-name lilei

Every request starts implicitly denied. Access requires an explicit Allow somewhere in the applicable policies.

No matching Allow  →  implicit deny  →  AccessDenied

A single explicit Deny in ANY applicable policy overrides every Allow. This is how guardrails are enforced.

Allow s3:* + Deny s3:DeleteObject  →  DeleteObject denied, rest allowed

Organization-level guardrails. An SCP can only RESTRICT — it never grants. If the SCP does not allow it, no IAM policy can either.

⚠ Gotcha: SCPs do not apply to the management account or to service-linked roles — a frequent "why isn’t my SCP working" surprise.

SCP denies region eu-west-1  →  every account in the OU is blocked there

A managed policy set as a ceiling on a user/role. The effective permission is the INTERSECTION of the identity policy and the boundary.

Identity allows s3:* + ec2:*; boundary allows s3:*  →  only s3:* is effective

Within ONE account, access is granted if the identity policy OR the resource policy allows it (and nothing denies). Either side can authorize.

No identity Allow, but bucket policy allows the user  →  access granted

Across accounts, BOTH the resource policy (or trust) in the target account AND an IAM policy in the caller’s account must allow it.

⚠ Gotcha: This asymmetry vs same-account union is the most common cross-account AccessDenied cause.

Bucket policy allows acct B, but B’s IAM has no Allow  →  denied

Launching an EC2/Lambda/ECS task with a role requires iam:PassRole on that role. Granting PassRole on "*" lets a user attach an admin role to compute they control — full takeover.

⚠ Gotcha: Always scope PassRole to specific role ARNs and add a Condition on iam:PassedToService.

"Action": "iam:PassRole", "Resource": "arn:aws:iam::123:role/app-task-role", "Condition": { "StringEquals": { "iam:PassedToService": "ecs-tasks.amazonaws.com" } }

A statement with Allow on Action "*" and Resource "*" is AdministratorAccess no matter what it is named. Wildcards hide the blast radius.

"Effect": "Allow", "Action": "*", "Resource": "*"

Managed policies are reusable, versioned, and listed via list-attached-*. Inline policies are 1:1 with the principal, unlisted there, and easy to lose.

⚠ Gotcha: A "missing permission" you cannot find is often hiding in an inline policy. Check list-role-policies / list-user-policies.

aws iam list-role-policies --role-name MyAppRole

Managed policy doc ≤ 6,144 chars; inline policy per user/role/group ≤ 2,048/10,240 chars depending on type. Whitespace counts.

⚠ Gotcha: Hitting the limit means splitting into multiple managed policies (up to 10 attachable per principal) or compacting whitespace.

Managed policy max: 6144 characters

A new key, role, or policy edit can take a few seconds to propagate globally. A create-then-use script may briefly 403.

⚠ Gotcha: Add a retry-with-backoff after create-role before assume-role, rather than assuming the change is instant.

create-role → (wait/retry) → assume-role

A committed AKID is scraped by bots within minutes and abused for crypto mining across regions. Delete the key FIRST; history rewrite alone does not help.

⚠ Gotcha: iam delete-access-key immediately, audit CloudTrail for the last 24h, then rotate every secret in that account.

aws iam update-access-key --access-key-id AKIA... --status Inactive --user-name lilei

aws iam delete-access-key --access-key-id AKIA... --user-name lilei

Allow + NotAction grants everything you did NOT list. People reach for it to "block one thing" and accidentally open the rest.

⚠ Gotcha: To block specific actions use an explicit Deny + Action, never Allow + NotAction.

BAD: "Effect": "Allow", "NotAction": "s3:DeleteObject", "Resource": "*"

If a condition value contains * or ?, you must use StringLike. StringEquals treats them as literal characters and the condition silently never matches.

WRONG: "StringEquals": { "s3:prefix": "home/*" }  →  RIGHT: "StringLike"

aws:userid and the caller ARN of an assumed role differ from the role ARN. Match sessions with ArnLike on the assumed-role ARN, not the iam role ARN.

"ArnLike": { "aws:PrincipalArn": "arn:aws:sts::123:assumed-role/MyAppRole/*" }

Use IAM Access Analyzer "last accessed" / generate-service-last-accessed-details to right-size a policy from real usage instead of guessing.

aws iam generate-service-last-accessed-details --arn arn:aws:iam::123:role/MyAppRole