02 AWS IAM Security Review

IAM security is not just about who has access. It is about whether that access is necessary, temporary where possible, governed correctly, and resistant to privilege escalation or credential compromise.

Welcome to the AWS IAM Security Review Runbook.

This runbook builds directly on the IAM themes emphasized throughout the AWS Security – Specialty material, including:

• IAM users

• groups

• roles

• STS

• identity-based policies

• resource-based policies

• session policies

• permission boundaries

• Service Control Policies

• IAM Access Analyzer

• IAM Policy Simulator

• federation

• IAM Identity Center

• cross-account access

• least privilege

• troubleshooting authorization failures

The purpose is to move from:

I understand IAM concepts.

to:

I can perform a structured IAM security review and produce defensible findings.

🎯 Runbook Information

Item	Details
Runbook	AWS IAM Security Review
Difficulty	Intermediate → Advanced
Estimated Time	2–5 hours
Primary Focus	Identity, Authorization & Privilege
Target Roles	IAM Engineer, Cloud Security Engineer, Security Consultant, Cloud Security Architect
Certification Alignment	AWS Certified Security – Specialty
Output	IAM Findings, Risk Ratings, Remediation Plan

🏢 Scenario

You have been asked to review the IAM posture of an AWS environment.

Management is concerned that:

• users may retain unnecessary permissions

• long-term access keys may be widely used

• MFA may not be consistently enforced

• cross-account access may be poorly controlled

• role trust relationships may be too broad

• developers may have privilege-escalation opportunities

• service roles may have excessive permissions

• access reviews may not be performed regularly

Your task is to determine:

Who can access what, why they have access, and whether that access is appropriately controlled.

🎯 Review Objectives

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

• inventory IAM identities

• review workforce access

• assess IAM users

• assess IAM roles

• review trust policies

• evaluate access keys

• review MFA

• evaluate IAM policies

• identify wildcard permissions

• understand effective permissions

• assess permission boundaries

• review cross-account access

• assess federation

• review IAM Identity Center

• identify potential privilege escalation

• use Access Analyzer

• troubleshoot access

• document IAM findings

• recommend remediation

⚠️ Authorization and Scope

Before reviewing IAM, confirm:

• AWS accounts in scope

• Regions where applicable

• Organizations structure

• whether IAM Identity Center is in use

• whether external identity providers are in scope

• whether permission changes are permitted

For production reviews, prefer read-only assessment until remediation has been approved.

🧭 IAM Review Workflow

Use:

Scope
  ↓
Identity Inventory
  ↓
Authentication Review
  ↓
User Review
  ↓
Role Review
  ↓
Policy Review
  ↓
Trust Review
  ↓
Cross-Account Review
  ↓
Privilege Escalation Review
  ↓
Access Analysis
  ↓
Findings
  ↓
Remediation
  ↓
Validation

01 — Understand the Identity Model

Before reviewing individual permissions, understand how people and workloads authenticate.

Determine whether access uses:

• IAM users

• IAM roles

• IAM Identity Center

• SAML federation

• OIDC

• external identity providers

• workload roles

• cross-account roles

🧠 First Question

Ask:

Is this environment designed around long-term identities or temporary role-based access?

The SCS-C02 study guide repeatedly emphasizes the use of roles and temporary STS credentials rather than long-term keys for workloads.

02 — Inventory IAM Users

Create an inventory.

User	Purpose	Console	MFA	Access Keys	Permissions

For each user determine:

• owner

• business purpose

• console access

• MFA status

• active keys

• last-used information

• direct policies

• group membership

🚨 Review Questions

Ask:

Is this user still required?

Could this access be provided through federation?

Is console access necessary?

Are long-term API credentials necessary?

03 — Review MFA

For every human interactive identity, determine whether strong MFA is required and enabled.

🚨 Example Finding

Finding:
Privileged IAM User Without MFA

Severity:
High

Observation:
The user has elevated permissions and interactive console access without MFA.

Risk:
Password compromise could result in privileged AWS access.

Recommendation:
Require MFA and migrate workforce access toward centralized federation where appropriate.

04 — Review Access Keys

For each key review:

• owner

• status

• age

• last used

• services accessed

• business requirement

🚩 Red Flags

Look for:

• unused active keys

• old keys

• keys assigned to humans without clear need

• keys owned by former users

• multiple active keys

• unclear ownership

