Every single AWS API call — regardless of which service it targets — passes through the same centralized policy evaluation logic, and understanding that evaluation logic’s precise rules is the single highest-leverage thing an advanced IAM practitioner can know.

At the core of IAM sits an evaluation engine that, for every request, gathers every policy potentially relevant to that request — identity-based policies attached to the calling principal, resource-based policies attached to the target resource, any permission boundary set on the principal, any Service Control Policies applying to the account, and any session policies passed during role assumption — and evaluates all of them together according to a fixed, deterministic precedence order rather than any single policy “winning” in isolation.

Two default states matter enormously here. First, everything is implicitly denied by default — a principal with no applicable allow statement anywhere is denied, not by an explicit rule but simply by the absence of a permit. Second, an explicit deny statement anywhere in any applicable policy overrides every other allow, no matter how many other policies grant the permission — this is the single most important rule in the entire IAM model, and it is the direct mechanism behind both permission boundaries and Service Control Policies functioning as effective “guardrails” that cannot be overridden by a more permissive identity policy layered on top.

The evaluation engine applies its policy layers in a specific, memorizable order, and knowing that order precisely is what separates fast IAM troubleshooting from guesswork.

flowchart TD
    A["API request made by a principal"] --> B{"Organizations SCP allows action?"}
    B -- No / Explicit Deny --> Z["Request Denied"]
    B -- Yes/Not Applicable --> C{"Resource-based policy explicit deny?"}
    C -- Yes --> Z
    C -- No --> D{"Identity-based policy explicit deny?"}
    D -- Yes --> Z
    D -- No --> E{"Permission Boundary allows action?"}
    E -- No --> Z
    E -- Yes/Not Applicable --> F{"Session Policy allows action?"}
    F -- No --> Z
    F -- Yes/Not Applicable --> G{"Any applicable policy grants explicit Allow?"}
    G -- No --> Z
    G -- Yes --> H["Request Allowed"]
    

Note the structural asymmetry: denials at any layer terminate evaluation immediately, but a “yes” or “not applicable” at any single layer does not grant access on its own — it simply means evaluation continues to the next layer, and ultimately at least one policy must contain an explicit allow statement for the specific action and resource in question, or the default implicit deny applies. This is why permission boundaries and SCPs are correctly described as setting a maximum possible permission ceiling rather than granting any permission themselves — they can only narrow what an identity policy’s explicit allows are permitted to grant, never expand it.

A frequently overlooked consistency detail: IAM is a globally replicated service, and changes — a new policy attachment, a new role, a permission update — can take a brief period to propagate across all AWS regions and services. Automated deployment pipelines that create an IAM role and immediately attempt to assume it in the very next step occasionally hit this propagation window, producing a transient “access denied” that resolves itself moments later with no configuration change required.

IAM offers six distinct places to attach a policy, and each exists to answer a genuinely different governance question — conflating them is the root cause of most advanced permission-modeling confusion.

Identity-based policies, attached to users, groups, or roles, are the primary mechanism for granting permissions and the one most engineers reach for by default. Resource-based policies, attached directly to a resource (an S3 bucket policy, a KMS key policy), grant access from the resource’s own perspective, which is what makes cross-account access without role assumption possible for services that support it. Permission boundaries set a maximum permission ceiling on a specific principal, used heavily to let a delegated administrator create IAM roles without those roles ever being able to exceed a pre-approved permission scope. Service Control Policies, applied at the AWS Organizations level, set an organization- or account-wide maximum ceiling that no identity policy anywhere in that account or OU can exceed, regardless of how permissive it is. Session policies, passed at role-assumption time, further narrow (never expand) what a specific temporary session can do below what the role’s own identity policy already allows. Access Control Lists, a legacy mechanism still present on a small number of resource types like S3 objects, predate the modern policy language and are increasingly superseded by resource-based policies.

Beyond basic permission policies, trust policies governing who may assume a role and attribute-based access control (ABAC) using tags represent the two configuration mechanisms most responsible for scaling IAM cleanly across a growing organization.

A role’s trust policy is a distinct, separate document from its permission policy — the trust policy defines who (which account, which service, which federated identity provider) is allowed to assume the role, while the permission policy defines what that role can do once assumed. Cross-account access architectures depend entirely on correctly scoping trust policies: a role in Account A with a trust policy naming Account B lets a principal in Account B assume that role and inherit exactly the permissions defined in Account A’s permission policy, all without ever creating a long-lived credential shared between the two accounts.

