2.2 AWS Identity and Access Management (IAM)

Quick Answer: AWS IAM is a free, global service that controls who (authentication) can do what (authorization) in your AWS account. Core components: Users (people), Groups (collections of users), Roles (temporary permissions for services/apps), and Policies (JSON documents defining permissions). Always follow the principle of least privilege.

IAM Overview

AWS Identity and Access Management (IAM) is one of the most important services on the exam. It lets you securely manage access to AWS services and resources.

Key Facts:

• IAM is free — there is no charge to use it
• IAM is global — not Region-specific (users, groups, roles, and policies apply across all Regions)
• IAM supports MFA (Multi-Factor Authentication) for added security
• IAM gives you centralized control of your account

The Root User

When you create an AWS account, you create a root user with the email and password used to sign up. The root user has complete, unrestricted access to everything in the account.

Root User Best Practices

Tasks That REQUIRE the Root User

• Change account settings (name, email, root password)
• Change or cancel the AWS Support plan
• Close the AWS account
• Restore IAM user permissions if the only IAM admin is locked out
• Configure an S3 bucket for MFA delete
• Change AWS account billing/tax settings and view certain tax invoices

IAM Components

IAM Users

An IAM user represents a person or service that interacts with AWS. Each user has a unique name, credentials (a console password and/or access keys for the CLI/API), and permissions defined by attached policies. Best practice: create one IAM user per person and never share credentials.

IAM Groups

An IAM group is a collection of users that makes permissions easier to manage.

Example groups: Administrators, Developers, Finance, ReadOnlyUsers.

IAM Roles

An IAM role is like a user but is meant to be assumed by whoever or whatever needs it, providing temporary security credentials.

On the Exam: When a question asks how to grant an AWS service (EC2, Lambda) permission to access another service (S3, DynamoDB), the answer is almost always an IAM role — never embedded access keys.

IAM Policies

IAM policies are JSON documents that define permissions — what actions are allowed or denied on which resources.

Policy structure:

• Version — policy language version (currently "2012-10-17")
• Statement — one or more permission statements, each with:
  • Effect — "Allow" or "Deny"
  • Action — the API action(s), e.g., s3:GetObject
  • Resource — the resource(s) by ARN
  • Condition (optional) — when the policy applies

Policy types: AWS managed (pre-built by AWS, e.g., AmazonS3ReadOnlyAccess), customer managed (you create and maintain), and inline (embedded in a single user/group/role, not reusable). An explicit Deny always overrides an Allow.

The Principle of Least Privilege

Least privilege means granting only the minimum permissions needed to perform a task — nothing more. Example: a developer who only needs to read one S3 bucket should have a policy allowing s3:GetObject on that specific bucket, NOT s3:* on all buckets.

Multi-Factor Authentication (MFA)

MFA adds a layer of security by requiring two factors: something you know (password) and something you have (an MFA device).

On the Exam: Always enable MFA on the root account, and treat MFA as a best practice for all IAM users with console access — especially administrators.

IAM Best Practices Summary

1. Lock away the root user — enable MFA, do not use for daily tasks
2. Create individual IAM users — one per person, never shared
3. Use groups to assign permissions — easier than per-user policies
4. Use roles for AWS services — never embed access keys in code
5. Grant least privilege — start minimal, add only as needed
6. Enable MFA everywhere — especially for privileged accounts
7. Rotate credentials regularly
8. Use IAM Access Analyzer — find resources shared with external entities
9. Use AWS Organizations — manage multiple accounts with service control policies