Cloud Identity and Access Management Lab

In modern cloud environments, identity is one of the most important security boundaries. Before a user, administrator, application, or service can interact with a cloud resource, the platform must determine who they are and what they are allowed to do.

Welcome to Lab 09 of the CompTIA Cloud+ practical lab sequence.

In the previous labs, you worked with:

• virtual machines
• segmented cloud networks
• routing
• security groups
• DNS
• block, file, and object storage
• storage security

You have protected network paths and data.

Now you will answer a different security question:

Who should be allowed to access those resources?

This lab introduces practical cloud Identity and Access Management — IAM.

You will build:

Identity
   ↓
Authentication
   ↓
Group / Role
   ↓
Policy
   ↓
Authorization
   ↓
Cloud Resource

The objective is not simply:

Create a cloud user.

The objective is:

Understand how cloud identities receive permissions, how least privilege is implemented, how access is validated, and how IAM problems are systematically troubleshot.

🎯 Mission Information

Item	Details
Lab	09 — Cloud Identity and Access Management
Difficulty	Beginner → Intermediate
Estimated Time	75–120 Minutes
Certification Alignment	CompTIA Cloud+
Primary Focus	Cloud IAM
Previous Lab	08 — Secure Cloud Storage
Career Alignment	Cloud Administrator, Cloud Engineer, Cloud Security Engineer
Major Skills	Users, Groups, Roles, Policies, Least Privilege, Authorization
Deliverable	Cloud IAM Model + Access Validation Report

🏢 Scenario

Your organization is expanding its cloud environment.

Until now, a small number of administrators have been using broad privileges to manage resources.

The environment now contains multiple teams:

Cloud Environment
      |
      ├── Cloud Administrators
      |
      ├── Developers
      |
      ├── Security Analysts
      |
      └── Auditors

Each team has different responsibilities.

The requirements are:

Cloud Administrators

Need administrative capabilities for approved cloud infrastructure.

Developers

Need to:

• view development compute resources

• manage selected development workloads

They should not manage:

• organization-wide IAM

• production security controls

• billing

Security Analysts

Need to:

• review security configuration

• access appropriate logs

• investigate security events

They should not normally:

• deploy business applications

• modify billing

• receive unrestricted administrator access

Auditors

Need:

read-only visibility

for selected resources and configurations.

Your manager asks you to create a basic role-based cloud access model.

🎯 Lab Objectives

By completing this lab, you should be able to:

• explain IAM

• distinguish identity from permission

• explain authentication

• explain authorization

• understand cloud users

• understand groups

• understand roles

• understand IAM policies

• interpret allow and deny concepts

• understand least privilege

• create test users or identities

• create groups

• assign permissions through groups or roles

• validate authorized access

• validate denied access

• identify excessive privileges

• understand privilege creep

• review IAM access

• troubleshoot access-denied errors

• document cloud permissions professionally

• explain cloud IAM during interviews

🧠 Why This Lab Matters

Traditional security thinking often focused heavily on:

Internet
   ↓
Firewall
   ↓
Server

Modern cloud environments add another critical layer:

Identity
   ↓
Cloud API
   ↓
Cloud Resources

A user may manage infrastructure without ever directly connecting to the underlying server.

For example:

Cloud Administrator
      ↓
Cloud Console / API
      ↓
Modify Firewall
Delete VM
Create Storage
Change Permissions

That makes cloud IAM extremely powerful.

🔐 Core IAM Model

Think:

WHO
 ↓
Identity

HOW VERIFIED
 ↓
Authentication

WHAT THEY CAN DO
 ↓
Authorization

WHERE THEY CAN DO IT
 ↓
Resource

01 — Understand Identity

An identity represents an entity interacting with the cloud platform.

Examples include:

• user

• administrator

• application

• service

• workload

• external identity

For this lab, you will primarily focus on:

human identities.

Workload identities will be covered in:

Lab 11 — Workload Identity and Service Account Lab

02 — Understand Authentication

Authentication answers:

Who are you?

Examples of authentication methods may include:

• password

• MFA

• certificate

• federation

• token

🧠 Simple Model

Identity
   ↓
Credentials
   ↓
Authentication
   ↓
Identity Verified

03 — Understand Authorization

Authorization answers:

What are you allowed to do?

