☁ AWS Cloud Engineer JourneyBeginner → Cloud Practitioner → Solutions Architect

Day 3Security · Lab⏱ 2h

IAM: Who Can Do What

By the end of today you can Create users, groups, roles and policies, read an IAM policy in JSON, and apply the principle of least privilege.

1. First principles: authentication vs authorization

Every request to AWS (a click, a CLI command, code) answers two questions:

  1. Authentication: Who are you? (password, access key, role)
  2. Authorization: Are you allowed to do this to that? (policies)

IAM (Identity and Access Management) is AWS's system for both. It's free and global.

Analogy: a hotel User = a guest with their own ID. Group = "Staff" or "VIP" (rules given to many people at once). Policy = what the keycard opens (Room 204 and the gym, not the manager's office). Role = a uniform you borrow temporarily: a plumber (or an EC2 server) puts on the "maintenance" uniform and gets those keys for a short time, with no permanent card.
User: Amina User: Brian Group: Devs Policy: AmazonS3ReadOnlyAccessAllow s3:Get*, s3:List* on * EC2 server Role: App Policy: write to one S3 bucket people → group → policyservices assume roles
Attach policies to groups and roles, not to individuals.

2. Reading a policy

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

Read it as a sentence: "Allow these actions on these resources." Key rules:

3. Lab: build a read-only teammate

  1. IAM → User groups → Create group ReadOnlyTeam, attach ReadOnlyAccess.
  2. IAM → Users → Create user test-reader (console access), add to ReadOnlyTeam. Note the generated password.
  3. Open a private/incognito window, sign in with the IAM sign-in URL as test-reader. Try to create an S3 bucket. You should get Access denied. Try to list buckets: allowed.
  4. Back as admin, create a custom policy (IAM → Policies → Create → JSON) from the example above for a bucket name of your choice, name it LabBucketRead.
  5. Attach it to test-reader and use the Policy Simulator (IAM → Policy simulator, or the "Simulate" tab) to test s3:PutObject (denied) vs s3:GetObject (allowed).
  6. Create a role: IAM → Roles → Create role → trusted entity AWS service → EC2 → attach AmazonS3ReadOnlyAccess → name ec2-s3-read-role. You'll use it on Day 5.
  7. Cleanup: delete test-reader. Keep the group and role (they cost nothing).
📸 Evidence: the "Access denied" message and the policy simulator result → evidence/day03-access-denied.png, evidence/day03-simulator.png

4. Why roles beat access keys

Access keys are long-lived passwords that people accidentally leak. A role hands out temporary credentials that expire and rotate automatically. When your EC2 server needs S3, attach a role, never paste keys onto the server.

5. Exam notes

Remember

6. Quiz

Q1. An EC2 instance needs to read S3 objects. Best approach?Attach an IAM role with S3 read permissions to the instance.
Q2. A user has an Allow for s3:* and a Deny for s3:DeleteObject. Can they delete?No. Explicit Deny wins.
Q3. What is the default permission for a new IAM user?None (implicit deny).
Q4. Can an IAM group contain another group?No.

7. Checklist