This chapter covers AWS Identity and Access Management (IAM), the core service for controlling access to AWS resources. IAM is a fundamental topic on the CLF-C02 exam, falling under Domain 2: Security and Compliance, Objective 2.2. Understanding IAM is critical because it underpins all security in AWS; without it, you cannot securely manage users, workloads, or permissions. Expect approximately 10-15% of exam questions to touch on IAM concepts, making it one of the highest-weighted security topics.
Jump to a section
Imagine a large corporate office building. The building itself is your AWS account. To enter, you need an ID badge (your IAM user). The badge has your name and photo, uniquely identifying you. But having a badge doesn't mean you can go everywhere. There are different doors: the front door (console access), the server room (EC2 instances), the finance office (billing), and the CEO's suite (root user). Each door has a lock that requires a specific key. In AWS, these keys are permissions defined in policies. A policy is like a rule sheet that says: 'Employees with badge type A can enter the server room from 9-5, but cannot open the safe.' IAM roles are like temporary visitor badges. If a contractor needs to access the server room for a day, you issue them a temporary badge that expires. They don't become a permanent user; they just assume the role. Groups are like departments: all employees in 'Engineering' get the same set of door access rights automatically. When a new engineer joins, you add them to the Engineering group, and they instantly get the same permissions as their peers. The root user is the building owner with a master key to every door. You rarely use it because if it's lost or misused, the entire building is compromised. Instead, you create individual badges for each employee and assign only the keys they need. This is the principle of least privilege. AWS IAM works exactly like this: you create users, assign them to groups, attach policies that grant specific permissions, and use roles for temporary, cross-account, or service-to-service access.
What AWS IAM Is and the Problem It Solves
AWS Identity and Access Management (IAM) is a web service that helps you securely control access to AWS resources. It allows you to manage who is authenticated (signed in) and authorized (has permissions) to use resources. Before IAM, AWS had only one account-level credential: the root user, which had unlimited access. The problem was that sharing the root user among multiple people was a massive security risk. IAM solves this by enabling you to create multiple users, each with their own credentials, and assign granular permissions.
IAM is a global service — it is not region-specific. This means you define your IAM policies and users once, and they apply across all AWS regions. There is no cost for IAM itself; you only pay for other AWS services that you access. However, there are service limits, such as a maximum of 5,000 IAM users per account and 300 roles per account (these limits can be increased by contacting AWS Support).
How IAM Works — The Mechanism
IAM operates on a simple model: Users, Groups, Roles, and Policies.
Users: A user represents a person or service that needs to interact with AWS. Each user has a unique name and a set of credentials (password for console access, access keys for programmatic access). By default, a new user has no permissions — you must explicitly grant them.
Groups: A group is a collection of users. Instead of attaching policies to each user individually, you attach policies to a group, and all users in the group inherit those permissions. A user can belong to up to 10 groups, and groups can have up to 5000 users (soft limit).
Roles: A role is similar to a user but is not uniquely associated with a person. Instead, it is a set of permissions that can be assumed by anyone who needs it — users, AWS services, or even users from another AWS account. Roles have no permanent credentials; they issue temporary security credentials via AWS Security Token Service (STS). This makes roles ideal for cross-account access, EC2 instances accessing S3, or Lambda functions needing permissions.
Policies: Policies are JSON documents that define permissions. They specify what actions are allowed or denied on which resources. There are two types: managed policies (AWS-managed or customer-managed) and inline policies (embedded directly into a user, group, or role). AWS-managed policies are created and maintained by AWS (e.g., AdministratorAccess, ReadOnlyAccess). Customer-managed policies are created by you for your specific needs. Inline policies are used for one-off permissions that should not be reused.
Policy Structure and Evaluation
An IAM policy document contains one or more statements. Each statement has:
Effect: Allow or Deny.
Action: A list of AWS actions (e.g., ec2:StartInstances, s3:GetObject).
Resource: The ARN of the resource the action applies to (e.g., arn:aws:s3:::my-bucket/*).
Condition (optional): Conditions under which the policy applies (e.g., IP address range, time of day).
Example policy that allows listing all S3 buckets:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
}
]
}When a request is made, AWS evaluates all applicable policies (user-based and resource-based) and determines whether to allow or deny. The default is Deny. An explicit Allow overrides the default Deny, but an explicit Deny overrides any Allow. This is called the "Deny override" rule.
Key Configurations and Features
Password Policy: You can set a password policy for your account, including minimum length, requiring uppercase, lowercase, numbers, symbols, and password expiration.
Multi-Factor Authentication (MFA): You can enable MFA for users or the root account. MFA adds a second factor (e.g., a code from a hardware device or virtual app) to the password.
Access Keys: For programmatic access, users have access keys (access key ID and secret access key). These are long-term credentials. Rotate them regularly.
IAM Roles for EC2: You can assign an IAM role to an EC2 instance, allowing applications on that instance to access AWS services without storing keys on the instance.
Cross-Account Roles: You can create a role in one account and allow users from another account to assume it, enabling centralized access management.
IAM Identity Center: Formerly AWS Single Sign-On (SSO), this service allows you to manage user access across multiple AWS accounts and business applications from a single place.
Comparison to On-Premises or Competing Approaches
In traditional on-premises environments, you might have Active Directory (AD) for user management. AD is a directory service that stores user objects and groups, and you assign permissions to network resources. AWS IAM is similar but designed for cloud. A key difference: IAM is not a directory service; it is an identity and access management service. It does not store user profiles beyond credentials and permissions. For enterprise integration, you can federate IAM with your existing identity provider (e.g., AD, Okta) using SAML 2.0 or OIDC. This allows users to sign in with their corporate credentials and get temporary AWS access via roles. Compared to competitors like Azure RBAC or GCP IAM, AWS IAM is more granular (resource-based policies) but can be more complex. The exam focuses on AWS IAM's core components.
When to Use IAM vs Alternatives
Use IAM Users when you have a small number of employees who need direct access to the AWS Management Console or programmatic access. For larger organizations, use IAM Identity Center or federation.
Use IAM Roles for:
EC2 instances that need to access S3, DynamoDB, etc.
Lambda functions that need to write to CloudWatch Logs.
Cross-account access (e.g., a developer in Account A needs to access resources in Account B).
Temporary access for external contractors.
Use IAM Groups to organize users with similar job functions (e.g., Developers, Admins, Auditors).
Use Service Control Policies (SCPs) with AWS Organizations if you need to set permission guardrails across multiple accounts. SCPs are not IAM policies; they are used to define the maximum permissions for accounts in an organization.
Use Resource-Based Policies (e.g., S3 bucket policies, Lambda resource policies) when you want to grant access to a resource directly without requiring the user to have a specific IAM policy. These are evaluated in addition to IAM policies.
Best Practices
Follow the principle of least privilege: grant only the permissions required to perform a task.
Use groups to assign permissions, not individual users.
Enable MFA for all users, especially the root account.
Do not use the root account for daily tasks; create an IAM user with administrative privileges.
Rotate access keys regularly.
Use IAM roles for applications running on EC2, not access keys.
Use AWS CloudTrail to monitor IAM activity.
Create an IAM User
Sign in to the AWS Management Console as the root user or an admin IAM user. Navigate to IAM, choose Users, and click 'Add user'. Enter a username (e.g., 'john.doe'). Select access type: you can enable 'Programmatic access' (generates access keys) and/or 'AWS Management Console access' (creates a password). For console access, you can set a custom password or auto-generated, and optionally require password reset. Click 'Next: Permissions'. At this point, the user has no permissions. You can add the user to a group, copy permissions from an existing user, or attach policies directly. For this step, choose 'Attach existing policies directly' and select 'AmazonS3ReadOnlyAccess' as an example. Click 'Next: Tags' (optional), then 'Review', then 'Create user'. AWS will display the user's access key ID and secret access key (if programmatic access was enabled). Download or copy these; they are shown only once. The user can now sign in to the console using the account ID or alias and the password, or use the access keys via CLI/SDK.
Create an IAM Group
In the IAM console, click 'Groups' under Access Management, then 'Create New Group'. Enter a group name, e.g., 'Developers'. Click 'Next Step'. On the 'Attach Policy' page, you can select one or more managed policies. For example, attach 'AmazonEC2FullAccess' and 'AmazonS3ReadOnlyAccess'. Click 'Next Step' and then 'Create Group'. The group now exists with the attached policies. To add users to the group, go to the group details, click 'Add Users to Group', select the users you want (e.g., the user created earlier), and click 'Add Users'. Now that user inherits the group's permissions. This makes management easier: if you need to change permissions for all developers, you modify the group's policies, and all members are updated automatically.
Create and Attach an IAM Policy
To create a custom policy, go to IAM > Policies > 'Create policy'. You can use the visual editor or the JSON tab. For example, create a policy that allows starting and stopping EC2 instances only in the 'us-east-1' region. In the visual editor, select service 'EC2', actions 'StartInstances' and 'StopInstances', resources 'All resources', and add a condition: 'aws:RequestedRegion' equals 'us-east-1'. Click 'Review policy', give it a name like 'EC2StartStopUSEast1', and create. Now you can attach this policy to a user, group, or role. To attach to a user, go to the user's permissions tab, click 'Add permissions', 'Attach existing policies', select your custom policy, and click 'Next: Review' then 'Add permissions'. The user now has the ability to start/stop instances only in us-east-1. This demonstrates granular control.
Create an IAM Role for EC2
To allow an EC2 instance to access S3, you create an IAM role. Go to IAM > Roles > 'Create role'. Select 'AWS service' as the trusted entity, then choose 'EC2'. This means EC2 can assume this role. Click 'Next: Permissions'. Attach a policy, e.g., 'AmazonS3ReadOnlyAccess'. Click 'Next: Tags', then 'Next: Review'. Give the role a name like 'EC2-S3-Read-Only' and create. Now, when launching an EC2 instance, under 'Configure Instance Details', you can select this role in the 'IAM role' dropdown. Alternatively, you can attach the role to an existing instance by stopping it, selecting the instance, Actions > Security > Modify IAM role. Once attached, any application running on the instance can use the temporary credentials provided by the instance metadata service (IMDS) to access S3. The credentials are automatically rotated. This avoids storing long-term access keys on the instance.
Set Up Cross-Account Access Using a Role
Suppose you have two AWS accounts: Account A (production) and Account B (development). You want a developer in Account B to access an S3 bucket in Account A. In Account A, create a role with a trust policy that allows Account B's users to assume it. Go to IAM > Roles > 'Create role'. Select 'Another AWS account' as the trusted entity, enter Account B's account ID. Optionally, require MFA. Click 'Next: Permissions', attach a policy granting access to the specific S3 bucket (e.g., `s3:GetObject` on `arn:aws:s3:::my-bucket/*`). Name the role 'CrossAccountS3Access'. Note the role ARN. In Account B, the administrator must grant the developer user permission to assume the role. This is done by attaching an inline policy to the user that allows the `sts:AssumeRole` action on the role ARN. The developer can then switch roles in the console or use the AWS CLI with `aws sts assume-role`. This provides secure, temporary access without sharing long-term credentials.
Scenario 1: Startup with 5 Employees
A small startup with 5 employees needs to manage their AWS account. The CEO wants to give each employee access to the console but limit permissions based on job role. The solution: create IAM users for each employee. Group them into 'Developers', 'Admins', and 'Finance'. Attach managed policies: AmazonEC2FullAccess for developers, AdministratorAccess for admins, and AWSBillingReadOnlyAccess for finance. The root account is secured with MFA and used only for account-level tasks like closing the account. All users have MFA enabled. This setup costs nothing for IAM, but the principle of least privilege ensures that a developer cannot accidentally delete the entire infrastructure. Misconfiguration: if the admin attaches AdministratorAccess to everyone, the startup loses security. Instead, they should use groups to manage permissions centrally.
Scenario 2: Enterprise with Federated Access
A large enterprise with 10,000 employees uses Microsoft Active Directory on-premises. They want employees to use their corporate credentials to access AWS. They set up IAM Identity Center (formerly AWS SSO) and configure SAML federation between their AD and AWS. Users sign in to a portal, see the AWS accounts they have access to, and get temporary credentials via role assumption. No IAM users are created for employees; instead, they use IAM roles. This reduces credential management overhead and enhances security because passwords are managed on-premises. Cost: IAM Identity Center is free, but the enterprise pays for the underlying AWS services used. What goes wrong: if the federation trust certificate expires, users cannot sign in. Regular monitoring and automation of certificate renewal is essential.
Scenario 3: Application Using EC2 to Access DynamoDB
A company runs a web application on EC2 instances that reads and writes to a DynamoDB table. Instead of embedding access keys in the application code, they create an IAM role with a policy that allows dynamodb:GetItem and dynamodb:PutItem on the specific table. They attach this role to the EC2 instance at launch. The application uses the AWS SDK, which automatically retrieves temporary credentials from the instance metadata service. This is secure and compliant because no long-term keys are stored on the instance. Misconfiguration: if the role policy grants dynamodb:* on all tables, a compromised instance could access other tables. The fix: restrict the resource ARN to the specific table. Also, ensure the instance metadata service version is IMDSv2 (enforced by default in newer instances) to prevent SSRF attacks that could steal credentials.
What CLF-C02 Tests on This Objective
The CLF-C02 exam (Domain 2: Security and Compliance, Objective 2.2) expects you to understand the core IAM concepts: Users, Groups, Roles, and Policies. Specifically, you need to know:
The difference between authentication (who you are) and authorization (what you can do).
The purpose of each IAM component and when to use it.
The principle of least privilege.
How to secure the root user (MFA, no daily use).
The difference between managed policies and inline policies.
How roles work for EC2 instances and cross-account access.
The default deny and explicit deny override.
Common Wrong Answers and Why Candidates Choose Them
"IAM users are required for every person accessing AWS" — Wrong. You can use federation or IAM Identity Center without creating IAM users. Candidates choose this because they think IAM users are the only way, but the exam tests alternative methods.
"IAM roles have long-term credentials like access keys" — Wrong. Roles provide temporary credentials via STS. Candidates confuse roles with users.
"Policies are attached to resources, not users" — Partially true (resource-based policies exist), but the exam often asks about identity-based policies. Candidates may confuse the two.
"The root user should be used for daily administration" — Wrong. AWS explicitly advises against this. Candidates think the root has full access so it's convenient, but security best practice says otherwise.
Specific Service Names and Terms That Appear on the Exam
ARN (Amazon Resource Name) — a unique identifier for AWS resources.
STS (AWS Security Token Service) — issues temporary credentials for roles.
IAM Policy Simulator — a tool to test policy effects.
IAM Access Analyzer — analyzes resource policies to identify unintended access.
Service Control Policies (SCPs) — not IAM, but often confused with IAM policies.
Tricky Distinctions
Identity-based vs Resource-based policies: Identity-based policies are attached to users, groups, or roles; resource-based policies are attached to resources (e.g., S3 bucket policy). The exam may ask which type is used for cross-account access without roles.
IAM user vs IAM role: A user is a permanent identity with long-term credentials; a role is a temporary identity with no permanent credentials. Roles are used for services like EC2.
Decision Rule for Multi-Choice Questions
When asked about granting permissions, follow this elimination strategy:
If the question involves a person, consider IAM user or federation.
If the question involves an AWS service (EC2, Lambda), use IAM role.
If the question involves temporary access or cross-account, use IAM role.
If the question involves grouping users by job function, use IAM group.
If the question involves setting maximum permissions across accounts, use SCP (not IAM).
Always look for keywords like "temporary," "cross-account," "EC2 instance," "federation" to identify the correct answer.
IAM is a global, free service that controls access to AWS resources.
Users represent people; roles represent permissions for services or temporary access.
Groups simplify permission management by collecting users with similar needs.
Policies are JSON documents with Effect, Action, Resource, and optional Condition.
The default is Deny; explicit Allow overrides default Deny, but explicit Deny overrides any Allow.
Always enable MFA on the root account and avoid using it for daily tasks.
Use IAM roles for EC2 instances instead of storing access keys on the instance.
IAM Identity Center (SSO) is the recommended way to manage access for large organizations.
Service Control Policies (SCPs) set permission boundaries across accounts in AWS Organizations.
The IAM Policy Simulator helps test policy effects before applying them.
These come up on the exam all the time. Here's how to tell them apart.
IAM User
Permanent identity with long-term credentials (password or access keys).
Best for humans who need regular access to AWS.
Can be a member of up to 10 groups.
Cannot be assumed by AWS services directly; you would use a role instead.
Maximum 5,000 users per account (soft limit).
IAM Role
Temporary identity with STS-issued credentials that expire (default 1 hour, max 12 hours).
Best for applications (EC2, Lambda) and cross-account access.
Not a member of groups; permissions are attached directly.
Can be assumed by any trusted entity: users, services, or other accounts.
Maximum 300 roles per account (soft limit).
Mistake
IAM roles are only for humans.
Correct
Roles can be assumed by AWS services (EC2, Lambda, etc.) and even other AWS accounts. They are not limited to human users.
Mistake
Once you create an IAM user, they automatically have access to everything.
Correct
By default, new IAM users have no permissions. You must explicitly attach policies to grant access.
Mistake
Access keys are the same as passwords.
Correct
Access keys are used for programmatic access (CLI, SDK) and consist of an access key ID and secret access key. Passwords are used for console login. They are different credentials.
Mistake
You can attach an IAM role to a user.
Correct
Roles are not attached to users; users can assume a role, but the role is a separate entity. You attach policies to users, not roles.
Mistake
Resource-based policies are the same as identity-based policies.
Correct
Resource-based policies are attached to resources (e.g., S3 bucket) and grant access to principals (users, roles). Identity-based policies are attached to principals and specify what resources they can access. They are evaluated together.
An IAM user is a permanent identity with long-term credentials (password and/or access keys) that represents a person or service. An IAM role is a temporary identity that issues short-term credentials via STS. Roles are assumed by users, services, or other accounts. The key difference: users have persistent credentials; roles have temporary credentials that expire. On the exam, if you see 'temporary' or 'cross-account', think role. If you see 'employee' or 'console access', think user or federation.
Yes, you can attach both managed and inline policies to a group. All users in the group inherit those policies. This is a best practice because it simplifies management. For example, you can have a 'Developers' group with 'AmazonEC2FullAccess' and 'AmazonS3ReadOnlyAccess'. Any user added to this group automatically gets those permissions. The exam emphasizes using groups over individual user policies.
IAM policies are attached to IAM users, groups, or roles and define what actions they can perform on AWS resources. SCPs are used with AWS Organizations to set permission guardrails for accounts in the organization. SCPs do not grant permissions; they define the maximum permissions that an account's IAM policies can grant. For example, if an SCP denies EC2 access, even an IAM policy allowing EC2 will not work. The exam tests that SCPs are not a substitute for IAM policies.
Create an IAM role with a policy that allows the necessary S3 actions (e.g., s3:GetObject) on the bucket. Then, attach that role to the EC2 instance at launch or by modifying the instance's IAM role. The AWS SDK on the instance automatically retrieves temporary credentials from the instance metadata service. This is more secure than storing access keys on the instance. The exam tests this pattern frequently.
The IAM Policy Simulator is a tool that allows you to test the effects of IAM policies before applying them. You can simulate a specific action (e.g., ec2:StartInstances) on a resource and see whether it is allowed or denied based on the policies attached to a user, group, or role. It helps troubleshoot permission issues and validate policy changes. The exam may ask about its use in policy validation.
Yes, by using cross-account IAM roles. You create a role in Account A with a trust policy that allows users from Account B to assume it. Then you grant the role permissions to Account A's resources. Users in Account B can switch to that role (via console or CLI) and access the resources. This is the recommended way for cross-account access. Alternatively, you can use resource-based policies (like S3 bucket policies) that directly grant access to users in another account.
AWS IAM policy evaluation follows a rule: an explicit deny overrides any allow. If a user has one policy that allows an action and another policy that explicitly denies the same action, the result is deny. This is known as the 'Deny override' rule. It ensures that you can always block access, even if other policies allow it. The exam tests this rule in the context of troubleshooting permission issues.
You've just covered AWS IAM — Users, Groups, Roles, Policies — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?