01 AWS IAM Security

IAM is one of the most important security boundaries in AWS. If identity is weak, the rest of your cloud security controls can be bypassed.

Welcome to the AWS IAM Security Lab.

You have already completed the AWS certification learning path and studied concepts such as:

• IAM users

• groups

• roles

• policies

• STS

• temporary credentials

• least privilege

• permission boundaries

• resource policies

• cross-account access

• AWS Organizations

• Service Control Policies

Now you will move from:

I understand IAM

to:

I can assess, configure, troubleshoot, and improve IAM security.

This lab is designed to help you think like a Cloud Security Engineer rather than simply follow console steps.

🎯 Mission Information

Item	Details
Lab	AWS IAM Security
Difficulty	Beginner → Intermediate
Estimated Time	90–150 minutes
Target Roles	Cloud Security Engineer, IAM Engineer, Cloud Engineer, SOC Analyst, Security Consultant
Primary Focus	AWS Identity and Access Management
Certification Alignment	Cloud Practitioner, Solutions Architect Associate, Security Specialty
Career Skill	IAM Security Assessment & Least Privilege
Environment	Personal AWS lab account
Cost	Normally minimal when using IAM-only activities

🧭 Why This Lab Matters

IAM controls:

Who can do what to which AWS resource under what conditions.

Many serious AWS security incidents involve identity problems such as:

• excessive permissions

• leaked access keys

• unused accounts

• poor MFA enforcement

• incorrectly configured trust relationships

• over-permissive roles

• dangerous policy combinations

• privilege escalation paths

A Cloud Security Engineer may be asked:

“Review this AWS account and tell us whether IAM is secure.”

This lab prepares you to answer that question systematically.

🏢 Mission Scenario

You have joined a company as a junior Cloud Security Engineer.

The organization has recently started using AWS.

Several administrators, developers, applications, and automation systems require AWS access.

The environment was created quickly and management is concerned that:

• users may have too many permissions

• MFA may not be consistently configured

• workloads may be using long-term credentials

• policies may contain wildcards

• inactive credentials may still exist

• developers may unintentionally have privilege-escalation paths

Your task is to perform a basic IAM security assessment and improve the environment.

🎯 Mission Objectives

By the end of this lab, you should be able to:

• review AWS IAM identities

• distinguish users from roles

• understand IAM policy structure

• create a least-privilege policy

• create and assume IAM roles

• review trust relationships

• understand temporary credentials

• identify dangerous permissions

• review account password policy

• review MFA status

• identify inactive credentials

• use IAM Access Analyzer

• troubleshoot AccessDenied errors

• understand permission boundaries

• document IAM security findings

📚 Prerequisites

Before beginning, you should understand:

• AWS account fundamentals

• IAM users

• IAM roles

• IAM policies

• AWS Management Console

• least privilege

• authentication vs authorization

Recommended previous learning:

• AWS Certified Cloud Practitioner

• AWS Certified Solutions Architect – Associate

• AWS Certified Security – Specialty IAM sections

⚠️ Lab Safety

Use a dedicated AWS lab environment.

Do not perform these exercises in:

• employer production environments

• customer environments

• shared enterprise accounts

unless you have explicit authorization.

For this lab:

• avoid using the root account for daily activity

• do not publish credentials

• do not commit access keys to GitHub

• remove temporary test resources after completion

🏗️ Lab Architecture

You will create a simple IAM environment.

AWS Account
│
├── Security Administrator
│
├── Developer User
│
├── ReadOnly Role
│
├── EC2 Application Role
│
└── IAM Policies
    │
    ├── Read-Only Policy
    └── Restricted Developer Policy

We will then assess the relationships between:

Identity
   ↓
Policy
   ↓
Action
   ↓
Resource
   ↓
Condition

🧠 IAM Security Mental Model

Before touching AWS, remember:

Principal
   ↓
Requests Action
   ↓
Policy Evaluation
   ↓
Allow / Deny
   ↓
AWS Resource

For every access question, ask:

Who?

Which identity is making the request?

What?

Which AWS API action is requested?

Which resource?

What resource is being accessed?

Under which conditions?

Are there:

• IP restrictions

• MFA requirements

• tags

• VPC restrictions

• time conditions

Is there an explicit deny?

