Azure Identity and RBAC Governance

Build an enterprise Azure governance structure with management groups and RBAC.

Introduction

30 Second Summary

Think about a company where every employee has the same level of access to everything. One accidental click could delete production databases or expose sensitive customer data.

In this project, you will build an enterprise governance structure in Azure that separates team permissions using management groups, security groups, and RBAC role assignments. You will sign in as different test users and see firsthand that access boundaries hold.

What You'll Build

You will sign in as three different personas and watch Azure block actions that fall outside each team's designated role, proving your governance model enforces real access isolation.

By the end of this project, you'll have:

A management group hierarchy (Root > FIBI-SAAS > ClientA > DEV/UAT/PROD) that organizes clients and environments the way production SaaS platforms do.
Three security groups populated with test users, proving group-based access control works on Azure's free tier.
Live RBAC role assignments (Owner, Contributor, SQL DB Contributor) at subscription scope, verified by logging in as each persona and hitting real permission boundaries.
Secret Mission: Prove that RBAC inheritance flows from a management group scope down through the hierarchy to your subscription.

Are there any prerequisites?

You need an active Azure subscription (Free tier or Pay-As-You-Go) with Owner access. All features in this project are free and included with any Azure subscription and the Microsoft Entra ID Free tier.

Before We Start

Before We Start...

Before we dive in, let's lock in what you're about to build and why it matters.

You are building an enterprise-grade identity and access management structure that separates administrative, DevOps, and database team permissions. The goal is access isolation: proving that giving someone Contributor does not let them assign roles, and giving someone SQL DB Contributor does not let them create VMs.

Set Up and Verify Your Azure Subscription

Before building governance structures, you need to confirm the foundation is solid. If your subscription is inactive or your account lacks the right permissions, every later step fails silently with confusing error messages.

In this step, you will verify your Azure subscription is active with Owner access, confirm your Microsoft Entra ID tenant is ready for user and group management, and disable a security setting that would block your test user logins later.

In this step, get ready to:

Confirm your Azure subscription is active and you have Owner access.
Verify your Entra ID tenant and note your tenant domain.
Disable Security Defaults so test users can sign in without MFA registration.

Sign in and verify your subscription

Your subscription is the billing and access boundary for everything you build in Azure. You need to confirm it is active and that your account holds the Owner role, which is the only role that can assign other roles to groups.

Open your browser and navigate to portal.azure.com.
Sign in with the Microsoft account that owns your Azure subscription.
In the portal search bar at the top, type Subscriptions and select Subscriptions from the results.
Confirm your subscription appears in the list with Status showing Active.
Note down your subscription name and subscription ID. You will need both in later steps.
Click on your subscription name to open it.
Click Access control (IAM) in the left menu.
Click Check access.

Before you search, what role do you expect to see on your account?

Search for your own account name or email address.
Confirm the results show you have the Owner role on this subscription.

Why do I need Owner?

The Owner role grants full access to manage all resources including the ability to assign roles in Azure RBAC. Without Owner, you cannot assign roles to the security groups you will create in Step 4.

The Contributor role looks similar but explicitly blocks role assignment actions. Only Owner (or User Access Administrator) can assign roles to others.

Don't see your subscription?

Make sure you signed in with the same Microsoft account that created or owns the subscription. If you have multiple accounts, check the account switcher in the top-right corner of the portal.

If your subscription shows a status other than Active (such as Disabled or Expired), you need to resolve that before continuing. A free trial that expired will not work for this project.

Still stuck? Help me troubleshoot my Azure subscription access.

Verify your Entra ID tenant

Microsoft Entra ID is the identity service where you will create test users and security groups. You need to confirm your tenant is accessible and that you have permission to manage users within it.

In the portal search bar, type Microsoft Entra ID and select it from the results.
Confirm you see the Overview page displaying your tenant name and Tenant ID.
Under Manage in the left menu, click Users.
Confirm you can see your own user account listed.
Note your tenant domain. This is the part after the @ symbol in your username (for example, yourtenant.onmicrosoft.com). You will use this when creating test users.