Example:

A user successfully signs into the cloud console.

Authentication:

SUCCESS

The user attempts to delete a production VM.

Authorization:

DENIED

because the user does not have that permission.

🧠 Authentication vs Authorization

Memorize the distinction conceptually:

Authentication
=
Who Are You?

Authorization
=
What Can You Do?

04 — Understand Cloud Permissions

Cloud permissions commonly represent actions such as:

View VM
Start VM
Stop VM
Create VM
Delete VM
Read Storage
Write Storage
Modify Network
Manage IAM

🧠 Permission Granularity

Broad:

Administrator
 ↓
Everything

More granular:

Developer
 ↓
Start / Stop Development VM

05 — Understand IAM Policies

A policy defines access decisions.

Conceptually:

Identity
   ↓
Policy
   ↓
Action
   ↓
Resource

A policy might conceptually mean:

Allow
Developer Group

To:
View and manage selected development VMs

06 — Understand the Four Key IAM Questions

Whenever reviewing cloud access, ask:

WHO?
 ↓
Identity

CAN DO WHAT?
 ↓
Action

TO WHICH RESOURCE?
 ↓
Resource

UNDER WHICH CONDITIONS?
 ↓
Context

This model becomes extremely important in cloud security.

07 — Understand Least Privilege

Least privilege means:

Give an identity only the permissions required to perform its responsibilities.

Avoid:

Developer
   ↓
Cloud Administrator

if the developer only requires:

Developer
   ↓
Development VM Management

🧠 Least Privilege Model

Job Requirement
      ↓
Required Actions
      ↓
Required Resources
      ↓
Minimum Permission

08 — Understand the Principle of Default Deny

A secure authorization approach generally follows:

No Permission
      ↓
No Access

until the required access is granted.

Do not design:

Allow Everything
      ↓
Remove What Seems Dangerous

Prefer:

Deny by Default
      ↓
Grant Required Access

09 — Review Your Current Identity

Sign into your cloud lab.

Identify:

Current Identity:

Authentication Method:

Role:

Permission Level:

Ask:

Am I currently using a highly privileged administrative identity?

10 — Review Current Administrative Access

Determine what your current identity can do.

Examples:

• manage compute

• modify networking

• modify storage

• change IAM

• view billing

🚨 Important

Having broad access during a learning lab does not mean:

broad access should be standard for enterprise users.

11 — Create an IAM Inventory

Create:

Identity	Type	Purpose	Privilege
Lab Admin	User/Admin	Lab Management	High
Developer Test	User	Development	Limited
Security Test	User	Security Review	Limited
Auditor Test	User	Audit	Read Only

12 — Create a Developer Test Identity

Create an approved test identity.

Example:

cloudplus-developer-01

Do not share this identity with other users.

13 — Create a Security Analyst Test Identity

Example:

cloudplus-security-01

14 — Create an Auditor Test Identity

Example:

cloudplus-auditor-01

🧠 Naming Standard

Use meaningful identity names.

Avoid:

user1
test
temp
abc

where possible.

15 — Understand Groups

Groups simplify permission management.

Instead of:

User A → Policy

User B → Policy

User C → Policy

you can use:

User A
User B
User C
   ↓
Developer Group
   ↓
Developer Policy

🧠 Group Benefit

Groups make access:

• easier to manage

• more consistent

• easier to review

• easier to remove

16 — Create a Developer Group

Example:

cloudplus-developers

17 — Create a Security Group

Example:

cloudplus-security-analysts

18 — Create an Auditor Group

Example:

cloudplus-auditors

19 — Add Users to Groups

Assign:

cloudplus-developer-01
      ↓
cloudplus-developers

cloudplus-security-01
      ↓
cloudplus-security-analysts

cloudplus-auditor-01
      ↓
cloudplus-auditors

20 — Build the IAM Architecture

Your model should resemble:

                  Cloud IAM
                     |
       +-------------+-------------+
       |             |             |
       v             v             v
 Developers       Security       Auditors
       |             |             |
       v             v             v
 Dev Access     Security View    Read Only

21 — Define the Developer Requirements

Document what the developer requires.

Example:

Developer Needs:

View development VMs
Start development VM
Stop development VM
View basic monitoring

Developer does not require:

Manage IAM