Explicit deny is extremely important during IAM evaluation.

🧪 Task 1 — Review the AWS Root Account

The root user has unrestricted authority over the AWS account.

It should not be used for normal administrative activities.

Step 1

Open:

AWS Console → IAM

Locate the account security recommendations.

Review whether:

• root MFA is configured

• root access keys exist

✅ Desired State

You should aim for:

Root MFA → Enabled

Root Access Keys → None

Daily Administration → IAM / Federated Identity

🔐 Security Analysis

Ask yourself:

Why is root-user compromise more serious than IAM-user compromise?

Because the root user has account-level capabilities that cannot be limited through ordinary IAM policies.

📝 Evidence to Capture

Record:

• root MFA status

• whether root access keys exist

• remediation recommendation if needed

Do not capture or publish sensitive account identifiers.

🧪 Task 2 — Review Account Password Policy

Navigate to:

IAM → Account settings

Review the account password policy.

Check whether controls exist around:

• password length

• complexity

• reuse

• expiration where applicable

🧠 Security Consideration

Password policies alone are not sufficient.

Strong identity security should also include:

• MFA

• federation

• temporary credentials

• least privilege

💡 Professional Tip

Modern enterprise AWS environments often reduce dependence on individual IAM users by using:

• IAM Identity Center

• centralized identity providers

• role-based access

But understanding IAM users is still essential.

🧪 Task 3 — Create a Developer User

Create a controlled user for testing.

Navigate:

IAM → Users → Create user

Use a name such as:

lab-developer

Do not initially assign administrator privileges.

⚠️ Important

Avoid giving:

AdministratorAccess

simply because it is convenient.

This lab is specifically about learning least privilege.

🧪 Task 4 — Create a Least-Privilege Policy

We will create a simple policy that allows read-only access to S3 bucket listings.

Navigate:

IAM → Policies → Create policy

Use the JSON editor.

Example:

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

Name it:

LabS3BucketListPolicy

Attach it to:

lab-developer

🔍 Examine the Policy

Break it down:

Effect
Action
Resource
Condition

Ask:

Why does this particular action require Resource: "*"?

Understanding AWS authorization requirements is important when building real IAM policies.

🧠 Least Privilege Exercise

Now compare the previous policy with:

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

The second effectively grants broad administrative-style capability.

Ask:

Which permissions does the user actually need?

This is the fundamental IAM question.

🧪 Task 5 — Test the Developer Permissions

Sign in as the test identity or use appropriate IAM testing mechanisms.

Try:

• viewing S3 buckets

• opening EC2

• creating an IAM user

• deleting an IAM role

Observe which actions are:

• allowed

• denied

📝 Record Results

Create a simple table.

Action	Expected	Result
List S3 buckets	Allow
Launch EC2	Deny
Create IAM user	Deny
Delete IAM role	Deny

🎯 Key Learning

IAM is based on authorization decisions.

A user can sign in successfully but still receive:

AccessDenied

Authentication worked.

Authorization failed.

🧪 Task 6 — Investigate an AccessDenied Error

Generate an intentional access failure.

For example, attempt an EC2 action using the restricted user.

Read the error carefully.

Then investigate:

• which identity performed the action

• which API permission was required

• whether an Allow exists

• whether an explicit Deny exists

🔎 Troubleshooting Method

Use:

1. Identify Principal
        ↓
2. Identify Requested Action
        ↓
3. Identify Resource
        ↓
4. Review Identity Policy
        ↓
5. Review Resource Policy
        ↓
6. Review Permission Boundary
        ↓
7. Review SCP if applicable
        ↓
8. Review Conditions
        ↓
9. Look for Explicit Deny

This sequence is useful both professionally and during interviews.

🧪 Task 7 — Explore IAM Policy Simulator

Use the IAM Policy Simulator where available/applicable.

Test the developer identity against actions such as:

s3:ListAllMyBuckets
ec2:RunInstances
iam:CreateUser

Observe the evaluation result.

🧠 Why This Matters

Cloud Security Engineers should not modify policies blindly.

Whenever possible:

test → validate → deploy

🧪 Task 8 — Create an IAM Role

Navigate:

IAM → Roles → Create role

Create a role for AWS service use.

Example name:

LabEC2ReadOnlyRole

Choose EC2 as the trusted service where appropriate.