Seeing your user account in the list confirms you have permissions to create users and groups in this tenant.

What is Microsoft Entra ID?

Microsoft Entra ID (formerly Azure Active Directory) is the cloud identity and access management service for Azure. It manages users, groups, and authentication for your tenant.

User and group management, basic reports, and single sign-on are all included in the Entra ID Free tier. You do not need a premium license for anything in this project.

Can't see the Users page?

If you see a permissions error when clicking Users, your account may not have directory read permissions. This is unusual for the subscription owner but can happen in corporate-managed tenants.

For this project, you need a tenant where you are the Global Administrator or have User Administrator permissions. If you are using a corporate tenant with restrictions, consider creating a new free Azure account with its own tenant.

Need more help? Help me access the Users page in Microsoft Entra ID.

Disable Security Defaults for test user login

Security Defaults enforces MFA registration for all users in your tenant. This is great for production security, but it would block your test user sign-ins in Step 5 because those users will not have MFA devices registered.

In Microsoft Entra ID, click Properties in the left menu.
At the bottom of the page, click Manage security defaults.
Set the Security defaults toggle to Disabled.
Select a reason from the dropdown (for example, My organization is using other security measures).
Click Save.

You should see a confirmation that the setting was saved successfully.

You will re-enable Security Defaults at the end of this project

Disabling Security Defaults is only for the duration of this lab. In the Before You Go section, the final cleanup step instructs you to re-enable it. Never leave Security Defaults disabled in a tenant that has real users.

Don't see the Properties page?

If Properties does not appear in the left menu, try navigating via Identity > Overview > Properties. The portal layout can vary depending on your tenant configuration.

If you see the page but the Manage security defaults link is missing or greyed out, your account may not have Global Administrator permissions on this tenant.

Still having trouble? Help me find and disable Security Defaults in my Entra ID tenant.

Your foundation is confirmed. You have an active subscription with Owner access, a working Entra ID tenant, and Security Defaults disabled for test user access. Next up, you will build the management group hierarchy that organizes your subscription into a real enterprise structure.

Build the Management Group Hierarchy

Your subscription is verified and your tenant is ready to build on. Now you need a structure that lets you scope access and policies at different levels of your organization.

Without a management group hierarchy, everything sits flat under one root. You cannot differentiate access between clients or environments. In this step, you will build a tree that mirrors how a SaaS company organizes multi-client, multi-environment deployments.

In this step, get ready to:

Create five management groups in a parent-child hierarchy.
Move your subscription under the DEV environment group.
Verify the complete tree structure from root to leaf.

Create the management group hierarchy

In the Azure Portal search bar, type Management groups and select it from the results.

First time using management groups?

If this is your first time, you may see a prompt to start using management groups. Click Start using management groups and wait for the initial setup to complete.

The first management group created in a directory can take up to 15 minutes to provision. You will receive a notification when the process is complete.

Once the page loads, you should see the Tenant Root Group at the top. This is the automatic root of every Azure hierarchy.

You will now create five management groups, one at a time. Here is the full hierarchy you are building:

FIBI-SAAS (ID: fibi-saas) under Tenant Root Group.
ClientA (ID: fibi-clienta) under FIBI-SAAS.
DEV (ID: fibi-clienta-dev) under ClientA.
UAT (ID: fibi-clienta-uat) under ClientA.
PROD (ID: fibi-clienta-prod) under ClientA.

Start by creating the first group, FIBI-SAAS:

Click + Add management group.
In the Management Group ID field, enter fibi-saas.
In the Display Name field, enter FIBI-SAAS.
Confirm the parent is set to Tenant Root Group.
Click Save.

You should see FIBI-SAAS appear in the management groups list under Tenant Root Group.

Why are management group IDs immutable?

The Management Group ID is the directory-unique identifier used throughout Azure to reference this group. It cannot be changed after creation. Use lowercase with hyphens as a naming convention to avoid issues later.

Now create the remaining four groups using the same process. For each one, click + Add management group, enter the ID, display name, and select the correct parent.

