AWS Identity & Access Management

AWS CLF-C02 — Domain 2: Security & Compliance

IAM Overview

IAM stands for Identity and Access Management
It is a Global Service — not Region-specific
IAM is used to manage who (authentication) can do what (authorization) in your AWS account
Free to use — no charges for IAM itself
When you first create an AWS account, you start with a root user

Key Point:

IAM is a global service. Users, groups, roles, and policies you create are available across all AWS Regions.

IAM Components

Users

Represent a person or application that interacts with AWS
Each user has a unique name within the AWS account
Users can have console access (password) and/or programmatic access (access keys)
Best practice: create individual IAM users, never share credentials

Groups

A collection of IAM users — lets you manage permissions for multiple users at once
A user can belong to multiple groups
Groups cannot contain other groups (no nesting)
Groups are not identities — you cannot reference a group in a resource policy's Principal

Roles

An IAM identity with permissions that can be assumed by anyone who needs it
Used to grant permissions to AWS services (e.g., EC2, Lambda)
Also used for cross-account access and federated users
Roles have no long-term credentials — they use temporary security tokens via STS
Common roles: EC2 Instance Role, Lambda Execution Role, CloudFormation Role

Policies

JSON documents that define permissions (what actions are allowed/denied on what resources)
Policies are attached to users, groups, or roles
Follow the principle of least privilege — grant only the permissions needed

Exam Tip:

"How do you grant an EC2 instance permission to access S3?" → Create an IAM Role and attach it to the EC2 instance. Never use access keys on an EC2 instance.

Root User vs IAM User

Feature	Root User	IAM User
Created when	AWS account is first created	Created by root or IAM admin
Access	Full, unrestricted access to everything	Only what policies allow
Can be restricted	No — cannot be limited by IAM policies	Yes — controlled by policies
Best practice	Lock it away, enable MFA, don't use for daily tasks	Use for everyday tasks

Tasks Only the Root User Can Do

Change account settings (account name, email, root password)
Close the AWS account
Change or cancel the AWS Support plan
Register as a seller in the Reserved Instance Marketplace
Enable MFA on the S3 bucket for delete operations (MFA Delete)
Restore IAM user permissions (if accidentally removed)
Configure an S3 bucket to enable MFA Delete

Exam Tip:

If a question asks what can ONLY be done by the root user, remember: closing the account, changing support plans, and configuring MFA Delete on S3 are root-only tasks.

IAM Policy Structure (JSON)

An IAM policy is a JSON document with these key elements:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadAccess",
      "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"
        }
      }
    }
  ]
}

Element	Description	Required?
`Version`	Policy language version. Always use `"2012-10-17"`	Yes
`Statement`	Array of individual statements (permissions)	Yes
`Sid`	Statement ID — optional identifier for the statement	No
`Effect`	`"Allow"` or `"Deny"`	Yes
`Action`	List of API actions the policy allows or denies	Yes
`Resource`	ARN of the resource(s) the actions apply to	Yes
`Condition`	Conditions for when the policy is in effect	No

Key Point:

An explicit Deny always overrides an Allow. If any policy denies an action, it is denied regardless of any Allow statements.

IAM Policy Types

Type	Description	Use Case
AWS Managed Policies	Pre-built policies created and maintained by AWS	Common use cases (e.g., `AmazonS3ReadOnlyAccess`)
Customer Managed Policies	Policies you create and manage yourself	Custom, fine-grained permissions specific to your needs
Inline Policies	Policies embedded directly in a single user, group, or role	Strict one-to-one relationship; deleted when the entity is deleted

Exam Tip:

AWS recommends using Customer Managed Policies over inline policies because they are reusable and easier to manage. AWS Managed Policies are great starting points but may be overly permissive.

Multi-Factor Authentication (MFA)

MFA adds an extra layer of security beyond just a password: something you know (password) + something you have (MFA device).

MFA Type	Description
Virtual MFA Device	Apps like Google Authenticator, Authy, or Microsoft Authenticator. Supports multiple tokens on a single device.
Universal 2nd Factor (U2F) Security Key	Physical device like YubiKey. Supports multiple root and IAM users with a single key.
Hardware Key Fob MFA	Physical token device (e.g., Gemalto). Generates a 6-digit code.
Hardware Key Fob for GovCloud	Special key fob provided by SurePassID for AWS GovCloud (US).

Exam Tip:

MFA should be enabled on the root account and all IAM users with console access. This is a critical best practice and frequently tested.

Access Keys vs Console Password

Feature	Console Password	Access Keys
Used for	AWS Management Console (web browser)	AWS CLI & SDK (programmatic access)
Components	Username + password (+ optional MFA)	Access Key ID + Secret Access Key
Generated by	Set during user creation	Generated separately; can only be viewed once
Security	Can enforce password policy	Treat like passwords — never share or commit to code

Key Point:

Access keys are not the same as a password. A user can have up to two active access keys. The Secret Access Key is shown only once at creation — if lost, you must create new keys.

IAM Security Tools

Tool	Scope	Description
IAM Credentials Report	Account-level	Lists all IAM users and the status of their credentials (passwords, access keys, MFA). Useful for auditing.
IAM Access Advisor	User-level	Shows the services a user has accessed and when they last accessed them. Helps you identify and remove unused permissions.

Exam Tip:

"Which tool helps you identify unused permissions?" → IAM Access Advisor. "Which tool provides a credential audit for all users?" → IAM Credentials Report.

IAM Best Practices

Don't use the root account except for AWS account setup — create IAM users instead
One physical user = one IAM user — never share credentials
Assign users to groups and manage permissions at the group level
Use strong password policies (length, complexity, rotation)
Enable MFA for root and all privileged users
Use IAM Roles for AWS services and applications (not access keys)
Use Access Keys for CLI/SDK but never share them
Apply least privilege principle — grant only the minimum permissions needed
Audit permissions regularly using IAM Credentials Report and Access Advisor
Never store credentials in code — use IAM roles, environment variables, or Secrets Manager

Key Point:

The Principle of Least Privilege means giving a user only the access they need to perform their job — nothing more. This is the single most important IAM best practice.