Imagine you just created an AWS account. You have one set of credentials — the root account. Your team grows: developers, data scientists, DevOps engineers, QA testers. You share the root credentials. One developer accidentally deletes a production database. Another downloads customer data to their laptop. There is no log of who did what. There is no way to restrict who can do what. You are one mistake away from catastrophe.

IAM exists to solve this exact problem. AWS Identity and Access Management gives you a way to create separate identities for every person and every service, grant each one exactly the permissions they need — nothing more — and audit every single action with a full trail.

IAM is the AWS service that answers two fundamental security questions for every single action taken in your AWS account:

These two concepts are frequently conflated but represent completely different phases. IAM handles both, in strict sequence — authorization never runs if authentication fails.

Every IAM permission statement is built on four questions. Together, they define every access boundary in AWS:

The best mental model for IAM is a large corporate office building with an advanced security system. Every element maps precisely to an IAM concept:

Most AWS services are regional — an RDS database in us-east-1 doesn't exist in eu-west-1. IAM is fundamentally different: it is global.

When a developer runs aws s3 ls s3://my-bucket, here is exactly what AWS does, in order:

1. Request arrives at AWS endpoint (signed)

   The CLI signs the request using the configured credentials (access key ID + secret access key → HMAC-SHA256 / SigV4 signature). The signed request is sent to the S3 regional endpoint.
2. IAM verifies the signature — Authentication

   AWS extracts the access key ID, finds the corresponding secret key in IAM, and re-derives the expected signature. Match → identity confirmed. No match → 401 Unauthorized. Stops here. Authorization never runs.
3. IAM determines the principal's full context

   Who is this principal? User, role, federated identity? Which account? What type of credentials (permanent, temporary)? What session policies? IAM collects all applicable policies: identity-based, resource-based, boundaries, SCPs.
4. IAM evaluates all policies — Authorization

   Is there an explicit Deny anywhere? (If yes → 403, stop). Is there an explicit Allow in any applicable policy? (If yes → proceed). Neither? → Default Deny → 403. All conditions (IP, MFA, time, region) are also evaluated here.
5. Decision rendered — Action executes or is blocked

   Allowed: S3 service executes ListBucket and returns the response. Denied: AccessDenied (403) returned. The action never executes. CloudTrail logs the attempt and outcome either way.

IAM has four core entity types. Mastering how they relate — and when to use each — is the foundation of every AWS security design. The mental mistake most beginners make is treating Users and Roles as interchangeable. They are not.

The root account is created when you first sign up for AWS using an email + password. It has unrestricted, irrevocable access to everything in the account — it cannot be limited by any IAM policy, permission boundary, or SCP.

Groups solve a management problem: when you have 50 developers and need to give all of them the same permissions, you don't attach 50 individual policies. You create a Developers group, attach one policy to it, and add all 50 users to it. Change the policy once — all 50 users get the update instantly.

Roles are the most important IAM entity for modern AWS architecture. Any time a service, application, or external identity needs to act in AWS, it should use a role — not an IAM user with hardcoded keys.

A role has two policy layers that must both allow the interaction:

1. Principal requests temporary credentials

   An EC2 instance (or AWS service, user, or external identity) calls sts:AssumeRole with the role ARN. If it's an EC2 instance with an instance profile, this happens automatically — the EC2 metadata service handles it transparently for the SDK.
2. STS validates the Trust Policy

   AWS Security Token Service (STS) checks the role's Trust Policy. Is the requesting principal listed as a trusted entity? If not → denied. If yes → proceed. Conditions in the trust policy are also evaluated (e.g., require MFA, require specific ExternalId for cross-account).
3. STS issues temporary credentials

   STS returns three values: AccessKeyId, SecretAccessKey, and SessionToken. These expire after the configured duration (default 1 hour, max 12 hours for most roles). The caller must use all three together — the session token proves the credentials are temporary.
4. Caller uses temporary credentials

   The caller signs requests with the temporary creds. AWS IAM validates the session token and evaluates the role's permission policies. The original caller's identity is not used — they are now acting AS the role. All CloudTrail logs show the role ARN + the original principal (AssumedRoleUser).
5. Credentials expire — automatically revoked

   When the TTL expires, the credentials become invalid. No manual cleanup needed. If the role's policies change, new sessions get new permissions. To revoke active sessions before expiry: use Revoke Sessions in the IAM console (adds an explicit deny policy with a time condition) or update the permission policy.

An IAM policy is a JSON document that defines permissions. It specifies what actions are allowed or denied, on what resources, under what conditions. Policies are the fundamental unit of authorization in AWS — without a policy granting access, nothing is allowed.