Create ClientA: ID = fibi-clienta, Display Name = ClientA, Parent = FIBI-SAAS.
Create DEV: ID = fibi-clienta-dev, Display Name = DEV, Parent = ClientA.
Create UAT: ID = fibi-clienta-uat, Display Name = UAT, Parent = ClientA.
Create PROD: ID = fibi-clienta-prod, Display Name = PROD, Parent = ClientA.

After saving each group, confirm it appears in the hierarchy before creating the next one.

Don't see the parent you expect in the dropdown?

If a parent group you just created does not appear in the dropdown, wait a few seconds and refresh the page. Management group creation can take a moment to propagate.

Also confirm you are clicking + Add management group from the main Management groups page, not from inside a specific group.

Still stuck? Help me troubleshoot why my parent management group is not showing up.

Move your subscription under DEV

Your management groups exist, but your subscription still sits at the root level. Moving it under DEV means it will inherit any RBAC or policy applied at DEV, ClientA, FIBI-SAAS, or Root.

Click on the DEV management group (fibi-clienta-dev) to open it.
Click + Add subscription.
Select your subscription from the dropdown list.
Click Save.

Your subscription now appears nested under the DEV management group.

What does moving a subscription accomplish?

Your subscription is now governed by the DEV management group and inherits any RBAC or policy applied at DEV, ClientA, FIBI-SAAS, or Root levels. This is how enterprises enforce consistent governance without configuring each subscription individually.

Verify the complete hierarchy

Before you move on, take a moment to predict what the full tree should look like. You created five groups and placed your subscription under DEV. What structure do you expect to see?

Navigate back to Management groups using the breadcrumb or search bar.
Click on the Tenant Root Group and expand the tree.

You should see the full tree: Tenant Root Group > FIBI-SAAS > ClientA > DEV (with your subscription listed inside), UAT, and PROD.

The UAT and PROD groups are empty placeholders representing where future client subscriptions would go in a real deployment.

Subscription not showing under DEV?

Make sure you clicked Save after selecting your subscription in the previous substep. If the subscription still appears under Tenant Root Group, open DEV again and repeat the + Add subscription process.

Need more help? Help me figure out why my subscription is not appearing under my DEV management group.

Your governance skeleton is in place. Next up, you will create security groups and test users to populate this hierarchy with real identities that you can assign roles to.

Create Security Groups and Test Users

Your management group hierarchy is in place. You have a clear structure separating clients and environments. Now you need people to govern.

Assigning RBAC roles directly to individual users does not scale. When someone joins or leaves a team, you would have to hunt down every role assignment across every subscription. Security groups solve this. You manage one group membership, and the permissions follow automatically.

In this step, get ready to:

Create three security groups in Microsoft Entra ID.
Create three test users with temporary passwords.
Add each user to their respective group.

Create the three security groups

Each security group represents a team in your organization. You will create three groups with static (Assigned) membership, which is fully supported on the Microsoft Entra ID Free tier.

In the Azure Portal search bar, type Microsoft Entra ID and select it.
In the left menu under Manage, click Groups.
Click + New group.

Create the first group with these settings:

Set Group type to Security.
Enter SG-Administrators as the Group name.
Set Membership type to Assigned.
Leave all other fields as default.
Click Create.

You should see SG-Administrators appear in your groups list.

Repeat the same process to create the remaining two groups:

Click + New group again.
Set Group type to Security.
Enter SG-DevOps as the Group name.
Set Membership type to Assigned.
Click Create.

Click + New group one more time.
Set Group type to Security.
Enter SG-DBTeam as the Group name.
Set Membership type to Assigned.
Click Create.

Your groups list should now show all three groups: SG-Administrators, SG-DevOps, and SG-DBTeam.

Why Assigned membership instead of Dynamic?

Dynamic groups automatically add and remove members based on user attributes, but they require a Microsoft Entra ID P1 license. Assigned (static) membership is fully supported on the Free tier and gives you explicit control over who belongs to each group.

Don't see your groups listed?

Click the Refresh button at the top of the groups list. If a group still does not appear, confirm you selected Security as the group type (not Microsoft 365).

Need more help?

