AWS IAM

Identity and Access Management — users, groups, roles, policies, cross-account access, permission boundaries, federation, and least-privilege patterns.

Overview

AWS Identity and Access Management (IAM) is the service that controls authentication (who can sign in) and authorisation (what they can do) for every AWS resource — it is the foundation of AWS security.

IAM is a global service — users, groups, roles, and policies are not region-scoped. There is no charge for IAM itself.

Core Concepts

Concept	Description
IAM User	An identity representing a person or application with long-term credentials (password/access keys)
IAM Group	A collection of IAM users; policies attached to the group apply to all members
IAM Role	An identity with temporary credentials assumed by users, services, or external identities
IAM Policy	A JSON document defining permissions (Effect, Action, Resource, Condition)
Permission Boundary	A managed policy that sets the maximum permissions an IAM entity can have
Identity-based Policy	Attached to a user, group, or role — defines what actions the identity can perform
Resource-based Policy	Attached to a resource (S3 bucket, SQS queue) — defines who can access it
Trust Policy	Attached to a role — defines which principals can assume the role
STS	Security Token Service — issues temporary credentials when a role is assumed
MFA	Multi-Factor Authentication — adds a second authentication factor to IAM identities

Policy Structure

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadOnly",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"],
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}

Policy Evaluation Logic

1. All requests start with an implicit DENY
2. Evaluate all applicable policies
3. Any explicit DENY → DENIED (final)
4. Any explicit ALLOW → ALLOWED
5. No explicit ALLOW found → DENIED (implicit)

Exam Trap: An explicit Deny always wins, regardless of any Allow statements. If a policy denies an action, no other policy can override it. This is tested frequently in cross-account and multi-policy scenarios.

Policy Types (Evaluation Order)

Policy Type	Attached To	Purpose
Service Control Policy (SCP)	AWS Organization OU/Account	Guardrails — restricts maximum permissions
Permission Boundary	IAM User or Role	Caps the effective permissions of the entity
Identity-based Policy	User, Group, or Role	Grants permissions to the identity
Resource-based Policy	AWS Resource (S3, SQS, etc.)	Grants cross-account or specific-principal access
Session Policy	STS AssumeRole call	Further restricts the assumed role's permissions

Effective permissions = intersection of all applicable boundary layers (SCP ∩ Permission Boundary ∩ Identity Policy).

IAM Roles

Common Role Types

Role Type	Assumed By	Use Case
EC2 Instance Role	EC2 instance (via instance profile)	Grant EC2 access to S3, DynamoDB, etc.
Lambda Execution Role	Lambda service	Grant Lambda access to AWS resources
ECS Task Role	ECS task	Per-container permissions
Cross-Account Role	IAM user/role in another account	Delegate access without sharing credentials
Service-Linked Role	AWS service	Pre-configured by AWS for specific services
SAML/OIDC Federation Role	External identity provider	SSO for enterprise users

SAA/SAP Tip: Always prefer IAM Roles over IAM Users with access keys. Roles provide temporary credentials that rotate automatically. Hardcoded access keys in code or config files are a security anti-pattern.

Cross-Account Access

Account A (Trusting)                     Account B (Trusted)
┌───────────────────┐                    ┌───────────────────┐
│ IAM Role           │◄── AssumeRole ──  │ IAM User/Role     │
│ Trust Policy:      │                    │ Policy:            │
│   Principal:       │                    │   Allow:           │
│     Account B      │                    │     sts:AssumeRole │
│ Permission Policy: │                    │   Resource:        │
│   Allow S3 access  │                    │     Role ARN in A  │
└───────────────────┘                    └───────────────────┘

Two requirements:

Trust policy on the role in Account A allows Account B to assume it
Identity policy on the user/role in Account B allows sts:AssumeRole for the role ARN

Permission Boundaries

Permission boundaries limit the maximum permissions for IAM users and roles — the effective permission is the intersection of the identity policy and the boundary.

Identity Policy:     s3:*, ec2:*, rds:*
Permission Boundary: s3:*, ec2:*
────────────────────────────────
Effective:           s3:*, ec2:*   (rds:* is excluded)

Use case: Allow developers to create IAM roles, but only with permissions that fall within the boundary — prevents privilege escalation.

Identity Federation

Federation Type	Protocol	Use Case
SAML 2.0	SAML	Enterprise SSO (Active Directory, Okta)
OIDC / Cognito	OpenID Connect	Web/mobile app users; social login (Google, Facebook)
AWS SSO (IAM Identity Center)	SAML / OIDC	Centralised multi-account access management
Custom Identity Broker	STS APIs	Legacy federation where SAML is not available

SAA/SAP Tip: IAM Identity Center (formerly AWS SSO) is the recommended way to manage workforce access across multiple AWS accounts. It integrates with Active Directory and external IdPs and should be the default answer for "centralised access management" questions.

Best Practices

Practice	Description
Least privilege	Grant only the minimum permissions required
Use roles over users	Temporary credentials are safer than long-term keys
Enable MFA	Require MFA for root and all human users
Rotate credentials	Rotate access keys periodically; prefer roles
Use policy conditions	Restrict by IP, MFA, time, tags, etc.
Separate duty with permission boundaries	Prevent privilege escalation in delegated admin models
Audit with IAM Access Analyzer	Identify resources shared externally or unused permissions

Common Use Cases

Application access — EC2 instance roles or Lambda execution roles grant applications temporary credentials to AWS resources.
Cross-account delegation — Central logging account assumes roles in workload accounts to read CloudTrail/CloudWatch.
Enterprise SSO — IAM Identity Center + Active Directory for workforce access across 50+ accounts.
CI/CD pipelines — CodeBuild or GitHub Actions assume IAM roles via OIDC federation — no stored secrets.
Third-party access — External vendor assumes a cross-account role with an external ID condition.

SAA/SAP Exam Tips

SAA/SAP Tip: For questions about "temporary credentials" or "no long-term credentials," the answer involves IAM Roles and STS:AssumeRole. Roles provide time-limited credentials that expire automatically.

Exam Trap: Resource-based policies (e.g., S3 bucket policy) can grant cross-account access without requiring sts:AssumeRole. The requesting principal must still have identity-based permissions, but no role assumption is needed — the resource policy directly grants access.

SAA/SAP Tip: Permission boundaries prevent privilege escalation. If a developer can create IAM roles, a permission boundary ensures they cannot create roles with more permissions than their own boundary allows.

Cross-Cloud Equivalents

Provider	Service / Solution	Notes
AWS	AWS IAM	Baseline
Azure	Azure Active Directory (Entra ID) + Azure RBAC	Entra ID handles identity; RBAC handles authz
GCP	Google Cloud IAM	Resource hierarchy-based; similar role concept
On-Premises	Active Directory, LDAP, Keycloak	Traditional identity management

Pricing Model

Dimension	Unit	Notes
IAM	Free	No charge for users, groups, roles, policies, or MFA

AWS Organizations — SCPs for multi-account permission guardrails
AWS KMS and CloudHSM — encryption key management policies
AWS Secrets Manager — securely store and rotate credentials
Amazon GuardDuty — threat detection for compromised credentials
Amazon CloudWatch — monitor IAM events via CloudTrail integration

AWS IAM

On this page