Cargando...
Cargando...
Master who can do what, on which resource, under what conditions — the foundation of every secure AWS architecture
AWS Identity and Access Management (IAM) is a global, free service that controls authentication (who you are) and authorization (what you can do) across all AWS services and resources. It enables fine-grained access control through users, groups, roles, and policies — all evaluated in real time on every API call. IAM is the security backbone of AWS: every action taken in AWS passes through IAM's policy evaluation engine before being allowed or denied.
Centrally manage access to AWS services and resources securely, enabling least-privilege access through identity-based and resource-based policies evaluated on every API request
Use When
Avoid When
IAM Users
Long-term identities with username/password and/or access keys; use sparingly — prefer roles and federation for humans and services
IAM Groups
Logical collection of users for policy attachment; NOT a principal — cannot be referenced in resource-based policies or trust policies
IAM Roles
Temporary credential-based identities assumed by users, services, or federated identities; the cornerstone of secure AWS architecture
Identity-based Policies
Attached to users, groups, or roles; define what actions the identity can perform on which resources
Resource-based Policies
Attached to resources (S3 buckets, KMS keys, SQS queues, etc.); define who can access the resource; support cross-account access without role assumption
Permission Boundaries
Advanced feature that sets the maximum permissions an identity-based policy can grant; does NOT grant permissions itself — only limits them
Service Control Policies (SCPs)
Applied via AWS Organizations; limit maximum permissions for entire accounts or OUs; do NOT grant permissions — only restrict
Session Policies
Passed during AssumeRole/federation calls; further restrict the role's permissions for that specific session only
IAM Policy Conditions
Conditional logic in policies using condition keys (aws:RequestedRegion, aws:PrincipalOrgID, aws:MultiFactorAuthPresent, etc.)
Policy Variables
Dynamic values in policies (e.g., ${aws:username}) enable creating single policies that work for all users without duplication
IAM Access Analyzer
Identifies resources shared with external principals; generates least-privilege policies from CloudTrail activity; validates policies against grammar and best practices
IAM Credentials Report
Account-level CSV report of all users and their credential status; useful for auditing MFA enablement and access key age
IAM Access Advisor
Shows last-accessed service data for a user/role; use to right-size permissions and implement least privilege over time
Multi-Factor Authentication (MFA)
Supports virtual MFA (TOTP apps), hardware FIDO2/WebAuthn keys, hardware TOTP tokens, and SMS MFA (for root via support only)
SAML 2.0 Federation
Enterprise SSO via corporate IdPs (ADFS, Okta, Ping); users get temporary credentials via AssumeRoleWithSAML
OIDC / Web Identity Federation
Federate with Google, Facebook, Amazon Cognito, GitHub Actions, Kubernetes service accounts; keyless credential vending
AWS STS Integration
All temporary credentials flow through STS; IAM Roles define permissions, STS issues the time-limited tokens
Global Service (No Regional Endpoint)
IAM is global — policies, users, roles replicate globally; no regional selection needed; IAM data is eventually consistent
Tags on IAM Identities
Tag users and roles; use aws:PrincipalTag condition key in policies for attribute-based access control (ABAC)
Attribute-Based Access Control (ABAC)
Use tags on principals and resources with condition keys to create scalable, tag-driven access control without modifying policies as teams grow
IAM Identity Center Integration
IAM Identity Center (formerly SSO) uses permission sets that generate IAM roles in member accounts; preferred for human workforce access
Root User
Has unrestricted access to all AWS services; cannot be restricted by SCPs or permission boundaries; should be used only for specific tasks and protected with MFA
IAM Policy Simulator
Test and debug policies without making real API calls; validates effective permissions considering all policy types
Organization-Wide Permission Guardrails with SCPs
high freqService Control Policies (SCPs) attached to OUs in AWS Organizations act as permission guardrails for all accounts in the OU. SCPs do NOT grant permissions — they define the maximum permissions any IAM policy in the account can grant. Use SCPs to prevent specific regions, deny disabling CloudTrail, or restrict to approved services. IAM policies within accounts still need to explicitly grant access.
Workforce Federation with Permission Sets
high freqIAM Identity Center (SSO) is the recommended solution for human workforce access. It creates IAM roles in member accounts based on Permission Sets, provides a centralized access portal, integrates with external IdPs (Azure AD, Okta), and issues short-lived credentials. Eliminates need for individual IAM users across multiple accounts.
IAM Activity Audit and Compliance
high freqEvery IAM API call (CreateUser, AttachRolePolicy, AssumeRole, etc.) is logged by CloudTrail as a management event. Use CloudTrail + CloudWatch Logs + metric filters to alert on root account usage, policy changes, or failed AssumeRole attempts. IAM Access Analyzer can also analyze CloudTrail logs to generate least-privilege policy recommendations.
Layered S3 Access Control
high freqS3 access is controlled by the intersection of IAM identity policies, S3 bucket policies (resource-based), S3 ACLs (legacy), and S3 Access Points. For cross-account access, a resource-based bucket policy can grant access directly without role assumption. For same-account access, either IAM policy OR bucket policy granting access is sufficient (union). Explicit Deny in either always wins.
Lambda Execution Role and Resource-Based Policy
high freqLambda uses two IAM constructs: (1) Execution Role — an IAM Role the Lambda function assumes to call other AWS services; (2) Resource-based policy — controls who/what can invoke the Lambda function. The execution role must trust lambda.amazonaws.com. Use least-privilege execution roles with only the permissions the function actually needs.
Secrets Access with IAM and Resource Policies
high freqSecrets Manager secrets have resource-based policies that control cross-account access. For same-account access, IAM identity policies granting secretsmanager:GetSecretValue are sufficient. Combine with IAM conditions (aws:SourceVpc, aws:PrincipalOrgID) to restrict secret access to specific network paths or organization members only.
Cross-Account Role Assumption
high freqAccount A (trusted) assumes a role in Account B (trusting) via STS:AssumeRole. Account B's role trust policy must list Account A's ARN as a principal. Account A's IAM policy must grant sts:AssumeRole on Account B's role ARN. STS returns temporary credentials (Access Key, Secret Key, Session Token) valid for the configured session duration.
EC2 Instance Profile for Service Credentials
high freqAttach an IAM Role to EC2 via an Instance Profile. The EC2 instance metadata service (IMDS) vends temporary credentials at 169.254.169.254/latest/meta-data/iam/security-credentials/. AWS SDKs automatically retrieve and refresh these credentials. IMDSv2 (session-oriented) is required for new instances in security-conscious environments — enforce via IAM condition aws:ec2MetadataHttpTokens.
KMS Key Policy + IAM Policy for Encryption Control
high freqKMS key access requires BOTH the KMS key policy to allow the principal AND the IAM identity policy to grant kms:* actions. The key policy is the primary access control — if the key policy grants the account root, then IAM policies in that account can further grant/restrict access. Cross-account KMS access requires explicit grants in both the key policy and the external account's IAM policies.
The IAM policy evaluation order is: Explicit Deny → SCPs → Resource-based policies → Identity-based policies → Permission Boundaries → Session policies. An explicit Deny ANYWHERE in this chain always wins, overriding any Allow. If no explicit Allow exists, the default is Deny (implicit deny).
IAM Roles issue TEMPORARY credentials via STS — they have no long-term passwords or access keys. When you see exam questions about 'most secure way to grant EC2/Lambda access to S3,' the answer is always IAM Role (not access keys, not environment variables with keys).
Permission Boundaries do NOT grant permissions — they only limit the maximum permissions an identity-based policy can grant. A user with a permission boundary of S3:* and an identity policy of EC2:* gets ZERO permissions because EC2 is outside the boundary. The effective permission is the intersection of identity policy AND permission boundary.
SCPs (Service Control Policies) from AWS Organizations also do NOT grant permissions — they are guardrails that restrict what IAM policies in an account CAN grant. The management (root) account is NEVER affected by SCPs. IAM policies in member accounts still need to explicitly grant access within the SCP-allowed scope.
For cross-account S3 access: if the requester is in the SAME account as the bucket, either the IAM policy OR the bucket policy granting access is sufficient. If cross-account, BOTH the bucket policy (resource-based) AND the requester's IAM policy must grant access — one alone is not enough.
Explicit Deny ALWAYS wins — SCPs, permission boundaries, and session policies only RESTRICT (never grant). The effective permission is always the INTERSECTION of all applicable policy types, with any explicit Deny immediately overriding all Allows.
IAM Roles vend TEMPORARY credentials via STS — always use roles for EC2, Lambda, ECS, and any AWS service needing to call other AWS services. Never embed long-term access keys in application code, environment variables, or AMIs.
Cross-account role assumption requires a TWO-SIDED configuration: the target account's role trust policy must allow the source principal, AND the source account's IAM policy must grant sts:AssumeRole on the target role ARN. Missing either side = AccessDenied.
IAM Groups CANNOT be principals in trust policies or resource-based policies. You cannot write 'Principal: {AWS: arn:aws:iam::123456789012:group/Developers}' — this is invalid. Only users, roles, AWS services, and accounts can be principals.
Role chaining (Role A assumes Role B) caps the session at 1 hour maximum, regardless of the MaxSessionDuration setting on either role. This is a hard limit — design workflows that need longer sessions to avoid role chaining.
The aws:PrincipalOrgID condition key is one of the most powerful IAM conditions — it restricts access to only principals within your AWS Organization without needing to list every account ARN. Use it in resource-based policies to prevent data exfiltration to accounts outside your org.
ABAC (Attribute-Based Access Control) with IAM tags scales better than RBAC for large organizations. Use aws:PrincipalTag/department and aws:ResourceTag/department in conditions to automatically grant access when tags match — no policy updates needed when teams grow.
The IAM Credentials Report (account-level) and IAM Access Advisor (per-identity) are the two key audit tools. Credentials Report shows ALL users and credential status (MFA enabled, key age, last used). Access Advisor shows last-accessed service timestamps per identity — use both for least-privilege enforcement.
When a Lambda function needs to access resources in another account, the Lambda's execution role must be granted sts:AssumeRole on the target account's role, AND the target role's trust policy must allow the Lambda's execution role ARN. Alternatively, use resource-based policies on the target resource if supported.
The root user cannot be restricted by SCPs, permission boundaries, or any IAM policy. The only way to protect root is: enable MFA, delete root access keys, and use AWS Organizations root account for billing/governance only — never for daily operations.
IAM is eventually consistent — after creating a user or updating a policy, there may be a brief delay before the change propagates globally. In exam scenarios about 'why is the new policy not working immediately,' eventual consistency is the answer.
Common Mistake
SCPs grant permissions to accounts in AWS Organizations — if I attach an SCP that allows S3:*, users in the account can access S3
Correct
SCPs ONLY restrict permissions — they never grant them. An SCP allowing S3:* means the maximum possible permission is S3:*, but IAM policies in the account must still explicitly grant the access. Without an IAM policy Allow, there is still an implicit Deny.
This is the #1 SCP misconception on exams. Think of SCPs as a ceiling, not a floor. The ceiling limits how high you can go, but you still need a ladder (IAM policy) to get there. If an SCP denies a service, no IAM policy in any account in that OU can override it.
Common Mistake
Permission Boundaries grant the permissions listed in them — attaching a permission boundary with S3:* gives the user S3 access
Correct
Permission Boundaries only define the MAXIMUM permissions an identity-based policy can grant. The boundary alone grants nothing. The user also needs an identity-based policy that explicitly allows S3:*. Effective permissions = intersection of identity policy AND permission boundary.
Permission boundaries are the second most misunderstood IAM concept. They're a safety net for delegated administration — e.g., allowing developers to create roles but ensuring those roles can never exceed a defined scope. The boundary restricts; the identity policy grants.
Common Mistake
IAM Groups can be used as principals in S3 bucket policies or IAM trust policies to grant access to all group members
Correct
IAM Groups are NOT valid IAM principals and CANNOT appear in Principal elements of any policy. They are purely administrative constructs for attaching policies to multiple users at once. To grant group-level access in resource policies, you must list individual user ARNs or use roles.
This trap appears regularly in S3 cross-account and trust policy questions. Remember: only Users, Roles, AWS Services, AWS Accounts, and federated identities are valid principals. Groups exist only to simplify policy management, not as security principals.
Common Mistake
AWS managed policies (like AmazonS3FullAccess) can be shared across AWS accounts or modified to fit specific needs
Correct
AWS managed policies are owned and maintained by AWS, exist in every account automatically, CANNOT be modified, and are NOT shared across accounts — each account has its own copy. Customer-managed policies are what you create and control, and they exist only in your account.
This ties to the exam misconception about 'AWS managed keys shared across accounts.' AWS managed policies (and keys) are per-account constructs. You can reference them but never modify them. For custom permissions, always create customer-managed policies.
Common Mistake
An IAM Role and an IAM Instance Profile are the same thing — attaching a role to EC2 is the same as creating an instance profile
Correct
An Instance Profile is a container that holds exactly one IAM Role and is the actual object attached to an EC2 instance. They are separate IAM resources. The AWS Console auto-creates instance profiles with the same name as the role, hiding this distinction. In CLI/CloudFormation/CDK, you must explicitly create both the role AND the instance profile.
Infrastructure-as-Code practitioners frequently hit errors when they create an IAM Role but forget to create the Instance Profile resource. The console's auto-creation behavior masks this requirement until you move to automation.
Common Mistake
Explicit Allow in an IAM policy always grants access, even if there's a Deny elsewhere
Correct
An Explicit Deny ALWAYS wins over any Allow, anywhere in the policy evaluation chain — identity policies, resource policies, SCPs, permission boundaries, or session policies. The evaluation order always checks for explicit Deny first, and finding one immediately terminates evaluation with a Deny.
The evaluation logic is: Deny wins > Allow wins > Implicit Deny (default). Use explicit Deny for non-negotiable security controls like 'never allow deletion of CloudTrail' or 'always require MFA' — these cannot be overridden by any other policy.
Common Mistake
When using AssumeRole across accounts, only the target account's role trust policy needs to be configured
Correct
Cross-account role assumption requires configuration in BOTH accounts: (1) The target account's role trust policy must list the source account/principal as a trusted entity, AND (2) The source account's IAM policy must grant sts:AssumeRole on the target role ARN. Missing either one will result in AccessDenied.
This two-sided requirement is frequently tested. Think of it as a handshake: the target says 'I trust you' (trust policy), and the source says 'I'm allowed to go there' (permission policy). Both must agree for the assumption to succeed.
Common Mistake
IAM is a regional service — you need to create users and roles in each region where you operate
Correct
IAM is a GLOBAL service with a single namespace across all regions. Users, roles, groups, and policies created in IAM are available globally without regional configuration. There is no 'us-east-1 IAM user' — all IAM resources are account-global.
This confuses candidates who know that most AWS services are regional. IAM, Route 53, CloudFront, and AWS Organizations are the main global services. The IAM console doesn't show a region selector for this reason.
PARC for what policies control: Principal, Action, Resource, Condition — every IAM policy statement has these four elements
DENY > ALLOW > IMPLICIT DENY — the three-tier evaluation waterfall: explicit Deny beats everything, explicit Allow wins if no Deny, silence means No
GROUPS ARE NOT PRINCIPALS — 'Groups Group policies, they're not Gatekeepers' — groups attach policies to users but cannot be referenced in trust or resource policies
SCP = CEILING, Boundary = CEILING, Session Policy = CEILING — all three only restrict, never grant. IAM identity policies are the only thing that actually GRANTS access
For cross-account access remember '2-sided handshake': Target TRUSTS (trust policy) + Source ALLOWS (identity policy) = successful AssumeRole
ABAC = Tags Match = Access Granted — Attribute-Based Access Control scales infinitely because you control access via matching tags, not by updating policy lists
The 5 policy types in evaluation order: SCPs → Resource-based → Identity-based → Permission Boundaries → Session Policies (SRIPS)
CertAI Tutor · SAP-C02, CLF-C02, SAA-C03, DOP-C02, SCS-C02, AIF-C01 · 2026-02-21
In the Same Category
Comparisons
Guides & Patterns