AWS IAM
AWS Identity and Access Management
Overview
AWS IAM controls who (authentication) can do what (authorization) on which AWS resources — the security foundation of every account. Users, groups, roles, and policies define and assign permissions. IAM itself has no additional charge; every AWS API call passes through this authorization layer. Designing with the principle of least privilege — granting only the permissions actually needed — determines the security posture of the entire account.
Key Concepts
Users, Groups, and Roles
IAM users are individual identities with long-term credentials. Groups bundle users to assign permissions in bulk. Roles are 'hats' with a permission set that any user or service can assume (AssumeRole) temporarily. Assigning roles to EC2 or Lambda lets them call AWS APIs with temporary credentials — no access key embedded in code.
Types of Policies
Identity-based policies attach to users/groups/roles to define permissions. Resource-based policies (e.g., S3 bucket policies) specify on the resource side who is allowed. Service Control Policies (SCPs, from Organizations) cap the maximum permissions for accounts and OUs. Permission boundaries and session policies can further restrict role assumption.
Policy Evaluation Logic
An explicit Deny in any policy always results in denial. If there is no Deny, an explicit Allow in any policy grants access. If no Allow exists anywhere, the default is implicit deny. When multiple boundary layers (SCP, permission boundary) apply, access is granted only if all layers allow it.
Least Privilege and Role Usage
Grant only the permissions required for the task — no more. Distributing long-term access keys is riskier than using role-based temporary credentials. IAM Access Analyzer detects overly permissive policies and external access. Cross-account access is nearly always implemented via role assumption.
MFA and Root User Protection
Enabling MFA adds a second factor beyond password, making credential leakage much less dangerous. The root user has unlimited permissions — enable MFA on it, avoid using it for daily operations, and restrict its use to billing settings and account-level tasks only.
Typical Use Cases
- Assign IAM roles to EC2 and Lambda to call AWS APIs without embedding access keys
- Create department or job-function groups and attach policies for centralized permission management
- Configure cross-account role assumption for safe access to resources in another account
- Apply SCPs across an organization to enforce region restrictions and service guardrails
- Enforce MFA and least-privilege policies to tighten access to privileged operations and production resources
Exam Relevance
IAM is tested at every level and is the core of most security questions. CLF covers the shared responsibility model and root user protection with MFA. SAA/DVA: 'call AWS APIs from an app → use a role, not an access key' is the most reliably correct pattern. Policy evaluation logic (explicit Deny wins, no Allow = implicit deny) is tested in reading-comprehension questions. SAP tests SCP + permission boundary + resource-based policy intersection. Cross-account access is almost always answered with AssumeRole. The reflexes 'no hardcoded keys,' 'least privilege,' 'explicit Deny is highest priority' are the key scoring skills.
Related Services
References
Last updated: 2026-06-24
This page is created from AWS official documentation and reviewed/edited by the operator. See our editorial & quality policy for details.