01 Azure Network Security

Welcome to the Azure RBAC Lab.

You have already completed the Azure certification sequence and studied:

Microsoft Entra ID
Azure subscriptions
resource groups
Azure RBAC
least privilege
Owner
Contributor
Reader
managed identities
privileged access
governance

Now you will move from:

I understand Azure RBAC

to:

I can assess, configure, troubleshoot, and improve Azure authorization.

This lab is designed to help you think like an:

Azure Security Engineer
Cloud Security Engineer
IAM Engineer
Azure Administrator
Cloud Security Consultant

🎯 Mission Information

Item	Details
Lab	Azure RBAC
Difficulty	Beginner → Intermediate
Estimated Time	90–150 minutes
Primary Focus	Azure Authorization & Least Privilege
Target Roles	Azure Security Engineer, IAM Engineer, Cloud Engineer
Certification Alignment	AZ-104, AZ-500, SC-300
Career Skill	RBAC Security Review & Access Troubleshooting
Environment	Personal Azure lab subscription
Cost	Minimal when using RBAC-only exercises

🏢 Mission Scenario

You have joined an organization as a junior Cloud Security Engineer.

The company has several Azure teams:

platform administrators
application developers
security analysts
auditors
automation workloads

The environment was built quickly.

Management is concerned that:

users may have excessive privileges
Owner access may be too widely assigned
roles may exist at overly broad scopes
old assignments may still exist
application identities may have unnecessary access
administrators may troubleshoot by granting more permissions instead of finding the real problem

Your task is to perform a structured Azure RBAC review and implement least-privilege improvements.

🎯 Mission Objectives

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

explain Azure RBAC
distinguish Azure RBAC from Microsoft Entra roles
understand Azure RBAC scope
review inherited permissions
assign built-in roles
explain Owner vs Contributor vs Reader
implement least privilege
review role assignments
understand custom-role concepts
assess managed identities
troubleshoot authorization failures
identify excessive access
create professional RBAC findings
document remediation

📚 Prerequisites

Before starting, you should understand:

Microsoft Entra ID basics
Azure subscriptions
resource groups
Azure resources
authentication vs authorization
least privilege

Recommended previous learning:

AZ-900
AZ-104
AZ-500
SC-300

⚠️ Lab Safety

Use:

your own Azure lab tenant/subscription
approved training resources
test users and resource groups

Do not modify access in:

employer production subscriptions
customer environments
shared enterprise tenants

unless you have explicit authorization.

🧠 Azure RBAC Mental Model

Azure RBAC determines:

Which security principal can perform which actions at which Azure scope.

Think:

Security Principal
       ↓
Role Definition
       ↓
Scope
       ↓
Role Assignment
       ↓
Effective Access

For every access question ask:

Who?

Which identity is requesting access?

What?

Which role or permissions are involved?

Where?

At what scope?

Inherited?

Did access come from a higher scope?

Necessary?

Does the identity actually need that level of access?

🧭 Azure RBAC Scope Hierarchy

Understand:

Management Group
      ↓
Subscription
      ↓
Resource Group
      ↓
Resource

Assignments at higher scopes can flow downward.

For example:

Contributor
at Subscription
      ↓
All Resource Groups
      ↓
Resources

This is powerful.

It is also why overly broad assignments can create significant risk.

🧪 Task 1 — Review Your Azure Subscription

Navigate to:

Azure Portal → Subscriptions

Open your lab subscription.

Review:

subscription name
subscription ID
tenant
Access control (IAM)

Do not publish your subscription ID in portfolio screenshots.

🧪 Task 2 — Review Existing Role Assignments

Open:

Subscription → Access control (IAM) → Role assignments

Review:

users
groups
service principals
managed identities
roles
scope

Create an inventory.

Principal	Type	Role	Scope	Expected?

🧠 Review Question

Ask:

Why does this identity have access at this scope?

If the answer is:

“We are not sure.”

that access deserves review.

🧪 Task 3 — Understand Owner, Contributor, and Reader

Review the built-in roles.

Reader

Can view Azure resources.

Contributor

Can create and manage resources, but does not have the same broad access-management capability as Owner.