Attach limited read-only permissions needed for your lab scenario.

🔎 Examine the Trust Policy

A role contains an important relationship:

Who can assume this role?

The trust policy answers that question.

The permission policy answers:

What can the role do after being assumed?

These are different controls.

🧠 Interview-Level Concept

Be able to explain:

Trust policy determines who can assume the role.

Permission policy determines what the assumed role can do.

This distinction is fundamental to AWS IAM.

🧪 Task 9 — Understand Temporary Credentials

IAM roles use AWS Security Token Service — STS to issue temporary credentials.

Compare:

Long-Term Access Key
vs
Temporary STS Credentials

Temporary credentials have important security advantages.

They:

• expire automatically

• reduce persistent credential exposure

• work well with roles

• support federation

• support cross-account access

💡 Security Engineer Principle

Whenever a workload needs AWS permissions, ask:

Can I use a role instead of storing access keys?

In many cases, the answer should be yes.

🧪 Task 10 — Review Existing IAM Users

Navigate:

IAM → Users

Review each user.

For every user ask:

• Is this identity still required?

• Is console access required?

• Does it have access keys?

• When were credentials last used?

• Is MFA enabled?

• Does it have excessive permissions?

📋 IAM User Review Worksheet

User	MFA	Console	Access Keys	Permissions	Finding
User 1
User 2

🚨 Common Findings

Possible findings include:

HIGH

User has administrator privileges without business requirement.

HIGH

Active access keys have not been used for a long period.

HIGH

Human account has no MFA.

MEDIUM

User has directly attached broad policies.

LOW

Naming/documentation does not clearly identify owner.

🧪 Task 11 — Review IAM Roles

Navigate:

IAM → Roles

For each role examine:

• trusted principal

• attached policies

• inline policies

• last activity

• purpose

Ask:

Can an unexpected principal assume this role?

Does the role have more permissions than required?

Is this role still used?

🔥 Important Security Area — Trust Relationships

Pay special attention to trust policies.

A weak trust policy may allow unexpected entities to assume privileged roles.

Example risk pattern:

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "*"
  },
  "Action": "sts:AssumeRole"
}

Do not deploy broad trust like this in real environments.

The lesson is:

A secure permissions policy cannot compensate for an unsafe trust relationship.

🧪 Task 12 — Search for Wildcard Permissions

Review policies for patterns such as:

Action: "*"

or:

Resource: "*"

Not every wildcard is automatically insecure.

Some AWS API actions require broad resource syntax.

But ask:

Is the wildcard technically necessary?

Can actions be narrowed?

Can resources be narrowed?

Can conditions reduce exposure?

🧠 Policy Review Method

Use:

Principal
+
Action
+
Resource
+
Condition
=
Effective Permission Intent

🧪 Task 13 — Explore IAM Access Analyzer

Navigate to:

IAM → Access Analyzer

Review available findings or create an analyzer if appropriate for your lab.

Access Analyzer can help identify resources accessible outside the intended trust boundary.

Examples may include:

• S3 buckets

• IAM roles

• KMS keys

• resource policies

🎯 Security Question

Ask:

Is this external access intentional?

External access is not automatically a vulnerability.

The real issue is:

Unintended access.

🧪 Task 14 — Review MFA Coverage

Review all human identities.

Determine:

• which users have MFA

• which users do not

📝 Example Finding

Finding:
IAM User Without MFA

Risk:
Compromised credentials could allow direct console access.

Severity:
High

Recommendation:
Require MFA for interactive identities and prefer centralized federation for workforce access.

🧪 Task 15 — Review Access Keys

For every access key check:

• status

• age

• last used

• service last accessed

• owner

🚨 Red Flags

Look for:

• old unused keys

• two active keys without operational reason

• keys assigned to human users unnecessarily

• unknown ownership

• keys embedded into applications

💡 Security Principle

Prefer:

EC2 → IAM Role

Lambda → Execution Role

ECS Task → Task Role

instead of:

Application → Hardcoded Access Key

🧪 Task 16 — Understand Permission Boundaries

Permission boundaries define the maximum permission ceiling available to a user or role.

Think:

Identity Policy
        ∩
Permission Boundary
        =
Maximum Effective Permissions

A boundary does not automatically grant permissions.

