A Complete Guide to the IAM Permission Model with Policies, Roles, and Permission Boundaries
_Category: Identity & Access_
Every aspect of AWS security ultimately comes back to IAM. IAM decides who (Principal) can do what (Action) on which service or resource (Resource), making it the foundation of any security architecture — and the single most frequently tested domain on the SCS-C03 exam. This guide works through the real-world pitfalls you will actually encounter: cross-account access failures, confusion between Permission Boundary and SCP, missing Trust Policies, and more.
---
The Four Pillars of the IAM Permission Model: Principal, Action, Resource, Condition
IAM determines access through the combination of four elements. Think of it like a building access-control system — every door check requires each element to line up.
Principal: Who is making the request. This can be an IAM user, an IAM role, an AWS service, or an external account. Action: What they are trying to do. These are API calls such as , , or . Resource: Which resource they are targeting. Specified by ARN — a particular bucket, a specific role, and so on. Condition: Under what circumstances. You can gate access on IP address, time of day, MFA status, AWS Region, resource tags, and many other attributes.
An IAM policy is a JSON document that describes these four elements. A single Statement block contains an Effect (Allow or Deny), a Principal, an Action, a Resource, and an optional Condition. Knowing the most common condition keys lets you read exam scenarios quickly.
— Automatically revokes time-limited access. Applied as a condition on an Allow statement; when the condition is not met, an implicit Deny takes effect. — Checks whether MFA was used. Long-term credential requests always set this to , so adding a Deny when the value is enforces MFA. — Restricts access to specific AWS Regions. Global services (IAM, CloudFront, Route 53) must be excluded using , or you will accidentally block them. — Blanket-blocks principals from outside your AWS Organization. + — Combines VPC scope with mandatory tagging in a single AND condition.
---
The Six Types of IAM Policies
IAM controls access through six distinct policy types, each operating at a different layer of the evaluation stack. You need to know exactly which layer each policy sits on and what it can and cannot do.
| Policy Type | Applies To | Primary Role | Cross-Account | |-------------|-----------|--------------|---------------| | Identity-based Policy | IAM users, groups, roles | Defines what the attached identity is allowed to do | No | | Resource-based Policy | S3 buckets, KMS keys, SQS queues, etc. | Defines which Principals can access the resource | Yes (specify Principal) | | Permission Boundary | Individual IAM users or roles | Sets a maximum permission ceiling for the identity | No | | SCP (Service Control Policy) | AWS Organizations OUs or accounts | Sets the maximum allowed scope for an entire account | Across the entire Organization | | Session Policy | STS temporary sessions | Adds further restrictions at the session level | No | | ACL (Access Control List) | S3 and select services | Legacy access-control mechanism (not recommended) | Yes |
A helpful analogy maps each type to a real-world access scenario. An Identity-based Policy is the personal access card that lists exactly which doors an employee can open. A Resource-based Policy is the sign on a meeting room door saying "Only these people may enter." A Permission Boundary is a new-hire badge stamped "Maximum floor access: Floor 3." An SCP is the company-wide security policy that applies to every employee simultaneously. A Session Policy is the temporary visitor pass issued to a contractor for a single day.
Resource-based policies attach directly to the resource itself, which is why they are the only mechanism that can grant cross-account access on their own. Permission Boundary and SCP can only narrow the permission scope — neither can grant permissions by itself.
---
Policy Evaluation Logic: Explicit Deny Takes Priority
When AWS receives a request, it collects every applicable policy and evaluates them in a defined order. There is one cardinal rule: an explicit Deny always overrides any Allow, regardless of where the Deny appears.
The evaluation sequence is: ① Explicit Deny → ② SCP (when running inside an AWS Organization) → ③ Permission Boundary → ④ Resource-based Policy → ⑤ Identity-based Policy. If no Allow is found at any step, the request ends in an implicit Deny.
The difference between same-account and cross-account access is one of the highest-yield distinctions on the exam.
| Access Scenario | What is Required | |-----------------|------------------| | Same-account S3 access | Either an Identity-based Policy OR a Resource-based Policy allows it — one is sufficient | | Cross-account S3 access | Both the Identity-based Policy AND the Resource-based Policy (bucket policy) must allow it |
Even a role that carries AdministratorAccess cannot reach a bucket in another account if that bucket's policy does not explicitly permit the cross-account principal. A second common trap is the S3 ARN level: must target the object ARN . Pointing only at the bucket ARN results in Access Denied.
---
Roles and AssumeRole: Temporary Credentials for Cross-Account and Service-to-Service Access
An IAM Role works like a temporary access pass issued to a colleague from another department. STS (Security Token Service) issues short-lived credentials that expire automatically — anywhere from 15 minutes up to a maximum of 12 hours.
Every role requires exactly two policies.
Trust Policy: Defines who is allowed to assume this role. The Principal element can be an AWS account, an IAM role, or an AWS service. Permission Policy: Defines what the role can do once it has been assumed.
For EC2 to access S3, the Permission Policy needs the relevant S3 permissions and the Trust Policy must list as a trusted principal. If the service is missing from the Trust Policy, the AssumeRole call itself fails before any permissions are evaluated.
Cross-account AssumeRole has two requirements that must both be satisfied: the target account's role Trust Policy must allow the source account, and the source account's IAM principal must have in its Permission Policy. Both sides must agree — either one missing causes failure.
AWS credential precedence for the CLI and SDKs: environment variables > credentials file > config profile > IMDS (instance role). If an EC2 instance has a role attached but a credentials file also exists, the credentials file wins. This is a frequent cause of "why isn't my instance role being used?"
Key temporary credential mechanisms to know for the exam: EC2 instance profiles (credentials delivered via IMDS and rotated automatically), Cognito Identity Pool (STS-backed credentials for guest and authenticated mobile users), and IAM Roles Anywhere (replaces long-term access keys for on-premises servers using X.509 certificates).
---
Permission Boundary vs SCP: Clearing Up the Most Confusing Pair
Permission Boundary and SCP are both tools that restrict permissions, but their scope and target differ entirely. Mixing them up is one of the most reliable ways to lose points on the exam.
| Attribute | Permission Boundary | SCP | |-----------|--------------------|---------| | Applies To | Individual IAM user or role | AWS Organizations OU or entire account | | Configured In | IAM console (per user or role) | Organizations management console | | Grants Permissions | No — defines a ceiling only | No — defines maximum allowed scope only | | Effective Permission Calculation | Identity-based Policy ∩ Permission Boundary | SCP ∩ Identity-based Policy ∩ Permission Boundary | | Primary Use Case | Cap the permissions of roles created by a dev team | Restrict Regions or services across the whole organization |
Permission Boundary is the right tool when you want to give a development team the freedom to create roles without letting them create roles that exceed a predefined permission ceiling. The security team creates the Boundary policy and enforces it by adding an condition to the action. Even if a developer attaches AdministratorAccess to a role they create, the Boundary silently caps everything the role can actually do.
SCP applies at the Organizations level — to an OU or to an entire account. Crucially, SCP does not apply to the management (master) account. Like Permission Boundary, SCP is not a permission-granting mechanism; it only sets an outer limit. For per-identity restrictions, always use Permission Boundary rather than SCP.
!Permission Boundary versus SCP
Federation and IAM Identity Center: Integrating External Identities and SSO
Creating a separate IAM user for each employee is both operationally expensive and a security liability. Federation lets you connect an existing Active Directory or external Identity Provider (IdP) to AWS instead.
SAML 2.0 Federation works by having the IdP authenticate the user, generating a SAML Assertion that STS validates in exchange for temporary AWS credentials. When you have multiple accounts, however, each one requires individual setup, which quickly becomes a management burden.
OIDC-based Federation (Web Identity Federation) is implemented through Cognito and uses to issue temporary credentials. This is the standard pattern for giving mobile app users — authenticated through a social login — access to AWS resources without IAM user accounts.
IAM Identity Center (formerly AWS SSO) integrates with Organizations to provide centralized SSO across hundreds of accounts using a single set of credentials. AD Connector allows you to authenticate against an existing on-premises Active Directory in proxy mode, with no need to synchronize the directory into the cloud.
Setup sequence for Identity Center: enable the service in the Organizations mana