Create test users

Each security group needs a member to prove that group-based access actually works. You will create three cloud-only test users, one for each team persona.

In the left menu of Microsoft Entra ID, click Users under Manage.
Click + New user, then select Create new user.

Create the first test user with these settings:

In the User principal name field, enter admin-test. The domain after the @ symbol is your tenant domain (the one you noted in Step 1, e.g. yourtenant.onmicrosoft.com).
In the Display name field, enter Admin Test.
Under Password, uncheck Auto-generate password and type a temporary password you can remember (for example, TempPass#2026!).
Click Review + create, then click Create.

You should see Admin Test appear in your users list. Now create the second user:

Click + New user > Create new user.
Enter devops-test as the User principal name.
Enter DevOps Test as the Display name.
Set a temporary password you can remember.
Click Review + create, then Create.

Create the third and final user:

Click + New user > Create new user.
Enter dbteam-test as the User principal name.
Enter DBTeam Test as the Display name.
Set a temporary password you can remember.
Click Review + create, then Create.

Record your credentials now

Write down the full user principal name and temporary password for each user. You will need all three in Step 5 when you sign in as each persona to test access boundaries.

Your users list should now show all three test accounts alongside your own admin account.

Getting a permissions error when creating users?

Confirm you are signed in with an account that has the Owner role on the subscription and Global Administrator or User Administrator role in Entra ID. If you set up the tenant yourself, your account has these by default.

Still stuck?

Add users to their respective groups

The users exist, but they do not belong to any group yet. Until you add them, the security groups are empty containers with no effect.

In the left menu of Microsoft Entra ID, click Groups.
Click on SG-Administrators to open it.
Click Members in the left menu.
Click + Add members.
Search for Admin Test, select it, then click Select.

You should see Admin Test listed as a member. The group now shows 1 member.

Now add DevOps Test to the SG-DevOps group:

Navigate back to the groups list by clicking Groups in the breadcrumb or left menu.
Click on SG-DevOps.
Click Members > + Add members.
Search for DevOps Test, select it, then click Select.

Finally, add DBTeam Test to the SG-DBTeam group:

Navigate back to the groups list.
Click on SG-DBTeam.
Click Members > + Add members.
Search for DBTeam Test, select it, then click Select.

Why groups instead of individual role assignments?

When a new developer joins the DevOps team, you add them to SG-DevOps. They instantly inherit every permission the group has across every subscription. When they leave, you remove them from the group. One change, total cleanup.

Without groups, you would need to find and remove their individual role assignments on every resource, subscription, and management group they ever touched.

Before you verify, what do you think you will see when you open each group? How many members should each group have?

Navigate to Microsoft Entra ID > Groups.
Confirm that SG-Administrators shows 1 member.
Confirm that SG-DevOps shows 1 member.
Confirm that SG-DBTeam shows 1 member.

Each group displays 1 member. Click into any group to confirm the correct user is listed inside.

A group shows 0 members?

Click into the group and check Members. If the member is missing, click + Add members and search for the user again. Make sure you click Select after highlighting the user.

Need help?

Your identity layer is complete. You have three teams, three test personas, and a group structure ready to receive permissions. Next up, you will assign Azure RBAC roles to these groups and bring the access model to life.

Assign Azure RBAC Roles at Subscription Scope

Your security groups exist, but right now they have zero permissions. Without RBAC role assignments, your test users cannot see or do anything in the subscription.

In this step, you will assign three different Azure RBAC built-in roles at the subscription scope. Each role grants a different level of access, and this is where the access model comes to life.

In this step, get ready to:

Assign the Owner role to SG-Administrators.
Assign the Contributor role to SG-DevOps.
Assign the SQL DB Contributor role to SG-DBTeam.

Assign Owner to SG-Administrators

The Owner role grants full access to manage all resources, including the ability to assign roles to others. This is the highest level of access in Azure RBAC.

In the portal search bar, type Subscriptions and select it.
Click on your subscription name.
Click Access control (IAM) in the left menu.
Click + Add.
Select Add role assignment.

What is this wizard?

The role assignment wizard has three tabs: Role (pick the permission set), Members (pick who gets it), and Review + assign (confirm). You will walk through these tabs for each assignment.

On the Role tab, select Privileged administrator roles.
Select Owner from the list.
Click Next.
On the Members tab, click + Select members.
Search for SG-Administrators.
Select it from the results.
Click Select.
Click Review + assign (you may need to click it twice to confirm).

A success notification appears at the top of the portal. SG-Administrators now has Owner access to your subscription.

What does the Owner role allow?

Owner grants full access to manage all resources including the ability to assign roles in Azure RBAC. This is what your Admin Test user will inherit through their SG-Administrators group membership.

Assign Contributor to SG-DevOps

The Contributor role grants full access to manage all resources but does not allow you to assign roles. This is the key boundary that separates it from Owner.

Still in Access control (IAM), click + Add.
Select Add role assignment.
On the Role tab, select Privileged administrator roles.
Select Contributor from the list.
Click Next.
On the Members tab, click + Select members.
Search for SG-DevOps.
Select it from the results and click Select.

Click Review + assign.

Another success notification appears. SG-DevOps now has Contributor access.

How is Contributor different from Owner?

Contributor explicitly blocks Microsoft.Authorization/*/Write and Microsoft.Authorization/*/Delete. This means a Contributor can create, update, and delete resources, but cannot grant or revoke access for anyone else.

Assign SQL DB Contributor to SG-DBTeam

SQL DB Contributor is a scoped role that lets you manage SQL databases but cannot create arbitrary resources like resource groups or virtual machines. This makes it ideal for a database team that should stay in their lane.

Click + Add.
Select Add role assignment.
On the Role tab, select Job function roles.
Search for SQL DB Contributor and select it.
Click Next.
On the Members tab, click + Select members.
Search for SG-DBTeam.
Select it from the results and click Select.

Click Review + assign.

Why is SQL DB Contributor under Job function roles?

Azure organizes built-in roles into categories. Owner and Contributor are privileged administrator roles because they grant broad access. SQL DB Contributor is a job function role because it is scoped to a specific workload (databases).

All three assignments are now in place. Before you verify, predict: how many group-based role assignments do you expect to see in the Role assignments tab?

Click the Role assignments tab at the top of the Access control (IAM) blade.

You should see three entries for the groups you just configured: SG-Administrators as Owner, SG-DevOps as Contributor, and SG-DBTeam as SQL DB Contributor. Your own Owner assignment from your personal account is also listed separately.

Don't see all three assignments?

Role assignments can take a few moments to propagate. Refresh the page and check again. If one is missing, repeat the assignment steps for that group, making sure you searched for the exact group name.

If you see a permissions error when trying to assign, confirm that your own account still has the Owner role on this subscription.

Help me troubleshoot my missing role assignments.

Your access model is live. Three groups, three roles, three different levels of access at the subscription scope. Next up, you will sign in as each test user and prove that these boundaries actually hold.

Verify Access Isolation by Testing Each Persona

Your RBAC role assignments are in place. Three security groups now hold three different levels of access to your subscription. But a governance model you have never tested is a governance model that might not work.

In this step, you will sign in as each test persona and deliberately attempt actions their roles should block. This is the kind of proof auditors ask for: concrete evidence that access boundaries hold under real conditions.

In this step, get ready to:

Test the DBTeam user (SQL DB Contributor boundaries)

The SQL DB Contributor role grants access to manage SQL databases but not general Azure resources. You will prove this by attempting to create a resource group and assign a role, both of which should fail.

Open a private/incognito browser window. Keep your admin session open in the regular window.
Navigate to portal.azure.com in the incognito window.
Sign in as dbteam-test@yourtenant.onmicrosoft.com using the credentials you recorded in Step 3. Replace yourtenant with your actual tenant domain.
You will be prompted to change the temporary password. Set a new password you can remember.
In the portal search bar, type Subscriptions and select it.
Confirm your subscription appears in the list.

The DBTeam user can see the subscription because SQL DB Contributor includes read access to resource groups. Now test whether this user can create resources or assign roles.

Click Resource groups in the portal search bar or left sidebar.
Click + Create.

Before you proceed, what do you expect will happen? Will Azure allow the SQL DB Contributor to create a resource group?

You should receive a permissions error or see that the Create button returns an authorization failure. This confirms that SQL DB Contributor does not include Microsoft.Resources/subscriptions/resourceGroups/write.

Navigate back to your subscription.
Click Access control (IAM) in the left menu.
Confirm that you cannot add role assignments. The + Add button should be disabled or return an error if clicked.

What does this prove?

SQL DB Contributor can view databases and related resources, but cannot create arbitrary resources or modify access. This is the principle of least privilege in action.

Test the DevOps user (Contributor boundaries)

The Contributor role grants full resource management but explicitly blocks role assignment actions. You will prove this by creating a resource group (should succeed) and then attempting to assign a role (should fail).

Open another private/incognito window, or sign out of the DBTeam session.
Navigate to portal.azure.com and sign in as devops-test@yourtenant.onmicrosoft.com.
Change the temporary password when prompted.
Navigate to Resource groups using the portal search bar.
Click + Create.
Enter rg-test-devops as the resource group name and select any region.
Click Review + create, then click Create.

This should succeed. The Contributor role includes full resource management permissions. Now test the boundary.

Navigate to your subscription using the search bar.
Click Access control (IAM) in the left menu.
Click + Add, then click Add role assignment.
Select any role and try to assign it to any member.

Before you complete the assignment, what do you expect? Can a Contributor assign roles to other users?

You should receive an authorization error. This confirms that the Contributor role's NotActions include Microsoft.Authorization/*/Write, blocking all role assignment operations.

What does this prove?

Contributor can manage all resources (create, delete, configure) but cannot modify who has access. This is the critical separation between Contributor and Owner.

Clean up: navigate to Resource groups, select rg-test-devops.
Click Delete resource group.
Type the resource group name to confirm, then click Delete.

Test the Admin user (Owner full access)

The Owner role grants full access to all resources including the ability to assign roles. Both actions that failed for the other users should succeed here.

Open another private/incognito window.
Navigate to portal.azure.com and sign in as admin-test@yourtenant.onmicrosoft.com.
Change the temporary password when prompted.
Navigate to Resource groups and click + Create.
Enter any name and select any region, then click Review + create and Create.

This should succeed. Now test role assignment.

Navigate to your subscription.
Click Access control (IAM) in the left menu.
Click + Add, then click Add role assignment.
On the Role tab, select Job function roles, then select Reader.
Click Next.
Click + Select members, search for DevOps Test, select it, then click Select.
Click Review + assign to complete the assignment.

Do you expect this to succeed? The Owner role has no NotActions blocking authorization operations.

This should succeed. The Owner can do everything, including assigning roles to other users. This is the most powerful built-in role and the reason it should only be assigned to administrators.

What does this prove?

Owner has full access to manage all resources including the ability to assign roles in Azure RBAC. This is the definitive separation: DBTeam could do neither action, DevOps could manage resources but not roles, and Owner can do both.

Now clean up the test artifacts you just created as the Admin user.

Navigate to Resource groups, select the resource group you just created.
Click Delete resource group, type the name to confirm, then click Delete.
Navigate back to your subscription and click Access control (IAM).
Click the Role assignments tab.
Find the Reader assignment for DevOps Test, select it, and click Remove.
Close all private/incognito browser windows.

Test user sign-in not working?

If you see a message about MFA registration being required, confirm that you disabled Security Defaults in Step 1. Return to your admin session and navigate to Microsoft Entra ID > Properties > Manage security defaults and set it to Disabled.

If you see a message about the subscription not being visible, RBAC role propagation can take up to 5 minutes. Wait a few minutes and refresh the page.

help me troubleshoot my test user sign-in for Azure RBAC verification

Return to your admin session in the regular browser window. Navigate to your subscription and click Access control (IAM), then click the Role assignments tab. You should see your three original assignments intact: SG-Administrators as Owner, SG-DevOps as Contributor, and SG-DBTeam as SQL DB Contributor.

Secret mission

Prove Management Group RBAC Inheritance

You have proven that roles assigned at subscription scope enforce access boundaries. But the real power of a management group hierarchy is inheritance. Can you assign a role at a higher scope and prove it flows down automatically to every subscription underneath?

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely on free Azure features, so there are no ongoing costs regardless of what you choose.

Resources you used:

5 management groups (FIBI-SAAS, ClientA, DEV, UAT, PROD). Free, no ongoing cost.
3 security groups (SG-Administrators, SG-DevOps, SG-DBTeam). Free, no ongoing cost.
3 test users (Admin Test, DevOps Test, DBTeam Test). Free, no ongoing cost.
3 RBAC role assignments (Owner, Contributor, SQL DB Contributor) at subscription scope. Free, no ongoing cost.

Keep everything running

No action needed. Choose this if you plan to build on this lab in the future, such as adding Azure Policy or expanding the hierarchy with more clients.

All resources in this project are free. Management groups, security groups, test users, and RBAC role assignments incur zero charges.
Your management group hierarchy remains intact and ready for follow-on projects.
Security Defaults is already re-enabled, so your test users cannot sign in without completing MFA registration.

Pause - I'll come back to this later

Delete the test users to prevent unused credentials sitting in your tenant, but keep the management group hierarchy and security groups for future use.

Navigate to Microsoft Entra ID in the Azure Portal.
Click Users in the left menu.
Select Admin Test, then click Delete user in the top toolbar. Confirm the deletion.
Repeat for DevOps Test and DBTeam Test.
Your management group hierarchy and security groups stay intact. When you return, create new test users and add them back to the groups.

Delete - I don't want to use this again

Remove all project resources in reverse order. Start with role assignments, then users, then groups, then move your subscription out, and finally delete management groups bottom-up.

Step 1: Remove RBAC role assignments.

In the portal search bar, type Subscriptions and select your subscription.
Click Access control (IAM) in the left menu.
Click the Role assignments tab.
Select the row for SG-Administrators (Owner), then click Remove and confirm.
Repeat for SG-DevOps (Contributor) and SG-DBTeam (SQL DB Contributor).

Step 2: Delete test users.

Navigate to Microsoft Entra ID > Users.
Select Admin Test, click Delete user, and confirm.
Repeat for DevOps Test and DBTeam Test.

Step 3: Delete security groups.

Navigate to Microsoft Entra ID > Groups.
Select SG-Administrators, click Delete, and confirm.
Repeat for SG-DevOps and SG-DBTeam.

Step 4: Move your subscription out of DEV.

In the portal search bar, type Management groups and select it.
Click on Tenant Root Group.
Click + Add subscription, select your subscription from the dropdown, and click Save. This moves it back to the root level.

Step 5: Delete management groups bottom-up.

In Management groups, click on DEV (fibi-clienta-dev). Click Delete and confirm.
Repeat for UAT (fibi-clienta-uat) and PROD (fibi-clienta-prod).
Delete ClientA (fibi-clienta).
Delete FIBI-SAAS (fibi-saas).
You must delete child groups before parent groups. If a group still contains children or subscriptions, the delete will fail.

Nice Work!

You just built a fully functional enterprise governance lab in Azure that proves you can design and enforce role-based access isolation across teams.

This is the foundational pattern behind every production Azure deployment. You did not just read about it. You signed in as different personas and saw the boundaries hold.

You've learned how to:

Build a multi-level management group hierarchy (Root > FIBI-SAAS > ClientA > DEV/UAT/PROD) that mirrors how enterprise SaaS platforms organize clients and environments.
Create security groups with test users and assign differentiated Azure RBAC built-in roles (Owner, Contributor, SQL DB Contributor) at subscription scope.
Sign in as each test persona and verify access isolation firsthand. Contributor cannot assign roles. SQL DB Contributor cannot create resource groups. Owner can do both.
Secret Mission: Proved that RBAC inheritance flows from a management group scope down through the hierarchy to subscription-level resources.

Ready to quiz yourself?