🧠 Security Principle

Prefer:

Workload
   ↓
IAM Role
   ↓
Temporary Credentials

instead of:

Workload
   ↓
Stored Access Key

05 — Review IAM Groups

If groups are used, review:

• members

• attached policies

• business purpose

• privilege level

Ask:

Are group permissions aligned with job function?

Avoid groups becoming permanent dumping grounds for broad access.

06 — Inventory IAM Roles

Create:

Role	Purpose	Trusted Principal	Permission Level	Last Used

Classify roles into:

• workload roles

• human/federated roles

• cross-account roles

• service-linked roles

• administrative roles

07 — Review Role Trust Policies

For every role ask:

Who can assume this role?

Review:

• AWS principals

• account principals

• services

• federated identities

• conditions

• external IDs where relevant

• MFA requirements where appropriate

🧠 Key Distinction

The SCS-C02 IAM material separates:

Trust Policy
→ Who may assume the role

Permission Policy
→ What the role may do

Both must be secure.

🚨 Example Finding

Finding:
Overly Broad Cross-Account Role Trust

Severity:
High

Observation:
A privileged role trusts an external account without sufficient restrictive conditions.

Risk:
Unexpected principals in the trusted account may be able to assume the role.

Recommendation:
Restrict the trusted principal and add appropriate conditions based on the business access model.

08 — Review Workload Roles

Review roles attached to:

• EC2

• Lambda

• ECS

• other workloads

Ask:

• does the workload need all permissions?

• are resources scoped?

• does it use * unnecessarily?

• could compromise of the workload expose sensitive AWS privileges?

🧠 Blast Radius Thinking

For a workload role, ask:

If this EC2 instance is compromised, what can the attacker do using the instance role?

That question often reveals excessive permissions quickly.

09 — Review Identity-Based Policies

Review:

• AWS managed policies

• customer managed policies

• inline policies

Look at:

Effect
Action
Resource
Condition

10 — Identify Wildcard Actions

Search for patterns such as:

"Action": "*"

or broad action families such as:

"s3:*"
"iam:*"
"ec2:*"

Do not automatically label all wildcard usage as vulnerable.

Determine whether the scope is justified.

11 — Review Wildcard Resources

Look for:

"Resource": "*"

Some AWS actions require it.

But for actions that support resource-level restriction, ask whether access can be narrowed.

12 — Review Policy Conditions

The SCS-C02 guide emphasizes IAM condition keys such as:

• aws:SourceIp

• aws:SecureTransport

• aws:MultiFactorAuthPresent

• principal tags

• request tags

Review whether sensitive permissions could benefit from:

• MFA conditions

• network restrictions

• tags

• resource conditions

13 — Review Explicit Denies

Remember:

Explicit deny is a powerful IAM control.

When reviewing effective access, identify whether denies exist in:

• identity policies

• resource policies

• SCPs

• session policies

• endpoint policies

14 — Review Resource-Based Policies

Where applicable, review resource policies on services such as:

• S3

• SNS

• SQS

• KMS

• Lambda

Ask:

Does this resource trust principals outside the intended boundary?

15 — Review Permission Boundaries

The study guide describes permission boundaries as controls that limit the maximum permissions a user or role can receive.

Review:

• which identities have boundaries

• what ceiling the boundary establishes

• whether delegated administrators can create overly privileged identities

🧠 Important

A permission boundary:

does not grant permissions.

It limits what identity policies can ultimately allow.

16 — Review Service Control Policies

If AWS Organizations is used, review SCPs relevant to the account/OU.

Understand:

IAM Policy
→ May Allow

SCP
→ Defines Organizational Maximum

Explicit SCP Deny
→ Blocks Access

The SCS-C02 guide explicitly states that SCPs restrict permissions but do not grant permissions.

17 — Review Session Policies

Where STS/federation workflows use session policies, determine whether additional restrictions are applied during temporary sessions.

This is especially useful when delegated access needs to be narrower than the role’s full permissions.

18 — Review Cross-Account Access

Inventory:

• roles trusted by other accounts

• resource policies granting external access

• external roles your account can assume

• third-party integrations

📋 Cross-Account Matrix

Source Account	Target Role/Resource	Access Type	Purpose	Risk

🧠 Core Rule

Never solve cross-account access by simply sharing IAM credentials.

The SCS-C02 guide recommends controlled role assumption using STS and resource policies where appropriate.