🏢 Enterprise Use Case

Suppose developers are allowed to create roles.

Without guardrails, a developer might create an administrator role.

A permission boundary can help limit the maximum authority of roles they create.

🧪 Task 17 — Review Dangerous IAM Permissions

Certain IAM permissions deserve extra scrutiny.

Examples include:

iam:CreatePolicyVersion
iam:SetDefaultPolicyVersion
iam:AttachUserPolicy
iam:AttachRolePolicy
iam:PutUserPolicy
iam:PutRolePolicy
iam:PassRole
sts:AssumeRole

These permissions are not automatically malicious.

But combinations can potentially create privilege-escalation paths.

🔥 iam:PassRole

This is particularly important.

iam:PassRole allows a principal to pass an IAM role to an AWS service.

Imagine:

Developer
   ↓
Can Launch EC2
   +
Can Pass Admin Role
   ↓
EC2 receives Admin Role

The developer may be able to indirectly use those privileges through the workload.

🧠 Security Review Question

Whenever you see iam:PassRole, ask:

Which roles can this identity pass?

Do not simply ask:

Does it have PassRole?

Scope matters.

🧪 Task 18 — Examine CloudTrail for IAM Activity

Navigate to:

CloudTrail → Event history

Search for IAM-related activities.

Examples:

CreateUser
CreateRole
AttachRolePolicy
CreateAccessKey
DeleteAccessKey
UpdateAssumeRolePolicy

🔎 Security Analysis

Ask:

Who performed the action?

From which IP?

When?

Which resource changed?

Was this expected?

🧠 Security Operations Connection

This is where IAM security connects with SOC and incident response.

A suspicious IAM event may represent:

• administrative activity

• accidental change

• privilege escalation

• persistence

Context determines which.

🧪 Task 19 — Simulate an IAM Security Finding

Create a fictional finding based on your lab.

Example:

Finding ID:
IAM-001

Title:
Developer Role Has Excessive S3 Permissions

Severity:
High

Affected Resource:
LabDeveloperRole

Observation:
Role contains s3:* against all resources.

Risk:
Compromise of the role could permit unauthorized modification or deletion of S3 data.

Recommendation:
Restrict permissions to required actions and specific bucket ARNs.

📊 Risk Classification

Use a simple model.

Critical

Immediate potential for broad account compromise.

High

Significant unauthorized access or privilege escalation.

Medium

Security weakness requiring remediation.

Low

Hardening or governance improvement.

🧪 Task 20 — Create an IAM Security Assessment Table

Document your environment.

Check	Status	Risk	Recommendation
Root MFA
Root access keys
Human MFA
Unused access keys
Administrator policies
Wildcard policies
Role trust policies
Access Analyzer findings
Least privilege
IAM logging

This is much closer to a professional security assessment than simply completing configuration steps.

🔍 Troubleshooting Challenge

A developer tells you:

“I should have access to this S3 bucket, but AWS returns AccessDenied.”

Do not immediately add more permissions.

Investigate.

Step 1

Identify the principal.

Step 2

Identify the exact requested action.

For example:

s3:GetObject

Step 3

Review identity policy.

Step 4

Review bucket policy.

Step 5

Review KMS permissions if the object uses KMS encryption.

Step 6

Check permission boundary.

Step 7

Check SCP.

Step 8

Look for explicit deny.

Step 9

Review CloudTrail.

💡 Professional Tip

One of the worst troubleshooting habits is:

“Give AdministratorAccess and see if it works.”

That may prove the problem is permission-related, but it also creates unnecessary risk and does not identify the root cause.

Troubleshoot systematically.

🚨 Incident Scenario — Compromised IAM Access Key

Imagine GuardDuty or another security mechanism indicates that an IAM access key may have been compromised.

What should you do?

Use:

Validate
   ↓
Contain
   ↓
Investigate
   ↓
Scope
   ↓
Remove Persistence
   ↓
Recover
   ↓
Improve

1. Validate

Determine whether the activity is suspicious.

2. Contain

Disable or rotate the affected credential as appropriate.

3. Investigate

Review CloudTrail.

Look for:

• unusual Regions

• source IPs

• new resources

• IAM modifications

• policy changes

• role assumptions

4. Scope

Determine:

• which resources were accessed

• which data was accessed