Owner

Has broad resource management and access-management authority.

🧠 Security Impact

Think:

Reader
→ Observation

Contributor
→ Resource Management

Owner
→ Resource Management + Access Control

Owner therefore deserves much greater scrutiny.

🚨 Common Finding

User:
application-developer

Role:
Owner

Scope:
Subscription

Actual Need:
Manage application resources in one resource group

This is a classic least-privilege problem.

🧪 Task 4 — Create a Dedicated Lab Resource Group

Create:

ghc-rbac-lab-rg

Use it for access testing.

This allows you to practise without granting access across the entire subscription.

🧪 Task 5 — Create or Select a Test User

In Microsoft Entra ID, create or select a controlled test identity.

Example:

ghc-rbac-developer

Do not give it broad Azure access initially.

🧪 Task 6 — Assign Reader at Resource Group Scope

Navigate:

Resource Group → Access control (IAM) → Add role assignment

Assign:

Role:
Reader

Principal:
ghc-rbac-developer

Scope:

ghc-rbac-lab-rg

✅ Expected Result

The user should be able to:

view resources in the resource group

but not:

create resources
delete resources
change access

🧠 Key Learning

The role is only half the decision.

The scope matters just as much.

🧪 Task 7 — Test Reader Access

Attempt:

view the resource group
view resources
create a storage account
create a VM
change IAM

Record:

Action	Expected	Actual
View resource group	Allow
Create resource	Deny
Delete resource	Deny
Change IAM	Deny

🎯 Security Principle

Successful authentication does not mean the user can perform every Azure action.

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to do?

🧪 Task 8 — Upgrade the Test User to Contributor

Replace or add Contributor access at the resource-group scope.

Now test:

create resource
modify resource
delete resource
assign role

🧠 Compare

Contributor should be able to perform more resource-management activity than Reader.

But this still should not automatically mean the user can manage all RBAC assignments.

🧪 Task 9 — Compare Contributor at Two Scopes

Compare:

Contributor
at Resource Group

with:

Contributor
at Subscription

Ask:

Which is more appropriate for an application developer managing one workload?

Usually the narrower scope is safer.

🧠 Least Privilege Formula

Use:

Required Role
+
Minimum Required Scope
=
Better RBAC Design

🧪 Task 10 — Review Inherited Permissions

Go to:

Resource → Access control (IAM)

Review effective assignments.

You may see permissions inherited from:

resource group
subscription
management group

🧠 Important

A user may not have a direct assignment on a VM but still have access because Contributor was assigned at the subscription.

Always investigate inheritance.

🧪 Task 11 — Create an Inheritance Example

Assign a test user:

Reader
at Subscription

Then inspect a resource deep in the hierarchy.

Observe that access is inherited.

🔥 Security Risk

Broad assignments at high scopes can silently grant access to:

future resource groups
future workloads
newly created sensitive resources

This is why scope governance matters.

🧪 Task 12 — Review Group-Based Access

Create or use a group such as:

ghc-app-developers

Add your test user.

Assign the group:

Contributor
at ghc-rbac-lab-rg

🧠 Why Groups Help

Instead of:

User A → Contributor
User B → Contributor
User C → Contributor

use:

Users
  ↓
Group
  ↓
Contributor

This improves:

administration
onboarding
offboarding
access reviews

🚨 Group Security Question

Ask:

Who can modify membership of this group?

A privileged group with weak membership controls can create indirect privilege escalation.

🧪 Task 13 — Review Azure RBAC vs Entra Roles

This distinction is critical.

Microsoft Entra Roles

Control directory-level activities.

Examples may involve:

users
groups
directory configuration

Azure RBAC Roles

Control Azure-resource actions.

Examples:

VMs
storage
networks
resource groups

🧠 Interview Essential

A user can be:

Global Administrator in Entra

and that does not automatically mean:

Owner of every Azure resource

These are different authorization systems.

🧪 Task 14 — Review High-Privilege Role Assignments

Search for principals with:

Owner
User Access Administrator
other highly privileged resource roles

Create:

Principal	Role	Scope	Business Need	Risk

🚨 High-Risk Pattern

Human User
   ↓
Owner
   ↓
Subscription
   ↓
Permanent

requires justification.

🧪 Task 15 — Review Service Principals

Open role assignments and identify application/service-principal identities.

For each ask:

what application owns this identity?
what role does it have?
at what scope?
is that permission still needed?
does it use stored secrets?

🧠 Security Principle

Non-human identities should receive the same level of scrutiny as users.

Sometimes more.

🧪 Task 16 — Review Managed Identities

If you have an Azure resource with a managed identity, review its RBAC assignments.

Example architecture:

Azure VM / App
      ↓
Managed Identity
      ↓
Storage / Key Vault

💡 Why Managed Identity Matters

Managed identities can reduce the need to store:

client IDs
passwords
secrets
long-term credentials

🧠 Workload Access Question

Ask:

What is the minimum role this workload needs?

Do not give:

Contributor at Subscription

to an application that only needs:

read one storage account

🧪 Task 17 — Create a Workload Least-Privilege Scenario

Imagine a managed identity only needs read access to one storage resource.

Compare:

Option A

Contributor
at Subscription

Option B

A storage-specific read role at the required resource scope.

Document why Option B better follows least privilege.

🧪 Task 18 — Review Custom Role Concepts

Azure supports custom roles for cases where built-in roles do not fit the requirement.

Do not create custom roles simply because you can.

Use them when:

built-in role is too broad
built-in role is missing necessary permissions
the organization has a clear repeatable requirement

🧠 Custom Role Design Principle

Start with:

What exact operations are required?

not:

Which actions should we add until the application works?

🧪 Task 19 — Review Role Definitions

For a built-in role, inspect:

actions
notActions
dataActions where applicable
assignable scopes

🧠 Important

Role names are useful summaries.

The actual permissions matter more.

🧪 Task 20 — Troubleshoot an Authorization Failure

Create a controlled failure.

Scenario:

ghc-rbac-developer can view a VM but cannot start it.

Use:

Identity
   ↓
Role Assignment
   ↓
Scope
   ↓
Role Definition
   ↓
Required Action
   ↓
Effective Permission

Step 1 — Confirm Identity

Which user/group/service principal is making the request?

Step 2 — Confirm Resource

Which resource is affected?

Step 3 — Check Role Assignment

Which role applies?

Step 4 — Check Scope

Is the assignment:

resource
resource group
subscription?

Step 5 — Inspect Permission

Does the assigned role contain the required management action?

Step 6 — Check Inheritance

Is there another inherited role?

Step 7 — Check Other Controls

Depending on the scenario, investigate:

policy
PIM activation
Conditional Access
resource-specific restrictions

💡 Troubleshooting Principle

Do not solve:

Access denied

by immediately assigning:

Owner.

That hides the real problem and increases risk.

🧪 Task 21 — Troubleshoot Scope Confusion

Scenario:

User has Contributor but still cannot manage a resource in another resource group.

Investigate the role scope.

If Contributor exists only on:

ghc-rbac-lab-rg

it should not automatically grant Contributor permissions elsewhere.

🧠 Interview-Level Lesson

Always answer RBAC questions with:

role + scope.

Not role alone.

🧪 Task 22 — Review PIM Concepts

If your licensing and environment support Privileged Identity Management, review how privileged access can be made:

eligible
temporary
approval-based
time-bound

If you cannot configure PIM in the lab, design the workflow conceptually.

User
 ↓
Eligible Role
 ↓
Activation
 ↓
MFA / Approval
 ↓
Temporary Privilege
 ↓
Expiration

🚨 Security Benefit

This reduces:

standing privilege.

🧪 Task 23 — Identify Standing Privilege

Review your role assignments and identify human identities with broad permanent roles.

Classify:

required permanent
could be reduced
could be temporary
unknown

📋 Privileged Access Review

Identity	Role	Scope	Permanent?	Recommendation

🧪 Task 24 — Review Access at Resource Scope

Select a sensitive test resource.

Review:

Access control (IAM)

Ask:

who can read it?
who can modify it?
who can delete it?
who can change access?

🧠 Security Review Question

The most important question is often not:

Who has access directly?

It is:

Who has effective access after inheritance is considered?

🧪 Task 25 — Review Unnecessary Assignments

Look for:

old users
disabled users
unused service principals
old project groups
overly broad roles
duplicate assignments

🚨 Common Finding

Former Project Group
   ↓
Contributor
   ↓
Production Resource Group

If the project ended months ago, access should be reviewed.

🧪 Task 26 — Create an RBAC Access Matrix

Document:

Identity	Resource/Scope	Required Access	Actual Access	Gap
Developer	App RG	Contributor	Contributor	None
Auditor	Subscription	Reader	Owner	Excessive
App Identity	Storage	Read	Contributor	Excessive

This is excellent professional evidence.

🧪 Task 27 — Create a Finding: Excessive Scope

Example:

Finding ID:
RBAC-001

Title:
Developer Assigned Contributor at Subscription Scope

Severity:
High

Affected Identity:
ghc-rbac-developer

Observation:
The user supports a single application but has Contributor access across the subscription.

Risk:
Compromise or misuse of the identity could impact unrelated workloads across the subscription.

Recommendation:
Reduce assignment to the required application resource group.

🧪 Task 28 — Create a Finding: Excessive Privilege

Example:

Finding ID:
RBAC-002

Title:
Auditor Assigned Owner Role

Severity:
High

Observation:
An audit user has Owner access but requires read-only visibility.

Risk:
The identity can modify resources and access assignments beyond its business requirement.

Recommendation:
Replace Owner with Reader or another approved read-only role.

🧪 Task 29 — Create a Finding: Workload Over-Permission

Example:

Finding ID:
RBAC-003

Title:
Managed Identity Has Broad Contributor Access

Severity:
High

Observation:
A workload identity has Contributor at subscription level but only requires access to one storage account.

Risk:
Compromise of the workload could provide broad control over unrelated Azure resources.

Recommendation:
Replace the broad assignment with the minimum required resource-specific role at the narrowest appropriate scope.

📊 Risk Rating

Use:

Privilege
+
Scope
+
Identity Type
+
Exposure
+
Business Impact
=
Risk

🔴 Critical

Potential broad or immediate takeover capability.

🟠 High

Significant excessive access or privilege.

🟡 Medium

Meaningful access-control weakness.

🔵 Low

Cleanup, documentation, or minor governance issue.

🧪 Task 30 — Build an RBAC Review Checklist

Check	Status	Risk	Recommendation
Subscription Owners reviewed
Contributor scope reviewed
Reader assignments reviewed
Group-based access used
Service principals reviewed
Managed identities reviewed
Stale assignments removed
Least privilege applied
PIM considered
Role inheritance reviewed

🚨 Scenario — Suspicious RBAC Change

Scenario:

A developer who previously had Reader access suddenly receives Owner at subscription scope.

Investigate:

Identity
   ↓
Role Assignment Change
   ↓
Who Made Change?
   ↓
Why?
   ↓
What Happened Afterwards?

Review:

activity logs
role assignment history where available
privileged identity
subsequent resource activity

🧠 Security Question

Ask:

Was the assignment itself the incident, or was it part of a larger attack path?

🚨 Scenario — Compromised Workload Identity

Scenario:

An application using managed identity is compromised.

Ask:

which role does the identity have?
at what scope?
which resources can it access?
can it modify IAM?
can it access secrets?
what activity occurred?

This is why workload least privilege matters.

🎤 Azure RBAC Interview Questions

Practise without notes.

Fundamentals

1. What is Azure RBAC?

2. What is a role assignment?

3. What is a role definition?

4. What does scope mean in Azure RBAC?

5. What is inheritance?

Roles

6. Reader vs Contributor?

7. Contributor vs Owner?

8. Why is Owner considered highly privileged?

9. When would you create a custom role?

Identity

10. Azure RBAC vs Microsoft Entra roles?

11. What is a service principal?

12. What is a managed identity?

13. Why are managed identities useful?

Security

14. What is least privilege?

15. Why is subscription-level access risky?

16. Why use groups for access management?

17. Why review workload identities?

18. What is standing privilege?