Delete production resources

Modify billing

Change security policies

22 — Create the Developer Permission Model

Conceptually:

Developer
   ↓
Development Resources
   ↓
View
Start
Stop

23 — Scope Developer Access to Resources

Where supported, restrict permissions to:

• development environment

• specific project

• specific resource group

• specific tagged resources

🧠 Resource-Level Access

Better:

Developer
   ↓
Development Resources

than:

Developer
   ↓
All Cloud Resources

24 — Define Security Analyst Requirements

The security analyst may require:

View IAM
View Security Configuration
View Logs
View Network Rules
View Security Alerts

but not necessarily:

Delete VM
Modify Billing
Deploy Business Applications

25 — Create the Security Analyst Access Model

Conceptually:

Security Analyst
      ↓
Security Visibility
      ↓
Logs
IAM Review
Security Configuration

26 — Define Auditor Requirements

The auditor requires visibility.

Use:

Auditor
   ↓
Read Only

The auditor should not normally:

• start workloads

• stop workloads

• delete resources

• change configuration

27 — Create Read-Only Access

Apply an appropriate read-only policy or role in your lab.

🧠 Read-Only Principle

Read-only access supports:

Visibility

without:

Modification

28 — Create an IAM Access Matrix

Use:

Role	View	Create	Modify	Delete	IAM Admin
Cloud Admin	✓	✓	✓	✓	✓
Developer	✓	Limited	Limited	Limited/No	✗
Security Analyst	✓	✗	Limited	✗	✗
Auditor	✓	✗	✗	✗	✗

Adjust according to your provider and lab.

29 — Sign In as the Developer

Use a separate browser profile, private browsing session, or another approved method so you do not confuse administrative and test sessions.

🧠 Operational Tip

Always know:

Which identity am I currently using?

Many cloud mistakes happen because an administrator believes they are operating under a different identity or account.

30 — Test Developer Read Access

Attempt to:

• view approved compute resources

• inspect VM configuration

Expected:

allowed.

31 — Test Developer Start/Stop Access

Where your permissions allow it, start or stop an approved lab VM.

Expected:

allowed.

32 — Test Developer IAM Administration

Attempt to access or modify IAM administration.

Expected:

denied.

33 — Test Developer Billing Access

Attempt to access restricted billing administration if your provider’s permission model supports this test.

Expected:

denied or appropriately restricted.

34 — Record Developer Test Results

Action	Expected	Result
View Dev VM	Allow
Start Dev VM	Allow
Stop Dev VM	Allow
Manage IAM	Deny
Modify Billing	Deny

🧠 Important

You are testing:

Authorized Action
      ↓
Allowed

and:

Unauthorized Action
      ↓
Denied

35 — Sign In as the Auditor

Use the auditor test identity.

36 — Test Auditor Read Access

Attempt to:

• view VM

• view network

• view storage

Expected:

allowed.

37 — Test Auditor Modification Access

Attempt a harmless configuration change that should be denied.

For example:

attempt to stop a disposable test VM without confirming the operation if the UI provides a safe authorization check.

Do not disrupt resources unnecessarily.

Expected:

denied.

38 — Test Auditor Resource Creation

Attempt to access the create-resource workflow.

Expected:

denied where access control applies.

39 — Record Auditor Results

Action	Expected	Result
View VM	Allow
View Network	Allow
View Storage	Allow
Stop VM	Deny
Create Resource	Deny
Delete Resource	Deny

40 — Test the Security Analyst Identity

Verify that the security analyst can view appropriate:

• IAM information

• security configuration

• logs

but cannot perform unrelated administrative actions.

41 — Build a Security Analyst Validation Table

Action	Expected	Result
View Security Configuration	Allow
View Logs	Allow
View IAM	Allow/Scoped
Delete VM	Deny
Modify Billing	Deny

42 — Understand Direct User Permissions

Some cloud environments allow permissions to be assigned directly to individual users.

Conceptually:

User
 ↓
Policy

This may be necessary in some situations.

However, large environments often benefit from:

User
 ↓
Group / Role
 ↓
Policy

🧠 Why?

It improves:

• consistency

• auditability

• scalability

43 — Identify Direct Permissions

Review your test identities.

Ask:

Does this user have permissions assigned outside their expected group or role?

