Identity and Access Management (IAM)

AWS Identity and Access Management (IAM) controls who can do what in your AWS account. On the CLF-C02 exam, IAM shows up constantly: protecting the root user, choosing between users and roles, applying least privilege, and reading a JSON policy. IAM is a global service (not tied to a Region) and is offered at no additional cost.

Core Idea

• IAM defines authentication (who you are) and authorization (what you may do) through users, groups, roles, and policies.
• Follow the principle of least privilege — grant only the permissions a person or service actually needs, and nothing more.
• Protect the root user and enable MFA everywhere it matters — most access should flow through IAM identities, not the root account.

IAM Users, Groups, and Policies

• An IAM user is a long-term identity for one person or application. Users can have a console password (for sign-in) and/or access keys (an access key ID + secret access key for the CLI, SDK, and API).
• An IAM group is a collection of users. You attach policies to the group and every member inherits them — the standard way to manage permissions by job function (Admins, Developers, Auditors). Groups cannot be nested and cannot contain roles or other groups.
• An IAM policy is a JSON document that lists permissions. A policy statement has an Effect (Allow or Deny), an Action (like s3:GetObject), and a Resource (the ARN it applies to). Policies attached to a user, group, or role are called identity-based policies.

The Root User and MFA

• The root user is created when you open the account, logs in with your email address, and has full, unrestricted access to everything including billing and account closure.
• Best practice: do not use the root user for everyday tasks. Create an IAM admin user instead, and lock the root credentials away.
• Enable Multi-Factor Authentication (MFA) on the root user first, and on privileged IAM users. MFA adds a second factor (a one-time code from a device) on top of the password, so a stolen password alone is not enough.
• A few tasks require the root user (for example, changing the account name/email, closing the account, or changing certain support plans).

IAM Roles

• An IAM role grants temporary permissions and is not tied to one person or to long-term credentials. An identity assumes a role and receives short-lived credentials.
• Roles for AWS services: give an EC2 instance, Lambda function, or other service permission to call AWS APIs by attaching a role — never by storing access keys on the instance.
• Cross-account access: a role in Account A can be assumed by users in Account B, enabling controlled access without duplicate users.
• Identity federation and SSO: roles let users from an external identity provider (corporate directory, SAML, or IAM Identity Center) sign in and assume permissions without a separate IAM user. This is how single sign-on works on AWS.

How Policy Evaluation Works

• Default is implicit deny — if nothing explicitly allows an action, it is denied.
• An explicit Allow grants access.
• An explicit Deny always wins — it overrides any Allow, no matter how the Allow was granted. This is the single most tested rule.
• Permissions are the union of all applicable policies, then filtered by any explicit Deny.

High-Yield Exam Patterns

• "Grant an EC2 instance / Lambda access to S3" → attach an IAM role, not access keys.
• "Best practice for the root account" → enable MFA and stop using it for daily work.
• "A user needs the fewest permissions to do the job" → principle of least privilege.
• "Temporary or cross-account access" → IAM role (assume role), never a shared user.
• "An Allow and a Deny both apply — what happens?" → the explicit Deny wins.
• "Manage permissions for many users efficiently" → attach policies to an IAM group.

Common Traps to Avoid

• Confusing users (long-term, one person) with roles (temporary, assumable) — services use roles.
• Thinking an Allow can override a Deny — it never can; explicit Deny always wins.
• Embedding access keys in code or on an EC2 instance instead of using a role.
• Assuming IAM is Regional — it is a global service.
• Using the root user for routine administration instead of a dedicated IAM identity.