19. How can PIM reduce risk?

Troubleshooting

20. A user has Reader but needs to restart a VM. What would you do?

21. A user has Contributor in one resource group but cannot manage another resource group. Why?

22. A user says they have access but receive authorization failure. What do you check?

🚨 Scenario Interview Question 1

A developer needs to manage one application but has Owner at subscription scope.

A strong answer should discuss:

confirm actual required tasks
identify appropriate role
reduce scope
remove Owner
validate required access
use temporary privilege if occasional elevation is required

🚨 Scenario Interview Question 2

An application needs read access to one storage account.

Do not assign Contributor at subscription level.

Discuss:

managed identity
resource-specific role
narrow scope
validation

🚨 Scenario Interview Question 3

A security analyst needs visibility across the subscription but should not change resources.

Consider:

Reader or an appropriate security/read role based on the exact requirement.

Always validate the actual permissions needed.

🚨 Scenario Interview Question 4

A user is a Global Administrator but cannot manage an Azure VM.

Explain the distinction between:

Entra directory roles
Azure RBAC resource roles

🧠 Interview Answer Framework

For Azure authorization questions use:

Principal
   ↓
Role
   ↓
Scope
   ↓
Inheritance
   ↓
Required Action
   ↓
Effective Access

💬 Interview Tip

Avoid:

“Give Contributor.”

A stronger answer is:

“I would first identify the exact operations the user needs, check their current role assignments and scope, select the least-privileged role that supports those tasks, assign it at the narrowest practical scope, and validate both allowed and denied actions.”

That sounds like an Azure Security Engineer.

📁 Portfolio Evidence

After completing this lab, create a sanitized portfolio package including:

RBAC Architecture

Show:

Identity
   ↓
Group
   ↓
Role
   ↓
Resource Group

Access Matrix

Document actual vs required permissions.

Findings

Create 2–5 RBAC findings.

Remediation

Explain how access was reduced.

Validation

Show what:

still works
is now denied

📝 Resume Examples

Instead of:

Knowledge of Azure RBAC.

Use:

Performed an Azure RBAC security review in a lab environment covering users, groups, role assignments, inheritance, managed identities, and scope, then implemented and validated least-privilege remediation.

Or:

Troubleshot Azure authorization issues by analyzing principals, role definitions, assignment scope, and inherited permissions without using excessive administrative access.

⭐ Job-Readiness Check

After this lab, you should be able to:

explain Azure RBAC
distinguish Azure RBAC from Entra roles
explain Reader, Contributor, and Owner
explain RBAC scope
explain inheritance
assign least-privilege roles
review group-based access
assess service principals
assess managed identities
identify standing privilege
understand PIM concepts
troubleshoot authorization
create professional findings

If your troubleshooting approach is still:

assign Owner and see if it works

repeat the lab.

The goal is:

I can identify exactly which access is required, where it should be assigned, and how to verify that unnecessary access has been removed.

🧹 Lab Clean-Up

After completing the lab:

remove temporary test users if appropriate
remove temporary role assignments
delete unused test groups
remove unnecessary service-principal assignments
remove broad test roles
delete temporary resource groups if no longer needed
confirm you did not leave unnecessary Owner assignments

🏆 Mission Complete

You have now practised:

Identity
   ↓
Role Definition
   ↓
Scope
   ↓
Inheritance
   ↓
Least Privilege
   ↓
Troubleshooting
   ↓
Security Findings
   ↓
Remediation

These are fundamental skills for:

Azure Security Engineers
IAM Engineers
Cloud Security Engineers
Azure Administrators
Security Consultants
Cloud Security Architects

🚀 What’s Next?

You now understand who can manage Azure resources and at what scope.

The next step is to secure the identity layer more deeply by focusing on:

authentication
MFA
Conditional Access
privileged access
PIM
guest identities
application identities
risky sign-ins
identity governance

➡️ Next: Microsoft Entra ID Security Lab

In the next lab, you will practise:

user and group security
MFA
Conditional Access
privileged roles
PIM concepts
guest access
service principals
managed identities
suspicious sign-in investigation
identity-security findings
remediation
identity interview scenarios