44 — Understand Privilege Creep

Privilege creep occurs when users accumulate access over time.

Example:

User Joins Development
      ↓
Developer Access

Later Joins Cloud Project
      ↓
Additional Access

Moves Teams
      ↓
Old Access Never Removed

Eventually:

Too Much Access

45 — Simulate Privilege Creep

In your lab, review what would happen if a test user were added to:

Developers
+
Administrators

Do not keep excessive membership.

🧠 Lesson

Permissions can combine.

Always review:

the identity’s complete effective access.

46 — Remove Unnecessary Group Membership

Return the test user to the correct group.

47 — Understand Effective Permissions

Effective permissions may come from multiple sources:

Direct Permission
+
Group
+
Role
+
Resource Policy
+
Organization Policy

Provider models vary.

🧠 Troubleshooting Question

When someone says:

“I don’t understand why this user can access the resource.”

Review:

all permission sources.

48 — Understand Explicit Deny Concepts

Some policy systems support explicit denies.

Conceptually:

Allow
+
Explicit Deny
=
DENY

The exact evaluation model depends on the provider.

🧠 Important

Always understand your platform’s policy evaluation logic.

49 — Understand Resource Policies

Access can sometimes be granted or restricted at the resource itself.

Example:

Storage Resource
      ↓
Resource Policy
      ↓
Approved Identity

50 — Compare Identity and Resource Policies

Conceptually:

Identity Policy
=
What Can This Identity Do?

Resource Policy
=
Who Can Access This Resource?

51 — Revisit the Storage Lab

Review the secure object storage created in Lab 08.

Ask:

Which identities can currently access it?

52 — Give the Developer Restricted Storage Access

Where appropriate, allow the developer to access only a dedicated lab object-storage location.

Do not grant access to all storage resources.

53 — Validate the Storage Scope

Developer:

Approved Lab Storage
      ↓
ALLOWED

Different protected storage:

Restricted Storage
      ↓
DENIED

🧠 Resource Scoping

This demonstrates:

Same Identity
      ↓
Different Resource
      ↓
Different Authorization Decision

54 — Review IAM for Compute Resources

Ask whether the developer needs permission to:

View VM
Start VM
Stop VM
Delete VM
Change Networking

These are different actions.

Do not group them together automatically.

55 — Separate Operational and Destructive Permissions

Example:

Start / Stop VM

may be reasonable for a developer.

But:

Delete VM

may require stronger controls.

🧠 Destructive Action Principle

Actions such as:

• delete

• change security

• change IAM

• disable logging

deserve careful privilege review.

56 — Understand Role-Based Access Control

RBAC maps permissions to roles.

Conceptually:

Job Function
      ↓
Role
      ↓
Permissions

Example:

Auditor
 ↓
Read-Only Role
 ↓
View Resources

57 — Understand Attribute/Condition-Based Access

More advanced environments may consider context such as:

• department

• device

• network

• time

• resource tag

Conceptually:

Identity
+
Resource
+
Context
      ↓
Access Decision

For Cloud+, understand the principle.

58 — Understand Temporary Access

Not all privileges need to be permanent.

A stronger model may use:

Request
 ↓
Approval
 ↓
Temporary Privilege
 ↓
Task
 ↓
Privilege Removed

This becomes particularly important for administrators.

You will go deeper in:

Lab 10 — Cloud MFA and Privileged Access

59 — Perform an Access Review

Review every test identity.

Ask:

Who Is This?

Why Does the Account Exist?

Which Group?

Which Role?

Which Resources?

What Permissions?

Still Required?

60 — Create an Access Review Table

Identity	Role	Required?	Access Appropriate?	Action
cloudplus-developer-01	Developer	Yes
cloudplus-security-01	Security	Yes
cloudplus-auditor-01	Auditor	Yes

61 — Understand Dormant Accounts

An unused account can still create risk.

Ask:

When was this identity last used?

Cloud environments should have lifecycle processes for:

Create
 ↓
Use
 ↓
Review
 ↓
Disable
 ↓
Delete

62 — Understand Joiner, Mover, Leaver

A common identity lifecycle is:

Joiner
 ↓
Create Required Access

Mover
 ↓
Change Access

Leaver
 ↓
Remove Access

🧠 Security Problem