A policy document contains a Version and a list of Statement objects. Each statement is one permission rule:

When a principal in Account A tries to access a resource in Account B, the interaction of policy types determines access. This is where most cross-account errors happen:

Conditions are the most powerful (and most underused) part of IAM policies. They allow context-aware permissions — the same identity can have different effective access depending on how and where they connect.

NotAction and NotResource are powerful but dangerous keywords. They are often in exam questions because they behave counterintuitively.

These condition keys are available in every AWS policy regardless of service. They appear constantly on AWS certification exams.

SCPs are typically used as deny lists (deny specific actions). But the allow list strategy is more restrictive and is a common exam pattern:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "s3:Get*",
      "s3:List*",
      "cloudwatch:Get*",
      "cloudwatch:List*"
    ],
    "Resource": "*"
  }]
}

With only this Allow statement in the SCP, all other actions are implicitly denied — even ec2:DescribeInstances. This locks accounts to an exact set of services.

The most common real-world use case for permission boundaries:

Access: https://policysim.aws.amazon.com — separate from the main AWS Console.

IAM Users solve human access. IAM Roles solve everything else: service-to-service access, temporary elevated access, federation, and cross-account operations. A role is an identity you become temporarily - not one you permanently own.

1. Caller requests role assumption

   Caller invokes STS API such as AssumeRole, AssumeRoleWithSAML, or AssumeRoleWithWebIdentity.
2. Trust policy evaluated first

   If caller principal and conditions do not match trust policy, request fails immediately and no credentials are issued.
3. STS returns credential triplet

   Session credentials include AccessKeyId, SecretAccessKey, and SessionToken, plus expiration timestamp.
4. APIs execute with role identity

   Requests are signed with temporary credentials. IAM evaluates role permissions (and other policy layers) for every API action.
5. Session expires automatically

   After TTL, credentials are invalid by design. This is why roles are safer than long-lived user keys.

Both sides must be configured correctly. Missing either side = AccessDenied.

Every AWS API call goes through IAM's permission evaluation engine. Understanding this decision logic is the single most important skill for IAM mastery. The exam tests it heavily. Misunderstanding one step leads to accidental over-permissioning or mysterious access denials.

When an API request arrives, IAM evaluates it through this exact sequence. The order matters:

1. Step 1: Start with implicit DENY

   Every request begins in DENY state. This is not a policy decision - it is the system default. Nothing is allowed until explicitly permitted. "Silence = Deny."
2. Step 2: Evaluate all applicable policies

   IAM collects all policies that apply: identity-based, resource-based, SCPs, permission boundaries, and session policies. All are evaluated together - not sequentially.
3. Step 3: Check for explicit DENY

   If ANY policy has an explicit Deny that matches the action, resource, and conditions - evaluation stops immediately. Result: DENIED. No further checks happen.
4. Step 4: Check Organizations SCP (if applicable)

   If the account is in an AWS Organization, the SCP must allow the action. SCPs cannot grant access - they only filter. If SCP does not explicitly allow it, result: DENIED (implicit deny from SCP).
5. Step 5: Check Permission Boundary (if set)

   If a permission boundary is attached to the identity, it must allow the action. Like SCPs, boundaries filter - they never grant. Not in boundary = DENIED.
6. Step 6: Check Session Policy (if present)

   If session policies were passed during AssumeRole or GetFederationToken, the action must be in the session policy. If not = DENIED.
7. Step 7: Check for explicit ALLOW

   Finally, check identity-based and/or resource-based policies for an Allow. Same-account: either one can grant. Cross-account: both must grant. If no Allow found = DENIED (implicit deny).

Use this table to instantly determine the final access decision for any scenario:

The most important security concept in IAM: grant only the minimum permissions required to perform a specific task. Nothing more. Start with zero access and add only what is needed. Never start with full access and try to remove.

One of the most powerful least-privilege tools: generate a policy from actual usage instead of guessing what permissions are needed.

STS is the engine behind all temporary credentials in AWS. Every time a role is assumed, a federation token is generated, or a session is created, STS is the service doing it. Understanding STS APIs is essential for advanced IAM work.

Federation allows external identities to access AWS without creating IAM users. This is how enterprises with thousands of employees manage AWS access without 5,000 IAM users.

A newer feature (2022) that extends IAM roles to workloads outside AWS — on-premises servers, Kubernetes clusters, IoT devices.

Workflow: Register CA → Create Trust Anchor → Create Profile (maps to role) → Workload presents cert → Gets temp creds via rolesanywhere:CreateSession

Not strictly IAM core, but frequently tested alongside IAM on AWS certification exams: