Cargando...
Cargando...
Know exactly which IAM construct to use, when, and why — the definitive exam and practitioner guide
Four constructs, one mission: control WHO can do WHAT to WHICH AWS resources
| Feature | IAM Roles Temporary credentials for any identity | IAM Users Long-term credentials for human or service | IAM Groups Logical collection of IAM users | IAM Policies JSON document defining permissions |
|---|---|---|---|---|
Primary Identity Type Groups and Policies are NOT identities and cannot directly make API calls. Only Users and Roles can authenticate to AWS. | Assumable identity — no permanent owner | Persistent identity — specific person or application | Container — not an identity itself | Permission document — not an identity |
Credential Type CRITICAL: Roles use temporary credentials via STS AssumeRole. This is always the preferred approach over long-term user keys for applications and services. | Temporary Security Credentials (STS: Access Key ID, Secret Access Key, Session Token) — expire automatically | Long-term credentials: password (console) and/or static Access Key ID + Secret Access Key | No credentials — groups cannot authenticate | No credentials — policies define permissions only |
Who/What Can Use It Groups cannot contain other groups. Roles cannot be added to groups. These are common exam traps. | AWS services (EC2, Lambda, ECS), IAM users, federated users (SAML/OIDC), other AWS accounts, web identity providers | Individual humans or applications needing long-term access (legacy pattern for apps) | IAM Users only — roles and other groups cannot be members | Attached to roles, users, groups, or resources (resource-based policies) |
Cross-Account Access For cross-account access scenarios on exams, the answer is almost always IAM Roles with a trust policy. Resource-based policies (like S3 bucket policies) are the secondary option. | YES — primary mechanism. Trust policy allows external account principals to assume the role | NO — users are account-scoped. Cross-account requires role assumption | NO — groups are account-scoped containers only | YES (resource-based policies) — S3 bucket policies, KMS key policies can grant cross-account access directly |
Credential Rotation / Security Posture Exam scenario: 'How do you securely provide an EC2 instance access to S3?' → Attach an IAM Role with an instance profile. NEVER store access keys on the instance. | Automatic — STS issues short-lived tokens (default 1 hour, max 12 hours for most roles). No rotation needed. | Manual — access keys must be rotated manually or via automation. Keys can be 0–2 per user. Risk of exposure. | N/A — no credentials | N/A — no credentials |
Policy Attachment IAM Roles have TWO policy types: (1) Trust Policy — who can assume the role; (2) Permission Policy — what the role can do. Both must be correct for access to work. | Attach identity-based policies (inline or managed). Also has a trust policy (resource-based) defining who can assume it. | Attach identity-based policies (inline or managed) directly to the user | Attach identity-based policies to the group; all member users inherit them | The policy itself is attached — it is the permission document (JSON) |
Policy Types Applicable Permission Boundaries are identity-based policies that set the MAXIMUM permissions an entity can have — they do not grant permissions themselves. SCPs (Service Control Policies) apply at the AWS Organizations level. | Identity-based (inline + managed) + Trust Policy. Can also be referenced in resource-based policies. | Identity-based (inline + managed). Can also be referenced in resource-based policies. | Identity-based (inline + managed) only | Types: AWS Managed, Customer Managed, Inline, Resource-Based, Permission Boundaries, SCPs (Organizations), Session Policies, ACLs |
Managed vs Inline Policies Best practice: Use Customer Managed Policies over inline policies for reusability and easier auditing. Inline policies are harder to manage at scale. | Supports both. AWS Managed (AWS-maintained), Customer Managed (you maintain), or Inline (embedded, 1:1 relationship) | Supports both. Inline policies are embedded directly in the user and deleted with the user. | Supports both. Inline policies on groups are deleted when the group is deleted. | Managed policies exist independently and can be attached to multiple principals. Inline policies are embedded and tied to one entity. |
Max Managed Policies Attachable The 10 managed policy attachment limit is a soft limit and can be increased via Service Quotas. Inline policy size limits are harder limits. | 10 managed policies per role (soft limit, adjustable) | 10 managed policies per user (soft limit, adjustable) | 10 managed policies per group (soft limit, adjustable) | A managed policy can be attached to an unlimited number of principals (users, groups, roles) |
Session Duration The maximum session duration for a role assumed via AssumeRole is 12 hours, but the default is 1 hour. For AWS service roles (like Lambda execution roles), the session is tied to the invocation. | Configurable: minimum 15 minutes, default 1 hour, maximum up to 12 hours (role-dependent). AWS service roles may have fixed durations. | N/A for API keys (no expiry by default). Console sessions: 12 hours by default. | N/A | N/A — but Session Policies can restrict permissions during a role session |
MFA Support To enforce MFA before allowing role assumption, add a Condition to the trust policy: 'Bool': {'aws:MultiFactorAuthPresent': 'true'}. This is a common exam scenario. | Can require MFA via Condition in trust policy (aws:MultiFactorAuthPresent). Cannot directly have MFA device. | YES — can assign virtual MFA (TOTP), hardware MFA (FIDO2/U2F), or SMS (legacy). Up to 8 MFA devices per user. | NO — groups cannot have MFA | Can enforce MFA via Condition keys (aws:MultiFactorAuthPresent, aws:MultiFactorAuthAge) |
AWS Organizations / SCP Interaction CRITICAL: SCPs do NOT affect the management account (root account of the organization). They apply to member accounts only. SCPs also do NOT affect service-linked roles. | Permissions are the intersection of role policies AND SCPs. SCPs can deny role actions even if the role policy allows them. | Permissions are the intersection of user/group policies AND SCPs. SCPs apply to all principals in the account. | Group permissions are subject to SCPs at the account/OU level | SCPs are a type of policy that act as guardrails — they do NOT grant permissions, only restrict them |
Permission Boundaries Permission Boundaries are the intersection mechanism: effective permissions = (identity-based policies) AND (permission boundary). If either denies, access is denied. | YES — permission boundaries can be set on roles to limit maximum permissions | YES — permission boundaries can be set on users to limit maximum permissions | NO — permission boundaries CANNOT be applied to groups | A permission boundary IS a managed policy used in a special way — it limits, not grants |
Service-Linked Roles Service-linked roles are automatically created when you enable certain AWS services. They are NOT affected by SCPs. You cannot delete them if the service is still using them. | Special type of IAM Role predefined by AWS services (e.g., AWSServiceRoleForEC2SpotFleet). Cannot be manually modified. | Not applicable | Not applicable | Service-linked roles have predefined policies managed by AWS — you cannot edit them |
Instance Profile Instance profile ≠ IAM Role. An instance profile is the wrapper that allows EC2 to use a role. Via CLI/CloudFormation, you must create the instance profile separately. One role per instance profile. | An instance profile is a container for a single IAM Role that is passed to an EC2 instance. Created automatically when you create a role for EC2 in the console. | NOT used with instance profiles | NOT applicable | Policies are attached to the role inside the instance profile |
Federation / SSO Support For enterprise SSO with Active Directory: use IAM Identity Center (formerly AWS SSO) which uses SAML 2.0 federation → assumes IAM Roles. Never create individual IAM Users for each AD user. | PRIMARY mechanism for federation. SAML 2.0, OIDC (web identity), AWS IAM Identity Center all use role assumption. | Not recommended for federated access. Legacy: create IAM users for external contractors (bad practice). | Not directly involved in federation | Policies on the assumed role define federated user permissions |
Audit & Visibility IAM Credential Report is for USERS only — it shows password age, MFA status, access key age, and last used. Use it to identify unused credentials and enforce key rotation. | CloudTrail logs AssumeRole events. IAM Access Analyzer can analyze role trust policies. Credential Report not applicable. | IAM Credential Report shows last used dates for passwords and access keys. CloudTrail logs all API calls. | No direct audit trail — audit by examining group membership and attached policies | IAM Policy Simulator lets you test policy effects. IAM Access Analyzer identifies overly permissive policies. |
Cost IAM is completely free. You pay for the AWS resources accessed via IAM, not IAM itself. IAM Identity Center (SSO) is also free. | FREE — no charge for IAM roles, role assumptions, or STS API calls | FREE — no charge for IAM users, groups, or policies | FREE | FREE — no charge for creating or attaching policies |
Best Practice Use Case AWS Well-Architected Framework and AWS Security Best Practices consistently recommend: prefer roles over long-term user credentials for all programmatic access. | EC2/Lambda/ECS service access, cross-account access, CI/CD pipelines, federated users, any programmatic access from AWS services | Break-glass emergency access, specific automation accounts where roles aren't feasible (rare), individual humans WITHOUT an identity provider | Organizing users by job function (Developers, Admins, ReadOnly) for easier policy management | Defining granular permissions — always use least-privilege principle |
Summary
IAM Roles provide temporary, automatically-rotated credentials and are the preferred mechanism for granting permissions to AWS services, cross-account access, and federated identities. IAM Users are persistent identities with long-term credentials best suited for individual humans without an external identity provider, though IAM Identity Center is now preferred even for humans. IAM Groups are organizational containers that simplify policy management for users, while IAM Policies are the JSON permission documents that define what actions are allowed or denied — they are attached to roles, users, and groups but are not identities themselves.
🎯 Decision Tree
If an AWS SERVICE needs permissions (EC2, Lambda, ECS) → IAM Role with instance profile/execution role. If a HUMAN needs AWS access and you have an IdP (AD, Okta) → IAM Identity Center with federated IAM Role. If a HUMAN needs AWS access with NO IdP → IAM User (with MFA). If you need CROSS-ACCOUNT access → IAM Role with trust policy in the target account. If you need to ORGANIZE users with shared permissions → IAM Group. If you need to DEFINE permissions → IAM Policy (Customer Managed preferred over Inline). If you need to LIMIT maximum permissions → Permission Boundary (managed policy). If you need ORGANIZATION-WIDE guardrails → SCP in AWS Organizations.
CRITICAL — Roles vs Users for AWS Services: NEVER store access keys on EC2 instances, Lambda functions, or ECS containers. Always use IAM Roles with the appropriate execution role or instance profile. The exam will present scenarios where an application on EC2 needs S3/DynamoDB/etc. access — the ONLY correct answer is an IAM Role attached via instance profile. If an answer choice mentions 'create an IAM user and store access keys in environment variables,' it is WRONG.
CRITICAL — Trust Policy vs Permission Policy: IAM Roles have TWO separate policies. (1) The TRUST POLICY (resource-based policy on the role itself) defines WHO can assume the role — this is the Principal in sts:AssumeRole. (2) The PERMISSION POLICY defines WHAT the role can do. Exam questions will test whether you know that both must be correctly configured. A common trap: a role has the right permissions but the trust policy doesn't allow the EC2 service (ec2.amazonaws.com) as a principal — the role won't work.
CRITICAL — Explicit Deny always wins: AWS IAM evaluation logic: (1) Start with DENY ALL. (2) Check for explicit Deny — if found, DENY immediately regardless of any Allow. (3) Check for explicit Allow — if found, ALLOW. (4) Default DENY. This means SCPs, permission boundaries, and resource-based policies that explicitly deny will override any identity-based policy Allow. The exam loves questions about 'why is access being denied even though the IAM policy allows it?' — check for explicit Denies in SCPs, permission boundaries, or resource-based policies.
IMPORTANT — Groups are NOT identities: IAM Groups cannot be used as principals in IAM policy documents (including trust policies and resource-based policies). You cannot say 'allow this S3 bucket to be accessed by Group:Developers.' You can only specify users, roles, accounts, services, or federated identities as principals. Exam trap: 'Grant the Developers group access to this S3 bucket via bucket policy' — you cannot reference a group as a principal in a resource-based policy.
IMPORTANT — Permission Boundaries do not grant permissions: A permission boundary sets the MAXIMUM permissions an entity can have. If you set a permission boundary that allows S3:GetObject but the identity-based policy allows S3:*, the effective permission is only S3:GetObject. Permission boundaries are commonly used in delegation scenarios where admins create roles/users but need to prevent privilege escalation. Exam tip: If a question asks 'how do you allow developers to create IAM roles but prevent them from creating roles with more permissions than they have?' — the answer is permission boundaries.
IMPORTANT — SCPs affect member accounts, NOT the management account: Service Control Policies in AWS Organizations apply to all accounts in the organization EXCEPT the management (root/master) account. SCPs also do NOT affect service-linked roles. If an exam question asks 'you applied an SCP to deny EC2 actions but the management account can still launch EC2 instances' — this is expected behavior. SCPs also cannot be applied to the root OU to affect the management account.
IMPORTANT — IAM Identity Center (SSO) vs IAM Federation: For enterprise SSO, AWS recommends IAM Identity Center over creating SAML federation directly with IAM. IAM Identity Center supports both AWS Managed Active Directory and external IdPs (Okta, Azure AD). It uses permission sets (which become IAM roles in each account) rather than manually creating roles. For the exam: if the question mentions 'centrally manage access across multiple AWS accounts for existing Active Directory users,' the answer is IAM Identity Center.
NICE-TO-KNOW — IAM Policy evaluation for cross-account access: For cross-account access, BOTH the identity-based policy in the source account AND the resource-based policy (or role trust policy) in the target account must allow the access. Unlike same-account access where either an identity-based policy OR a resource-based policy can grant access (not both required), cross-account requires both sides to explicitly allow.
NICE-TO-KNOW — Credential Report vs Access Advisor: IAM Credential Report (account-level) shows last used info for ALL users' passwords and access keys — use it for compliance auditing. IAM Access Advisor (entity-level) shows which services a specific user/role/group/policy has accessed and when — use it to identify and remove unused permissions. Both are free tools for implementing least privilege.
The #1 exam trap is confusing IAM Role TRUST POLICIES with PERMISSION POLICIES. When a role 'isn't working,' candidates check the permissions policy but forget that the trust policy must also correctly specify the Principal (who can assume the role). For example, an EC2 instance role must have 'ec2.amazonaws.com' as the trusted principal, and a Lambda execution role must have 'lambda.amazonaws.com'. A second major trap is assuming SCPs grant permissions — they only restrict. A third trap is thinking Groups can be referenced as Principals in resource-based policies — they cannot.
CertAI Tutor · SAP-C02, CLF-C02, SCS-C02, SAA-C03, DVA-C02, DEA-C01, AIF-C01, DOP-C02 · 2026-02-22
Services
Comparisons
Guides & Patterns