The Mover stage is often where privilege creep occurs.

Old access must be removed when responsibilities change.

63 — Simulate a Role Change

Imagine:

Developer
      ↓
Moves to Auditor Role

Required action:

Remove Developer Access
      ↓
Add Auditor Access

not:

Keep Developer
+
Add Auditor

64 — Review Authentication Settings

For each identity, review:

• authentication method

• password configuration where relevant

• MFA status

MFA will be explored deeply in the next lab.

65 — Understand Human vs Machine Credentials

Human users should not generally provide their personal credentials to applications.

Avoid:

Developer Credentials
      ↓
Application Script

Prefer dedicated workload identity mechanisms.

66 — Understand API Credentials

Cloud APIs may use:

• tokens

• temporary credentials

• access keys

Long-lived credentials require careful control.

🚨 Never Store Credentials In

• source code

• public repositories

• screenshots

• lab documentation

67 — Review Your Local Lab Files

Check whether any credential information was accidentally stored in:

README.md

scripts

screenshots

configuration files

Remove sensitive information immediately.

68 — Understand IAM Logging

IAM changes should be auditable.

Important events may include:

User Created

User Deleted

Role Assigned

Policy Changed

Group Membership Changed

Authentication Attempt

Permission Changed

69 — Locate IAM Audit Logs

Using your provider’s supported logging capability, identify where administrative IAM activity is recorded.

70 — Perform a Test IAM Change

Make a harmless test change such as:

• add test user to a test group

• remove the user again

71 — Review the Audit Trail

Determine whether you can identify:

Who Made the Change?

What Changed?

When?

Which Identity Was Affected?

Was It Successful?

🧠 Cloud Security Principle

A sensitive IAM change without logging creates a major investigation gap.

72 — Build an IAM Monitoring Scenario

Imagine:

Standard Developer
      ↓
Added to Administrator Role

That event should deserve security attention.

73 — Identify High-Risk IAM Events

Examples include:

• new administrator created

• MFA disabled

• privileged role assigned

• access policy broadened

• security logging disabled

• access key created unexpectedly

74 — Understand IAM as an Attack Surface

A compromised administrator may be able to create:

New Identity
      ↓
Administrative Permission
      ↓
Persistent Cloud Access

IAM changes therefore matter during incident response.

75 — Deliberately Create an Access-Denied Scenario

Using your developer test identity, attempt an operation outside its allowed permissions.

Example:

access IAM administration.

Expected:

ACCESS DENIED

76 — Troubleshoot the Access-Denied Error

Do not automatically grant administrator access.

Use:

Identity
 ↓
Requested Action
 ↓
Target Resource
 ↓
Assigned Groups
 ↓
Roles / Policies
 ↓
Resource Policy
 ↓
Conditions
 ↓
Deny / Allow

77 — Determine Whether Access Is Actually Required

Before changing IAM, ask:

Should this identity be able to perform this action?

This is the most important step.

🧠 Troubleshooting vs Security

A denied request does not always mean:

IAM is broken.

Sometimes:

IAM is working exactly as intended.

78 — Simulate a Legitimate Missing Permission

Choose a harmless lab operation the developer should legitimately perform but temporarily remove that permission.

For example:

View Approved Lab VM

79 — Confirm the Failure

Expected:

access denied.

80 — Review Effective Permissions

Identify the missing permission in the appropriate:

• group

• role

• policy

81 — Restore the Minimum Required Permission

Do not grant:

Administrator

to solve:

Missing View Permission

Grant only what the job requires.

82 — Validate the Fix

The developer should now:

View Approved VM
      ↓
ALLOWED

while still:

Manage IAM
      ↓
DENIED

83 — Document the IAM Troubleshooting Case

Problem:
Developer cannot view approved lab VM.

Identity:

Required Action:

Target Resource:

Observed Error:

Groups:

Roles:

Policies:

Root Cause:

Corrective Action:

Validation:

84 — Troubleshooting Scenario — User Can Log In but Cannot Access VM

Remember:

Authentication
 ✓

Authorization
 ✗

Investigate permissions.

85 — Troubleshooting Scenario — User Has Role but Still Cannot Access Resource

Review:

Correct Role?

Correct Scope?

Correct Resource?

Explicit Deny?

Resource Policy?