19 — Review Third-Party Access

For vendors, auditors, or external services, review:

• trusted account

• role permissions

• conditions

• session duration

• external ID where relevant

• logging

• continued business need

20 — Review Federation

If SAML/OIDC federation is used, assess:

• identity provider

• mapped roles

• permission sets

• MFA

• group-to-role mappings

21 — Review IAM Identity Center

Where used, assess:

• user/group assignments

• permission sets

• account assignments

• administrator privileges

• MFA through the identity provider

• inactive assignments

The SCS-C02 study material identifies IAM Identity Center as a preferred multi-account workforce access solution.

22 — Review Administrator Access

Identify identities with:

• AdministratorAccess

• Action: "*"

• broad IAM privileges

• broad Organizations permissions

For each privileged identity document:

Why is this level of access required?

🚨 Finding Example

Finding:
Excessive Administrator Access

Severity:
High

Observation:
Multiple human identities retain permanent administrative permissions.

Risk:
Credential compromise could result in full account compromise.

Recommendation:
Reduce standing administrative access and use controlled temporary privileged roles with MFA and logging.

23 — Review IAM Privilege Escalation Paths

Pay special attention to permission combinations.

Examples include:

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

These permissions are not automatically vulnerabilities.

Risk depends on combinations and resource scope.

24 — Review iam:PassRole

For every principal with iam:PassRole, determine:

• which roles can be passed

• which services can receive them

• how privileged those roles are

🔥 Example Escalation Pattern

Developer
   ↓
ec2:RunInstances
   +
iam:PassRole
   ↓
Privileged EC2 Role
   ↓
Temporary Credentials
   ↓
Higher Privileges

🧠 Critical Question

Can the principal pass a role more privileged than itself?

25 — Review Role Assumption Paths

For sts:AssumeRole, assess:

• target roles

• trust relationships

• conditions

• privilege difference

• cross-account paths

Create an access-path diagram if needed.

User
 ↓
Role A
 ↓
Role B
 ↓
Sensitive Resource

26 — Review IAM Access Analyzer

Use Access Analyzer to identify unintended access where supported.

The SCS-C02 guide specifically identifies Access Analyzer for detecting unintended access and overly permissive policies.

Review findings involving:

• external principals

• cross-account access

• public access

27 — Review IAM Policy Simulator

Where useful, validate policy behavior.

Test relevant actions against:

• users

• roles

The SCS-C02 guide identifies Policy Simulator as an IAM troubleshooting tool.

🧠 Professional Principle

Do not modify policy blindly.

Use:

Understand
  ↓
Simulate
  ↓
Change
  ↓
Validate

28 — Review CloudTrail IAM Events

Search for activity such as:

CreateUser
CreateAccessKey
CreateRole
AttachRolePolicy
PutRolePolicy
AssumeRole
UpdateAssumeRolePolicy

Review:

• principal

• source IP

• time

• changes

• unusual activity

29 — Review IAM Usage

Determine whether identities and permissions are actually used.

Look for:

• inactive users

• inactive keys

• unused roles

• excessive services permitted compared to actual use

💡 Least Privilege Maturity

Least privilege is not a one-time configuration.

It is a continuous process:

Grant
 ↓
Observe Usage
 ↓
Reduce
 ↓
Validate
 ↓
Review Again

30 — Review Credentials in Workloads

Ask whether applications store:

• access keys

• secret keys

• credentials in environment variables

• credentials in code

• credentials in repositories

🚨 Red Flag

Workload access should generally use role-based temporary credentials when supported.

31 — Review Break-Glass Access

If emergency privileged access exists, review:

• when it can be used

• approval

• MFA

• monitoring

• logging

• credential protection

🧠 Security Principle

Emergency access should be:

available when needed

but:

difficult to misuse silently.

32 — Review Separation of Duties

Assess whether one identity can:

• create identities

• grant itself permissions

• modify logs

• disable security controls

• delete evidence

A strong security model separates sensitive duties where practical.

33 — Review Security Service Administration

Review who can disable or modify:

• GuardDuty

• Security Hub

• CloudTrail

• AWS Config

• logging buckets

🚨 High-Risk Pattern

An identity that can both:

Perform Sensitive Activity
+
Disable Security Monitoring

creates increased risk.

34 — Create IAM Findings

Use a standard format.

Finding ID:

Title:

Severity:

