How do IAM roles and policies work in depth?

Question

Accepted Answer

Beyond basic IAM, understanding **roles** (assumed identities), **policy types and evaluation** (how permissions are determined), and patterns like **cross-account access** and **service roles** is important for secure, well-architected AWS access management.

## Roles in depth — who assumes what

```text
A ROLE has TWO key policies:
  TRUST POLICY → WHO can assume the role (which principals: a service, account, user)
  PERMISSION POLICIES → WHAT the role can do once assumed
Use cases:
  → SERVICE roles — an EC2/Lambda assumes a role to access AWS (no embedded keys)
  → CROSS-ACCOUNT — account B's role trusts account A → A's users assume it (controlled access)
  → FEDERATION/SSO — external identities assume roles (temporary credentials)
→ Roles give TEMPORARY credentials (auto-rotated) — far safer than long-lived keys.
```

## Policy types

```text
IDENTITY-BASED → attached to users/groups/roles (what THEY can do)
RESOURCE-BASED → attached to a resource (e.g. an S3 bucket policy: who can access IT)
PERMISSION BOUNDARIES → a max-permissions limit on an identity (cap delegated permissions)
SCPs (Service Control Policies) → org-wide guardrails (limit what accounts can do)
→ Effective permissions = the combination, with rules for how they interact.
```

## Policy evaluation (how access is decided)

```text
1. Explicit DENY anywhere → DENIED (deny always wins)
2. Else, an explicit ALLOW (from identity/resource policy) within bounds → ALLOWED
3. Else (no allow) → DENIED (default deny)
→ Default deny; explicit deny overrides any allow; you need an allow + no deny + within
  any boundaries/SCPs.
```

## Why it matters

Understanding IAM roles and policies in depth is important for **secure, well-architected AWS access management**, so it's valuable knowledge beyond IAM basics.

Understanding **roles in depth** — their **trust policy** (who can assume the role) and **permission policies** (what it can do) — is key to the most important secure access patterns: **service roles** (letting EC2 instances and Lambda functions access AWS resources via temporary, auto-rotated credentials instead of embedded long-lived keys — a critical security practice), **cross-account access** (controlled access between AWS accounts via role assumption), and **federation/SSO** (external identities assuming roles for temporary access).

Roles providing temporary credentials rather than long-lived keys is a foundational security improvement.

Understanding the **policy types** — identity-based (what users/roles can do), resource-based (like S3 bucket policies controlling who can access a resource), permission boundaries (capping delegated permissions), and SCPs (organization-wide guardrails) — is necessary for sophisticated access control in real organizations.

Understanding **policy evaluation logic** (default deny; an explicit deny anywhere always wins; you need an explicit allow within any boundaries and no deny) is essential for reasoning correctly about what permissions actually result — a common source of confusion where misunderstanding leads to either overly-broad access (security risk) or unexpected denials (operational friction).

Since secure access management is critical to AWS security (and IAM misconfigurations are a leading cause of breaches), and since understanding roles deeply (for secure credential-free access patterns), policy types (for layered control), and policy evaluation (for correct reasoning about permissions) is necessary for well-architected, secure access, understanding IAM roles and policies in depth is valuable, practically-important AWS knowledge for security — building on IAM basics to enable the secure access patterns and correct permission reasoning that professional AWS security requires, an important area where depth of understanding directly affects security posture.