IAM Fundamentals

Who can do what

Every action in AWS comes down to one question: is this identity allowed to do this thing to this resource? AWS Identity and Access Management, or IAM, is the service that answers it. IAM is where you decide who can sign in to your account and what each person or application is permitted to do once they are in.

This matters because an AWS account starts with a single all-powerful login and nothing else. Real work involves many people and many applications, each needing a different slice of access. IAM is how you hand out those slices safely. It carries a large share of the Security and Compliance domain on the exam, so the building blocks here are worth learning well.

What IAM is

IAM is a web service that controls access to your AWS resources. It does two jobs:

• Authentication confirms who is making a request. When you sign in with a password or an application calls AWS with a key, IAM checks those credentials against an identity it trusts.
• Authorization decides what that identity may do. Once AWS knows who you are, it checks your permissions to see whether the specific action you asked for is allowed.

Two facts about IAM are easy marks on the exam. First, IAM is a global service: the identities you create are not tied to a Region, so you never choose a Region when creating a user or role. Second, IAM itself is free. You pay only for the AWS resources your identities use, not for IAM.

The building blocks

IAM gives you four things to work with. Get these straight and most of the topic falls into place.

IAM users

An IAM user is an identity for one person or one application that needs long-term access to your account. A user can have a password for console sign-in, access keys for programmatic access, or both. Each user is a distinct identity with its own credentials, which is what lets you tell who did what.

IAM groups

A group is a collection of users. You attach policies to the group, and every user in it inherits those permissions. Groups make permissions easier to manage: put your developers in a Developers group, attach the right policies once, and new developers get the same access the moment you add them. A group is not an identity you can sign in as, it has no credentials, and you cannot nest one group inside another.

IAM roles

A role is an identity you create with a set of permissions, but unlike a user it is not tied to one person and has no long-term password or access keys. Instead, a trusted principal assumes the role and receives temporary security credentials for that session. Roles are how you grant access without handing out permanent keys. Common uses include giving an EC2 instance permission to read from S3, letting one AWS account access another, and granting access to users who already have identities outside AWS.

The difference between a user and a role is a frequent exam point. A user is a permanent identity with its own credentials. A role is a temporary hat that a principal puts on, gets short-lived credentials, and takes off again.

IAM policies

A policy is a document, usually written in JSON, that lists permissions. You attach policies to users, groups, or roles to define what they can do. AWS also provides AWS managed policies, ready-made policies for common jobs that you can attach as a starting point, alongside customer managed policies that you write yourself.

A simple policy statement has a few key parts:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::my-example-bucket"
    }
  ]
}

• Effect is Allow or Deny.
• Action lists the operations, like s3:ListBucket.
• Resource names what the actions apply to.

You do not need to write JSON by hand for the exam, but you should recognize these parts and know that Effect is what makes a statement permit or block an action.

How a request is evaluated

When a principal makes a request, AWS works through it in order.

1. Authentication. AWS matches the credentials in the request to a principal it trusts: an IAM user, a role session, or a federated identity.
2. Authorization. AWS gathers every policy that applies and checks whether the action is allowed.

The default answer is no. Access is denied unless a policy explicitly allows it, and an explicit Deny in any policy always wins, even over an Allow. So a request succeeds only when something allows it and nothing denies it.

Identity-based and resource-based policies

Policies come in two broad shapes, and telling them apart helps on the exam.

Identity-based policies say "this identity can do these things." Resource-based policies say "these principals can do these things to me." A role is a special case: it carries both a permissions policy and a trust policy that names who is allowed to assume it.

Exam tips

• IAM controls authentication (who you are) and authorization (what you can do).
• IAM is a global service and is free. You pay only for the resources identities use.
• Four building blocks: users (a person or app), groups (a collection of users), roles (assumable, temporary credentials), and policies (JSON permissions).
• A user has long-term credentials; a role is assumed for temporary credentials. Know this difference.
• Groups have no credentials and cannot be nested.
• Access is denied by default; an explicit Deny always overrides an Allow.
• Identity-based policies attach to users, groups, and roles. Resource-based policies attach to a resource and name the principal.