• which permissions were used

5. Persistence

Check for:

• new IAM users

• new access keys

• new roles

• changed trust relationships

• policy modifications

6. Recover

Restore secure access.

7. Improve

Improve:

• MFA

• monitoring

• access-key handling

• least privilege

• secrets management

🎤 Interview Preparation

After completing this lab, practise answering these questions without notes.

IAM Fundamentals

1. IAM user vs IAM role?

2. Authentication vs authorization?

3. What is least privilege?

4. What is an IAM policy?

5. Managed policy vs inline policy?

Policy Evaluation

6. What happens if one policy allows an action but another explicitly denies it?

7. Identity policy vs resource policy?

8. What is a permissions boundary?

9. What is an SCP?

10. Does an SCP grant permissions?

Roles & STS

11. What is STS?

12. What is AssumeRole?

13. Why are temporary credentials safer than long-term access keys?

14. Trust policy vs permissions policy?

Security

15. What is iam:PassRole?

16. Why can wildcard permissions be dangerous?

17. How would you review IAM security in a new AWS account?

18. How would you detect unused credentials?

19. How would you secure workforce access across multiple AWS accounts?

Troubleshooting

20. How would you troubleshoot AccessDenied?

A strong answer should consider:

Identity policy
Resource policy
Permission boundary
SCP
Conditions
Explicit deny
KMS policy
CloudTrail

🚨 Scenario Interview Question

A developer can create EC2 instances and also has permission to pass an administrator IAM role. What security concern do you see?

Discuss the potential privilege-escalation path.

A strong candidate should recognize that the developer could potentially launch a workload using the privileged role and then leverage the workload’s credentials.

🧠 Interview Answer Framework

For IAM questions use:

Principal
   ↓
Permission
   ↓
Resource
   ↓
Condition
   ↓
Trust
   ↓
Effective Access

This gives your answers structure.

📁 Portfolio Evidence

After completing this lab, create a sanitized portfolio artifact containing:

Architecture

Simple IAM relationship diagram.

Assessment

IAM security checklist.

Findings

2–5 example findings.

Remediation

Explain how each issue was corrected.

Lessons Learned

Explain:

• least privilege

• role usage

• MFA

• credential management

• logging

📝 Resume Example

Instead of:

Learned AWS IAM.

Use something you can defend:

Performed an AWS IAM security assessment in a lab environment, reviewed users, roles, policies, MFA, access keys, and trust relationships, identified excessive permissions, and implemented least-privilege remediation.

Or:

Built and tested IAM roles and policies, investigated AccessDenied scenarios, and analyzed CloudTrail IAM events to validate authorization behavior.

⭐ Job-Readiness Check

After completing the lab, you should be able to:

• explain IAM users and roles

• create limited IAM policies

• understand policy evaluation

• review IAM identities

• identify excessive permissions

• explain role trust

• understand temporary credentials

• identify dangerous IAM patterns

• review MFA

• review access keys

• troubleshoot basic authorization failures

• document IAM findings

If several of these still feel difficult, repeat the lab.

The goal is not:

I completed the steps.

The goal is:

I can perform an IAM security review without being told every click.

🧹 Lab Clean-Up

After completing your evidence collection:

• remove temporary IAM users

• delete unused roles

• delete temporary policies

• remove test access keys

• ensure no unnecessary credentials remain

Do not remove controls required for your actual AWS learning account security.

🏆 Mission Complete

You have now moved beyond basic IAM definitions.

You have practised:

Identity Review
      ↓
Policy Review
      ↓
Least Privilege
      ↓
Role Security
      ↓
Credential Security
      ↓
Troubleshooting
      ↓
Security Findings
      ↓
Remediation

These are fundamental skills for:

• Cloud Security Engineers

• IAM Engineers

• Cloud Security Consultants

• Cloud SOC Analysts

• AWS Security Architects

🚀 What’s Next?

IAM protects who can access AWS.

The next security layer is understanding how AWS workloads communicate and how network exposure is controlled.

➡️ Next: AWS Network Security Lab

In the next lab, you will work with:

• VPCs

• public and private subnets

• route tables

• Security Groups

• Network ACLs

• internet exposure

• private connectivity

• VPC endpoints

• network-security assessment

• troubleshooting

• network-focused interview scenarios