IAM Fundamentals (Users, Groups, Roles, Policies)

The Day Everything Was Root

Imagine your first week at Trailbase, a small startup that runs a hiking app on AWS. The whole company signs in with the same credentials: the root account email and password, taped to a note in the team chat. It works fine, right up until an intern named Theo, trying to clean up a test environment, deletes the production photo bucket. Nobody knows it was Theo. The audit log just says "root did it," because as far as AWS is concerned, everyone at Trailbase is the same all-powerful person.

That failure is exactly what AWS Identity and Access Management (IAM) exists to prevent. IAM answers two questions for every single request that touches your AWS account: authentication (who is making this request?) and authorization (are they allowed to do this?). Everything in this lesson, users, groups, roles, and policies, is a tool for answering those two questions precisely instead of handing everyone the master key.

One more thing before we rebuild Trailbase properly: IAM is a global service. There is no "IAM in eu-west-1." An identity you create exists across every region at once, which is why the exam loves asking about it in scenarios that span regions.

The Cast of Identities

Here is the whole IAM system on one map. Keep it in view as we meet each piece: identities on the left (users, groups, roles), policies in the middle defining what is allowed, and AWS resources on the right receiving the requests.

IAM Users: A Key for Every Human

The first fix at Trailbase is obvious once you name the problem: five people were sharing one identity, so actions could never be traced to a person and permissions could never be tailored to a job. An IAM user is a permanent identity for one human (or, in rare legacy cases, one application). Dana, the founder, creates a user for each teammate, locks the root credentials in a password manager, and from that day on the audit log says theo instead of root.

The root account does not disappear. Dana still needs it for a handful of account-level tasks such as changing the support plan or closing the account, so she protects it with MFA and stops using it for daily work. Everything else now happens through IAM users.

IAM Groups: Permissions at Team Scale

Within a month Trailbase hires four more developers. Dana could attach the same policies to each new user by hand, but hand-copied permissions drift: one developer ends up with an extra permission from an old experiment, another is missing one and files a ticket. An IAM group solves this by being a container for users. Attach the policy to the group once, and every member inherits it. New hire? Add them to Developers and they are productive in one step. Someone moves to the data team? Move their membership, and their permissions follow.

IAM Roles: Identities You Borrow, Not Own

Two new problems appear at Trailbase that users and groups cannot solve cleanly.

First, the app servers on EC2 need to upload hiker photos to S3. The tempting shortcut is to create a user, generate access keys, and paste them into the server's config file. Now a permanent secret lives on every instance, it never expires, and one leaked AMI or committed config file hands an attacker the keys for good.

Second, Priya, an external auditor with her own AWS account, needs read access to Trailbase's logs for two weeks. Creating a permanent user for a temporary outsider is exactly the kind of standing access that least privilege forbids.

An IAM role answers both. A role is an identity with permissions, just like a user, but nobody owns it and it has no permanent credentials. Instead, a trusted party assumes the role and receives temporary security credentials that expire on their own (they are issued by AWS STS, the Security Token Service, which you will meet properly in lesson 4). The EC2 instances assume a role and get short-lived keys that AWS rotates automatically. Priya assumes an auditor role from her own account and loses access the moment the trust is removed.

Every role is defined by two documents, and the exam tests whether you can keep them apart:

1. The trust policy answers who may assume this role.
2. The permissions policy answers what the role can do once assumed.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Read it as a sentence: the EC2 service is allowed to assume this role. Swap the principal for another AWS account ID and you have Priya's cross-account trust policy instead.

IAM Policies: The Language of Permission

Users, groups, and roles are all just identities. None of them can do anything until a policy says so. A policy is a JSON document that states which actions are allowed or denied on which resources, optionally under which conditions. Here is the policy Dana writes so the developers can work with the production photo bucket, but only from the office network:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowPhotoBucketAccess",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::trailbase-photos",
        "arn:aws:s3:::trailbase-photos/*"
      ],
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "192.168.1.0/24"
        }
      }
    }
  ]
}

Walk through it once slowly, because every IAM policy you will ever read has this same skeleton. Version is always the literal string 2012-10-17; treat it as a magic constant. Effect is either Allow or Deny. Action lists the API operations in service:Operation form. Resource pins those actions to specific ARNs; note that the bucket itself and the objects inside it (/*) are different resources, a classic exam trap. Condition narrows when the statement applies at all.

Policies come in several flavors, and knowing which attaches where is easy exam money:

One more distinction the exam leans on: managed policies are standalone objects you can attach to many identities and version over time, while inline policies are embedded in a single identity and die with it. Prefer managed policies; save inline ones for a strict one-to-one relationship you never want reused.

When Policies Collide

Mara, Trailbase's data engineer, sits in two groups. Developers grants s3:GetObject on the photo bucket. A newer DataGovernance policy explicitly denies s3:* on that same bucket while a privacy review is running. Mara requests a photo. What happens?

She is denied, and she would be denied even if ten other policies allowed her. AWS evaluates every policy that applies to a request using three rules, in this order of power:

1. Everything starts as an implicit deny: no policy mentioning you means no access.
2. Any applicable Allow lifts that implicit deny; permissions across your policies are combined with a logical OR.
3. One explicit Deny anywhere trumps every Allow, with no exceptions.

If the account lives inside AWS Organizations, SCPs sit above this whole process as an outer fence: an action an SCP does not permit is unavailable to every identity in the account, including administrators. The full decision flow looks like this:

Trailbase, Rebuilt

Six weeks after the Theo incident, the account looks like a textbook diagram. Every human has an IAM user with MFA. The Developers group carries the day-to-day policies, so onboarding is one action. The EC2 fleet assumes an instance role for S3 uploads, and no server has ever seen a permanent key. Priya audits through a cross-account role that Trailbase can revoke in one click. Root credentials live in a vault and have been used exactly once, to enable MFA on themselves.

Theo still works there. His user can delete anything he likes, as long as it is in the sandbox account.

Common Pitfalls

Quick Reference

arn:aws:iam::account-id:user/user-name
arn:aws:iam::account-id:group/group-name
arn:aws:iam::account-id:role/role-name
arn:aws:iam::account-id:policy/policy-name

Related Services

Further Reading

• AWS IAM User Guide
• IAM Best Practices
• Policy Evaluation Logic
• IAM JSON Policy Reference