Attribute-based access control uses resource and principal tags directly within policy conditions, rather than hardcoding specific resource ARNs into every policy — a single well-designed ABAC policy can grant a principal access only to resources tagged with a matching project or environment attribute, scaling automatically as new resources are created with the correct tags, without ever requiring a policy update. This is a fundamentally different scaling model from traditional role-based access control (RBAC), where growth in resource count typically requires growth in policy complexity.

IAM is a global service with no regional deployment for the operator to manage, but its eventual-consistency propagation model and its role in the credential lifecycle for every other service make it a genuine dependency worth understanding for reliability planning.

IAM policies, roles, and users are replicated globally and are not scoped to a single AWS Region the way most other services are, meaning there is no separate multi-region IAM deployment decision to make. What does require reliability awareness is the eventual-consistency propagation window discussed in Chapter 2 — automated infrastructure-as-code pipelines that create a role and immediately depend on it should build in retry logic rather than assuming instantaneous global consistency, since a role created moments ago may not yet be assumable from every AWS service endpoint simultaneously.

Because IAM sits in the credential path for literally every other AWS API call, a temporary credentials expiration (for example, an assumed role’s session token nearing its expiry) that isn’t proactively refreshed by application code is a common source of “IAM outage” reports that are actually application-side credential lifecycle bugs rather than any actual IAM service degradation — a distinction advanced incident responders should check early during any widespread “everything is throwing access denied” investigation.

IAM’s own evaluation performance is effectively invisible to operators, but the service imposes real, hard limits on policy size and count that shape how permission architecture must scale as an organization grows.

Managed policies (both AWS-managed and customer-managed) have character-count limits per policy and a limit on how many managed policies can be attached to a single principal, while inline policies count against a separate, per-principal aggregate size quota. Organizations with rapidly growing, fine-grained permission requirements can hit these limits faster than expected if every new requirement is expressed as a brand-new, narrowly scoped managed policy rather than being consolidated or expressed through ABAC’s tag-based conditions, which scale without a corresponding growth in policy count.

Customer-managed policies, reusable across many principals, are strongly preferred over inline policies for anything beyond a genuinely one-off, principal-specific permission, since inline policies cannot be shared, versioned, or centrally audited the way managed policies can — a scalability and governance consideration as much as a technical one.

IAM provides genuinely powerful tooling for approaching least privilege, but none of it enforces least privilege automatically — it is a discipline that has to be actively practiced and continuously audited, not a property the service guarantees by default.

IAM Access Analyzer is the most consequential advanced security tool in the service: it can generate policies based on actual observed access activity (letting teams replace an overly broad hand-written policy with one precisely scoped to what a role has genuinely used), and it separately identifies resources shared with external entities that may represent unintended cross-account or public access. Credential reports and access-advisor data provide the complementary view — which permissions granted to a principal have actually never been used — making it possible to identify and remove genuinely unnecessary access rather than guessing at what “least privilege” should look like from policy documents alone.

CloudTrail is the foundational observability layer for IAM — nearly every meaningful IAM investigation, from a permission denial to a security incident, begins by tracing the actual API calls and the identity behind them through CloudTrail.

Every IAM-related action (policy attachment, role creation, role assumption) and every action taken by an assumed identity is recorded in CloudTrail, including the specific principal, the source IP, and — critically for debugging complex multi-policy evaluation failures — enough context to reconstruct exactly which identity was making the call and under which assumed role or session. CloudTrail’s `AccessDenied` events, correlated against the policy layers from Chapter 2, are the standard starting point for diagnosing exactly which layer produced an unexpected denial.

The durable IAM architectures favor roles over long-lived users, centralized organizational guardrails via SCPs, and tag-driven ABAC for anything that scales with resource count — while the recurring anti-patterns almost always involve long-lived credentials and overly broad wildcard permissions.

IAM’s trade-off is between genuinely comprehensive, fine-grained control and the real cognitive overhead of correctly reasoning about six interacting policy types across every single API call in an account.

Nearly every advanced IAM incident traces back to either an unnoticed explicit deny buried in an unexpected policy layer, a wildcard permission granted for convenience, or long-lived credentials that should have been temporary roles from the start.

Advanced IAM patterns consistently cluster around organizations managing many AWS accounts, delegating administration safely, or operating multi-tenant platforms where permission scope needs to scale with customer count rather than engineering effort.