Affected Identity:

Observation:

Evidence:

Risk:

Privilege Path:

Recommendation:

Validation:

35 — Example Finding — Unused Access Key

Finding ID:
IAM-001

Title:
Unused Active Access Key

Severity:
Medium

Affected Identity:
legacy-admin-user

Observation:
An active access key has not been used for an extended period.

Risk:
Unused long-term credentials increase attack surface and may remain unnoticed if compromised.

Recommendation:
Validate business need and deactivate/delete the key if no longer required.

36 — Example Finding — Excessive IAM Policy

Finding ID:
IAM-002

Title:
Developer Role Has Broad IAM Permissions

Severity:
High

Observation:
Developer role contains iam:* permissions.

Risk:
The role may be capable of modifying identities and escalating privileges.

Recommendation:
Replace broad IAM permissions with task-specific actions and restrict resources where supported.

37 — Example Finding — Dangerous PassRole Scope

Finding ID:
IAM-003

Title:
Developer Can Pass Privileged IAM Roles

Severity:
Critical / High depending on reachable role

Observation:
Developer role has iam:PassRole against highly privileged roles and can create compatible compute resources.

Risk:
The developer may be able to obtain higher privileges through a workload.

Recommendation:
Restrict iam:PassRole to explicitly approved low-privilege roles and constrain related service actions.

38 — Rate IAM Risk

Use:

Privilege
+
Exposure
+
Credential Type
+
Exploitability
+
Business Impact
=
Risk

🔴 Critical

Potential direct account takeover or unrestricted privilege escalation.

🟠 High

Significant excessive privilege, dangerous trust, or privileged credential weakness.

🟡 Medium

Meaningful access-control weakness.

🔵 Low

Hardening, cleanup, or documentation issue.

39 — Prioritize Remediation

Recommended order:

Active Compromise Risk
        ↓
Privilege Escalation
        ↓
Privileged Authentication
        ↓
Cross-Account Trust
        ↓
Unused Credentials
        ↓
Least Privilege Optimization

40 — Create a Remediation Plan

Example:

Finding	Recommendation	Priority	Owner
Broad admin role	Reduce privilege	Immediate	IAM Team
Missing MFA	Enforce MFA	Immediate	Identity Team
Old access key	Remove key	Short Term	Application Team
Federation gap	Implement Identity Center	Strategic	Platform Team

41 — Validate IAM Remediation

Never assume the change worked.

Validate:

• required access still works

• unauthorized access fails

• workloads still operate

• trust path is correct

• no unexpected privilege remains

🧠 Best Validation Pattern

Test:

what should work

and:

what should not work.

42 — Produce an IAM Access Matrix

Example:

Identity	Resource	Required Access	Actual Access	Gap
App Role	S3 Bucket A	Read	Full S3	Excessive
Analyst	Security Hub	Read	Read	None
Developer	EC2	Manage Dev	Admin	Excessive

43 — Produce a Privilege Map

For complex environments, visualize:

Developer Group
      ↓
Developer Role
      ↓
Can Pass
      ↓
Application Role
      ↓
Accesses
      ↓
Production Data

This makes privilege paths easier to explain.

44 — Prepare the Executive Summary

Keep IAM executive reporting simple.

Example:

The IAM security review identified excessive standing privilege, inconsistent MFA coverage, and unnecessary long-term access keys.

The highest-priority concern is the ability of selected developer identities to access or pass privileged roles.

Immediate remediation should focus on removing privilege-escalation paths, securing privileged authentication, and eliminating unnecessary credentials.

45 — Prepare the Technical Report

Recommended sections:

1. Scope
2. Identity Architecture
3. Authentication Review
4. IAM User Findings
5. IAM Role Findings
6. Policy Findings
7. Cross-Account Access
8. Privilege Escalation Analysis
9. Risk Summary
10. Remediation Plan

🎤 AWS IAM Security Review Interview Questions

Practise answering without notes.

IAM Fundamentals

1. How would you perform an AWS IAM security assessment?

2. Which IAM identities would you review first?

3. Why are IAM roles generally preferred for workloads?

Authentication

4. How would you assess MFA coverage?

5. What risks exist with long-term access keys?

6. How would you handle unused credentials?

Policies

7. How do you review an IAM policy?

8. When is Resource: "*" acceptable?

9. What is an explicit deny?

10. Identity policy vs resource policy?

Roles