Conditions?

86 — Troubleshooting Scenario — User Can Access Too Much

This is potentially more serious than access denied.

Review:

Direct Permissions
+
Group Membership
+
Roles
+
Inherited Access

🧠 Important

Users often report:

“I cannot access something.”

They rarely report:

“I can access far too much.”

Access reviews must proactively identify excessive privilege.

87 — Troubleshooting Scenario — Former Team Member Still Has Access

Review identity lifecycle.

Action may include:

Validate Employment / Role
      ↓
Disable or Remove Access
      ↓
Review Credentials
      ↓
Review Activity

according to organizational procedures.

88 — Troubleshooting Scenario — Application Uses Employee Credentials

Identify this as poor identity architecture.

Recommend moving toward:

dedicated workload identity.

This leads directly into Lab 11.

89 — Troubleshooting Scenario — Administrator Cannot Explain Why Permission Exists

This is a governance issue.

Every privileged permission should ideally have:

• owner

• purpose

• scope

90 — Build the IAM Troubleshooting Framework

Use:

Who?
 ↓
Authenticated?
 ↓
Which Action?
 ↓
Which Resource?
 ↓
Which Group?
 ↓
Which Role?
 ↓
Which Policy?
 ↓
Which Scope?
 ↓
Any Deny?
 ↓
Access Decision

91 — Perform an IAM Security Assessment

Review:

[ ] Every test identity has an owner
[ ] Identity purpose documented
[ ] Groups used where appropriate
[ ] Roles match job responsibilities
[ ] Least privilege applied
[ ] Broad administrator access reviewed
[ ] Direct user permissions minimized
[ ] Dormant identities reviewed
[ ] Resource scope reviewed
[ ] Authentication settings reviewed
[ ] IAM logging available

92 — Build an IAM Findings Register

Finding	Risk	Recommendation	Priority
Developer Has Admin Role	Excessive Privilege	Replace With Scoped Role	High
Dormant Account Active	Unauthorized Access	Disable/Review	High
Direct Permissions	Hard to Manage	Use Group/Role	Medium
No Access Review	Privilege Creep	Implement Periodic Review	Medium
IAM Changes Not Monitored	Limited Visibility	Enable Monitoring	High

93 — Build the Final IAM Architecture

                          Cloud IAM
                              |
        +---------------------+---------------------+
        |                     |                     |
        v                     v                     v
  Administrators          Developers             Auditors
        |                     |                     |
        v                     v                     v
 Privileged Role         Scoped Dev Role       Read-Only Role
        |                     |                     |
        +---------------------+---------------------+
                              |
                              v
                         Cloud Resources
                              |
          +-------------------+-------------------+
          |                   |                   |
        Compute             Storage            Network

You may also include:

Security Analysts
      ↓
Security Read / Investigation Access

94 — Create the IAM Access Matrix

Persona	Compute	Network	Storage	Security Logs	IAM	Billing
Admin	Manage	Manage	Manage	View	Manage	Scoped
Developer	Scoped Manage	View/Limited	Scoped	Limited	No	No
Security Analyst	View	View	View	View	View	No
Auditor	Read	Read	Read	Read	Read	No

95 — Create an Identity Lifecycle Record

For each identity document:

Identity:

Owner:

Purpose:

Created:

Group:

Role:

Resource Scope:

Last Review:

Expiration / Review Date:

96 — Capture Evidence

Capture sanitized evidence of:

• groups

• role assignments

• access matrix

• developer allowed access

• developer denied access

• auditor read-only behavior

• IAM audit event

• access-denied troubleshooting

Never capture:

• passwords

• MFA secrets

• API keys

• access tokens

• private account information

97 — Update the Resource Inventory

Add an IAM section:

Identity / Group	Purpose	Privilege	Status
cloudplus-developers	Development	Scoped	Active
cloudplus-security-analysts	Security Review	Scoped	Active
cloudplus-auditors	Audit	Read Only	Active
cloudplus-developer-01	Test Developer	Scoped	Active
cloudplus-security-01	Test Security Analyst	Scoped	Active
cloudplus-auditor-01	Test Auditor	Read Only	Active

98 — Perform Final Validation

Verify:

Developer
      ↓
Required Development Action
      ↓
ALLOW

Verify:

Developer
      ↓
IAM Administration
      ↓
DENY

Verify:

Auditor
      ↓
View Resource
      ↓
ALLOW

Verify:

Auditor
      ↓
Modify Resource
      ↓
DENY

Verify:

Security Analyst
      ↓
Security Visibility
      ↓
ALLOW

🧪 Final Validation Checklist

Validation	Status
Current administrative identity reviewed
Developer identity created
Security analyst identity created
Auditor identity created
Developer group created
Security group created
Auditor group created
Users assigned to groups
Developer permissions scoped
Auditor read-only access configured
Security analyst access scoped
Authorized action tested
Unauthorized action denied
Resource scope tested
Privilege creep understood
IAM access review completed
Identity lifecycle reviewed
IAM logging reviewed
Access-denied scenario tested
Missing permission corrected with least privilege
Findings documented
IAM architecture diagram created

99 — Cleanup Decision

If continuing the lab sequence, retain the IAM structure where useful.

However, remove unnecessary training identities when they are no longer required.

Review:

Temporary Users

Temporary Roles

Temporary Policies

Temporary Group Membership

Do not leave unnecessary privileged test identities active.

🎯 Certification Connection

A Cloud+ scenario may say:

A user successfully signs into the cloud console but cannot stop a VM.

Think:

Authentication
      ↓
SUCCESS

Authorization
      ↓
CHECK PERMISSION

Another scenario may say:

A developer only needs to restart development servers but has full administrator access.

Think:

Least privilege.

Another:

The same permissions are manually assigned to 50 users.

Consider:

group or role-based access management.

Another:

An employee changes departments but retains previous permissions.

Think:

Privilege creep and identity lifecycle.

🎤 Interview Questions

Practice without notes.

1. What is IAM?

2. Authentication vs authorization?

3. What is a cloud identity?

4. What is an IAM policy?

5. What is a role?

6. What is a group?

7. Why use groups instead of assigning every permission individually?

8. What is least privilege?

9. What is default deny?

10. What is role-based access control?

11. What is resource-level permission?

12. What is effective permission?

13. What is privilege creep?

14. What is an access review?

15. What is a dormant account?

16. What is the joiner-mover-leaver lifecycle?

17. Why are administrator accounts high risk?

18. Why should IAM changes be logged?

19. Why should applications avoid employee credentials?

20. How would you troubleshoot an access-denied error?

21. What is the difference between identity and resource policies?

22. Why might a user have more access than expected?

23. Why is read-only access useful for auditors?

24. Why should destructive permissions be restricted?

25. Why is IAM important in cloud security?

🚨 Scenario Interview Question 1

A developer can sign in but cannot start the development VM.

Use:

Identity
 ↓
Authentication
 ↓
Role / Group
 ↓
Required Action
 ↓
Resource Scope
 ↓
Authorization

🚨 Scenario Interview Question 2

A developer asks for administrator access because one required operation is currently denied.

Do not grant administrator access immediately.

Determine:

Required Action
+
Required Resource
+
Minimum Permission

🚨 Scenario Interview Question 3

An auditor needs to review the cloud environment but must not change anything.

Use:

read-only access.

Validate both:

View
 ↓
ALLOW

and:

Modify
 ↓
DENY

🚨 Scenario Interview Question 4

A user moved from development to finance but still has cloud-development access.

This is:

privilege creep / identity lifecycle failure.

Review and remove obsolete access.

🚨 Scenario Interview Question 5

A user has no direct permission but can still access a resource.

Investigate:

• group membership

• role

• inherited permission

• resource policy

🚨 Scenario Interview Question 6

A user has the expected role but cannot access one storage resource.

Investigate:

Role
 ↓
Resource Scope
 ↓
Resource Policy
 ↓
Explicit Deny
 ↓
Encryption Key if Applicable

🚨 Scenario Interview Question 7

A cloud application stores an employee’s administrative credentials in a configuration file.

Recommend:

a dedicated workload identity or service account with scoped permission.

🚨 Scenario Interview Question 8

The security team discovers a new administrator account created overnight.

Investigate:

Who Created It?
 ↓
When?
 ↓
From Where?
 ↓
Why?
 ↓
Which Permissions?
 ↓
What Activity Followed?

🚨 Scenario Interview Question 9

