AWS Certified Cloud Practitioner / Identity and Access Management

IAM Policies Hands On

In this lecture, we’re going deeper into IAM policies and observing how permissions behave in real time inside AWS Identity and Access Management (IAM).

This is where you truly understand how AWS authorization works.

👤 Step 1 – Inspect Current User Permissions

In the left sidebar (as the Root User): go to IAM → Users.

You'll see the user codeveda is in the Admin group. That group has the AdministratorAccess policy attached — so codeveda inherits full admin rights.

In practice, that means:

  • Access to every AWS service

  • No restrictions

  • Can do anything in the account

❌ Step 2 – Remove the User from the Admin Group

Now let's test what happens when you take permissions away.

  1. Go to User Groups

  2. Open the Admin group

  3. Remove codeveda

The moment he's removed, he loses those inherited permissions — instantly. AWS checks permissions in real time, not on a schedule.

Refresh the IAM Users page as codeveda and you'll see:

  • ❌ Access Denied

  • Error naming iam:ListUsers

The takeaway: permissions from a group only exist while you're in that group. Remove the membership, and the access is gone immediately — no delay.

🔧 Step 3 – Fixing Access with a Managed Policy

Let's give codeveda some access back — just enough to look around, not to change anything.

  1. Go to IAM → Users → codeveda

  2. Click Add permissions

  3. Choose Attach policy directly

  4. Select IAMReadOnlyAccess

This policy lets him view and list IAM resources — users, configs, and so on. It does not let him create or change anything.

🔄 Refresh Again

Refresh the console and try again.

  • ✅ You can view users and groups

  • ❌ You can't create a group — that attempt will fail

Why? Read-only means exactly that. Viewing and creating are different permissions, and this policy only grants the first one.

This is least privilege in action: give people only what they need, nothing more.

👥 Step 4 – Adding Multiple Permission Sources

Let's stack a few permission sources on codeveda at once.

Create a new group

  1. Go to User Groups

  2. Create a group called developers

  3. Add codeveda to it

  4. Attach a managed policy — e.g. AlexaForBusinessFullAccess

Add him back to Admin

5. Go to the Admin group and add codeveda again

Now he's picking up permissions from three places at once:

  1. Admin group → AdministratorAccess

  2. Developers group → AlexaForBusinessFullAccess

  3. Direct attachment → IAMReadOnlyAccess

🔎 Inspecting Effective Permissions

Open codeveda's Permissions tab and you'll see all three, listed side by side:

  • AdministratorAccess — via Admin group

  • AlexaForBusinessFullAccess — via Developers group

  • IAMReadOnlyAccess — attached directly

This is permission stacking, visible in one place. A user's total access is just the sum of everywhere they get permissions from:

  • Every group they're in

  • Any policy attached directly to them

📜 Looking at the Policies Themselves

Inspect AdministratorAccess

Go to IAM → Policies → AdministratorAccess. The summary shows access to every AWS service. Switch to the JSON tab and you'll see:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

What this means:

  • "Action": "*" → every API action

  • "Resource": "*" → every resource

Together, that's full admin access.

Inspect IAMReadOnlyAccess

Open this policy and you'll see actions like iam:Get* and iam:List*

About the wildcards: Get* matches any API starting with "Get," List* matches any starting with "List." One line covers many calls — GetUser, GetRole, ListUsers, ListGroups, all allowed. No write actions included.

🏗 Building a Custom Policy

  1. Go to IAM → Policies → Create policy

  2. Choose Visual Editor or JSON Editor

Using the Visual Editor, set:

  • Service → IAM

  • Actions → ListUsers, GetUser

  • Resource → All resources

Name it MyIAMPermissions and create it.

Check the JSON tab afterward — you'll see:

"Action": [
  "iam:ListUsers",
  "iam:GetUser"
],
"Resource": "*"

The point: the Visual Editor is just a friendlier way to write the same JSON. Once created, this policy can attach to users, groups, or roles.

🧹 Cleanup

  1. Delete the developers group

  2. Remove IAMReadOnlyAccess from codeveda

  3. Leave him in the Admin group only

He's back to full admin access with nothing extra attached. Refresh the console to confirm everything still works.