11. What is a role trust policy?

12. Trust policy vs permission policy?

13. How would you review cross-account roles?

Advanced IAM

14. What is a permission boundary?

15. What is an SCP?

16. Do SCPs grant permissions?

17. What is iam:PassRole?

18. Why can iam:PassRole create privilege-escalation risk?

19. How would you identify unintended external access?

Troubleshooting

20. How would you troubleshoot AccessDenied?

A structured answer should consider:

Principal
 ↓
Identity Policy
 ↓
Resource Policy
 ↓
Boundary
 ↓
SCP
 ↓
Session Policy
 ↓
Conditions
 ↓
Explicit Deny

🚨 Scenario Interview Question 1

A developer can launch EC2 instances and pass any IAM role in the account. What is the risk?

Discuss:

• role privilege

• PassRole

• workload credentials

• potential escalation

🚨 Scenario Interview Question 2

A third-party vendor requires access to one S3 bucket in your AWS account. How would you design access?

Discuss:

• cross-account role or controlled resource access

• least privilege

• temporary credentials

• trust conditions

• monitoring

Do not recommend sharing AWS access keys.

🚨 Scenario Interview Question 3

An IAM user has AdministratorAccess but has not logged in for six months. What would you do?

Discuss:

• validate ownership

• determine business need

• review access-key usage

• disable/remove unnecessary access

• avoid immediately deleting without validation

🚨 Scenario Interview Question 4

A user receives AccessDenied even though an identity policy clearly allows the action. Why?

Possible areas to investigate:

• SCP

• permission boundary

• resource policy

• explicit deny

• policy condition

• KMS key policy

🧠 Interview Answer Framework

Use:

Identity
   ↓
Authentication
   ↓
Trust
   ↓
Authorization
   ↓
Effective Permission
   ↓
Business Need

💬 Interview Tip

Avoid:

“I would remove admin access.”

A stronger answer:

“I would first determine the user’s required job functions, review effective permissions and actual usage, identify which administrative actions are necessary, design a narrower role, validate the replacement access, and then remove the standing administrator permission.”

That demonstrates controlled remediation.

📁 Portfolio Deliverables

Create sanitized examples of:

• IAM inventory

• MFA review

• access-key review

• role trust review

• policy assessment

• privilege-escalation diagram

• findings

• remediation plan

📝 Resume Examples

Instead of:

Experience with AWS IAM.

Use:

Performed a structured AWS IAM security review covering users, roles, policies, MFA, access keys, trust relationships, cross-account access, permission boundaries, and potential privilege-escalation paths.

Or:

Identified excessive IAM permissions and risky role-assumption paths in a lab environment, then implemented and validated least-privilege remediation.

⭐ Runbook Readiness Check

You should be able to:

• inventory IAM identities

• review MFA

• assess access keys

• evaluate IAM policies

• explain effective permissions

• assess trust relationships

• evaluate cross-account access

• explain permission boundaries

• explain SCPs

• identify privilege-escalation paths

• use Access Analyzer

• troubleshoot authorization

• create defensible IAM findings

The objective is not:

I reviewed every IAM policy.

The objective is:

I understand which identities can reach sensitive privileges, whether that access is justified, and how to reduce unnecessary exposure without breaking the business.

🏆 Runbook Complete

You now have a repeatable methodology for:

Identity Discovery
      ↓
Authentication Review
      ↓
Credential Review
      ↓
Role Trust Review
      ↓
Permission Analysis
      ↓
Privilege Escalation Review
      ↓
Cross-Account Analysis
      ↓
Risk Rating
      ↓
Remediation
      ↓
Validation

This methodology is directly relevant to:

• IAM Engineers

• Cloud Security Engineers

• AWS Security Engineers

• Security Consultants

• Cloud Security Architects

🚀 What’s Next?

IAM determines who can act within AWS.

The next runbook focuses on systematically reviewing where traffic can flow, which workloads are exposed, how segmentation is implemented, and whether AWS network controls follow least privilege.

➡️ Next: AWS Network Security Review Runbook

In the next runbook, you will assess:

• VPC architecture

• public and private subnets

• route tables

• Internet Gateways

• NAT

• Security Groups

• Network ACLs

• VPC endpoints

• peering and Transit Gateway

• public exposure

• Flow Logs

• hybrid connectivity

• network findings

• risk rating

• remediation

• network-security interview scenarios