A former contractor account remains enabled after the project ended.

Review:

• account ownership

• last use

• credentials

• activity

• removal

🚨 Scenario Interview Question 10

Management asks why every cloud user cannot simply have administrator access.

Explain:

• least privilege

• accidental changes

• credential compromise

• accountability

• separation of duties

• blast radius

🧠 IAM Interview Framework

Use:

WHO
 ↓
Identity

HOW
 ↓
Authentication

WHAT
 ↓
Action

WHERE
 ↓
Resource

WHY
 ↓
Business Requirement

HOW MUCH
 ↓
Least Privilege

VERIFY
 ↓
Access Test + Audit

💬 Interview Tip

Avoid:

“If access is denied, I would add permissions.”

A stronger answer is:

“I would first confirm the identity, requested action, target resource, and business requirement. I would review the user’s groups, roles, policies, resource scope, resource policies, and any explicit deny conditions. If access is legitimately required, I would grant the minimum permission necessary and then validate that the required operation succeeds while unrelated privileged actions remain denied.”

That demonstrates Cloud Administrator and Cloud Security Engineer thinking.

📁 Portfolio Deliverables

Keep sanitized versions of:

1. IAM Architecture Diagram

Show:

Users
 ↓
Groups / Roles
 ↓
Policies
 ↓
Resources

2. IAM Access Matrix

Document:

• administrators

• developers

• security analysts

• auditors

3. Least-Privilege Validation

Show:

Required Action
 ↓
Allowed

Unauthorized Action
 ↓
Denied

4. IAM Access Review

Document:

• identity

• role

• privilege

• review decision

5. IAM Troubleshooting Record

Show:

Access Denied
 ↓
Permission Investigation
 ↓
Root Cause
 ↓
Least-Privilege Correction
 ↓
Validation

6. IAM Findings Register

Document excessive privileges and remediation recommendations.

📝 Resume Examples

Instead of:

Worked with cloud IAM.

Use:

Designed and validated role-based cloud IAM for administrators, developers, security analysts, and auditors using groups, scoped permissions, least privilege, resource-level access controls, and access reviews.

Or:

Tested cloud authorization by validating permitted resource operations and denied privileged actions while troubleshooting group, role, policy, resource-scope, and access-control issues.

Or:

Performed cloud IAM security reviews identifying excessive permissions, dormant identities, privilege creep, direct user permissions, and access-governance gaps.

⭐ Job-Readiness Check

You should now be able to:

• explain cloud IAM

• distinguish authentication from authorization

• explain users, groups, roles, and policies

• understand least privilege

• explain default deny

• create scoped identities

• use group-based access

• build a role-access matrix

• distinguish read-only from administrative access

• scope access to specific resources

• validate required access

• validate denied access

• identify excessive privilege

• explain privilege creep

• perform an access review

• understand identity lifecycle

• explain IAM audit logging

• troubleshoot access denied

• troubleshoot excessive access

• document IAM professionally

🏆 Mission Complete

You have added the identity layer to your Cloud+ environment.

Your architecture has progressed from:

Network
+
Compute
+
Storage

to:

Identity
      ↓
Authentication
      ↓
Authorization
      ↓
Cloud Resources

You now understand that cloud access should follow:

Business Requirement
      ↓
Identity
      ↓
Role
      ↓
Minimum Permission
      ↓
Required Resource
      ↓
Validation
      ↓
Periodic Review

The key lesson is:

Cloud IAM is not about giving users access. It is about giving the right identity the right access to the right resource for the right reason—and no more.

🚀 What’s Next?

You now understand how cloud users, groups, roles, and permissions work.

The next lab strengthens the most sensitive part of the identity model:

privileged access.

You will work with:

• multi-factor authentication

• administrator identities

• privileged roles

• separate administrative accounts

• emergency access

• temporary privilege

• access reviews

• privileged-activity monitoring

• compromised-password scenarios

• MFA validation

• privileged-access troubleshooting

You will move from:

Administrator
      ↓
Password
      ↓
Cloud

to a stronger model:

Administrator
      ↓
Strong Authentication
      ↓
MFA
      ↓
Controlled Privileged Role
      ↓
Cloud Resources

➡️ Next: Lab 10 — Cloud MFA and Privileged Access Lab