Role-Based Access Control with Entra ID

Set up group-based Azure RBAC with PIM for just-in-time admin access.

Introduction

30 Second Summary

When a new developer joins your team, how do they get access to the right cloud resources without accidentally being able to delete the entire database? In most growing organizations, managing who can do what becomes a full-time job.

In this project, you will build a centralized, role-based access control system in Azure using Microsoft Entra ID security groups, Azure RBAC roles, and Privileged Identity Management. You will create team-based permission boundaries and enforce just-in-time access for elevated privileges.

What You'll Build

When your team members log into the Azure portal, they see only the resources and actions their group membership grants them. Administrators must explicitly activate their elevated privileges through PIM before they can manage access.

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

Three security groups in Entra ID mapped to specific Azure RBAC roles, so onboarding a new team member is as simple as adding them to a group.
Verified access isolation where your DevOps team can deploy resources but cannot grant access to others, and your DB team can manage SQL databases but cannot touch compute or networking.
Just-in-time Owner access through PIM for Administrators, requiring explicit activation with MFA and a full audit trail.
Secret Mission: Create a Management Group hierarchy for multi-client, multi-environment subscription structure with inherited role assignments.

Are there any prerequisites?

You need an Azure subscription where you have Owner or Global Administrator access. You also need a Microsoft Entra ID P2 license, which offers a free 30-day trial that you will activate in Step 1.

Before We Start

Before you can assign roles to groups, you need to confirm you have the right admin privileges and license tier. Azure RBAC role assignments require Owner access at the subscription level, and Privileged Identity Management requires an Entra ID P2 license.

In this step, you will verify both of these prerequisites so the rest of the project runs smoothly.

In this step, get ready to:

Confirm Global Administrator access in the Microsoft Entra admin center.
Activate the Entra ID P2 license or verify it is already active.
Verify your Owner role assignment at subscription scope in the Azure portal.

Sign in to the Microsoft Entra admin center

The Microsoft Entra admin center is where you manage identity, groups, and licensing for your Azure tenant.

Open a new browser tab and navigate to entra.microsoft.com.
Sign in with the account that has Global Administrator or Privileged Role Administrator access.
Once signed in, you land on the Microsoft Entra admin center home page.

What is the Microsoft Entra admin center?

The Microsoft Entra admin center is the management portal for identity services in Azure. It replaced the legacy Azure Active Directory portal and is where you manage users, groups, licenses, and enterprise applications.

Confirm your admin role by checking the top-right profile icon. Your account name and role should be visible there.

Confirm your Entra ID P2 license

Privileged Identity Management requires a P2 license. You need to verify your tenant has one active before proceeding.

In the left navigation menu, expand Identity.
Click Overview.
Look at the tenant overview card. It displays your tenant name, tenant ID, and license information.

What do you expect to see in the license section? Before you check, predict whether your tenant already has P2 or whether you will need to activate a trial.

✔️ I see Microsoft Entra ID P2

Your tenant already has a P2 license active. You are ready to use Privileged Identity Management later in this project.

No action needed. Move on to the next substep.

ⓧ I do not see P2 listed

You need to activate the free 30-day P2 trial to unlock PIM features.

In the left navigation, navigate to Identity > Overview.
Click Try/Buy near the top of the page.
Under Microsoft Entra ID P2, select Free trial.
Click Activate.
Refresh the Overview page. Your license section should now show Microsoft Entra ID P2.

How long does the trial last?

The free trial lasts 30 days and gives you full access to P2 features including Privileged Identity Management. After the trial expires, PIM features become unavailable unless you purchase a license.

Don't see the Try/Buy option?

Make sure you are signed in as a Global Administrator. Only Global Administrators can activate license trials for the tenant.

If you have already used a P2 trial on this tenant before, the option may not appear again. In that case, you will need to purchase a P2 license or use a different tenant.

Help me troubleshoot why I cannot activate a P2 trial in the Entra admin center.

Verify your Owner role in the Azure portal

You need the Owner role at subscription scope to assign RBAC roles to the security groups you will create in the next step.

Open a new browser tab and navigate to portal.azure.com.
In the top search bar, type Subscriptions and select Subscriptions from the results.
Click on your subscription name to open it.
In the left menu, click Access control (IAM).
Click the Role assignments tab.

Before you scroll through the list, predict: do you expect to see your account listed with the Owner role at this scope?

Find your account in the list and confirm the Role column shows Owner and the Scope column shows your subscription name.

You should see your account listed with the Owner role. This confirms you have the permissions needed to assign roles to groups in the upcoming steps.

Why do I need Owner specifically?

The Owner role grants full access to manage all resources, including the ability to assign roles in Azure RBAC. The Contributor role can manage resources but cannot assign roles to others. You need Owner (or the Role Based Access Control Administrator role) to create role assignments for the security groups.

Don't see yourself as Owner?

If your account does not appear with the Owner role, contact the subscription administrator to have them grant you Owner access. Without it, you cannot complete this project.

If you created this subscription yourself, you should automatically have Owner. Try refreshing the page or checking that you are viewing the correct subscription.

Help me figure out why I don't have the Owner role on my Azure subscription.

Your admin access is confirmed and your license is ready. Next up, you will create the security groups that form the foundation of your role-based access control system.

Create Security Groups and Add Users

Your admin access is confirmed and Entra ID P2 is active. You're ready to build the access control structure that maps teams to permissions.

Assigning roles directly to individual users does not scale. As teams grow, tracking who has what access becomes a management nightmare. Security groups solve this by letting you manage access through team membership. Onboarding a new team member becomes as simple as adding them to a group.

In this step, get ready to:

Create three security groups in Entra ID (SG-Administrators, SG-DevOps, SG-DBTeam).
Add at least one member to each group.
Note the Object ID for each group for use in role assignments.

Prepare users for your groups

Each security group needs at least one member. You might already have users in your tenant, or you may need to create test users first.

✔️ I already have users in my tenant

You're ready to go. You'll add these existing users as members when you create each group in the next substep.

ⓧ I need to create test users

Create three test users (one per group) so you can test access isolation later. You only need basic accounts.

In the Entra admin center, navigate to Identity > Users > All users.
Click New user > Create new user.
In the User principal name field, enter a username like admin-test and select your tenant domain after the @ symbol.
In the Display name field, enter Admin Test User.
Leave Auto-generate password checked and note the temporary password shown.
Click Review + create, then click Create.
Repeat to create two more users (e.g. devops-test and db-test).

After creating all three, you should see them listed under All users.

Only seeing an Invite option?

If the Create new user option is greyed out and you only see Invite external user, confirm you are signed in as a Global Administrator with an active (not eligible) role assignment. Eligible roles must be activated through PIM before they grant permissions.

help me understand why I can't create a new user in Entra ID

Create your first security group

You'll create SG-Administrators first to learn the workflow. Then you'll repeat the process for the other two groups.

In the Entra admin center, navigate to Identity > Groups > All groups.
Click New group at the top of the page.
In the Group type dropdown, select Security.
In the Group name field, enter SG-Administrators.
Leave Group description blank or enter a description like Administrators group for subscription Owner access.
Leave the Microsoft Entra roles can be assigned to the group toggle set to No. You do not need role-assignable groups for Azure RBAC assignments.
Set Membership type to Assigned.
Under Members, click No members selected. Search for your admin test user (or an existing user) and select them.
Click Select to confirm the member.
Click Create at the bottom of the form.

You should see a notification confirming the group was created. The group now appears in the All groups list.

Why not enable role-assignable groups?

The Microsoft Entra roles can be assigned to the group toggle is only needed when assigning Entra directory roles (like Global Administrator) to a group. For Azure RBAC role assignments at subscription scope, standard security groups work perfectly.

Keeping this set to No avoids the P1 licensing requirement for role-assignable groups and keeps your setup simpler.

Create the remaining groups and verify

Return to All groups and click New group again.
Create a second security group with Group name set to SG-DevOps, Membership type set to Assigned, and at least one member added.
Click Create.
Repeat one more time to create SG-DBTeam with the same settings and at least one member.
Click Create.

Before you check the groups list, how many groups do you expect to see that you just created?

Navigate back to Identity > Groups > All groups.
Confirm you see all three groups listed: SG-Administrators, SG-DevOps, and SG-DBTeam.

You should see all three groups in the list. Now note down each group's Object ID for the role assignment step.

Click on SG-Administrators to open its Overview blade.
Confirm the Members tab shows the user(s) you assigned.
Copy the Object ID shown on the Overview blade and save it in a text file or note.
Repeat for SG-DevOps and SG-DBTeam. Confirm each has members and note each Object ID.

Why note the Object ID?

The Object ID is the unique identifier for each group in your tenant. You'll reference these IDs in the next step when assigning Azure RBAC roles at subscription scope. Having them ready saves time when searching for groups in the role assignment workflow.

Group not showing in the list?

If a newly created group does not appear immediately, wait a few seconds and click the Refresh button at the top of the All groups page. Group creation is near-instant but the UI list sometimes takes a moment to update.

help me troubleshoot why my security group is not appearing in Entra ID

Your three security groups are created and populated. Next up, you'll map each group to a specific Azure RBAC role at your subscription scope, giving each team precisely the permissions they need.

Assign RBAC Roles at Subscription Scope

Your three security groups are ready in Entra ID with members assigned. The next step is giving these groups actual permissions in Azure.

Right now, your groups exist only as identity containers. Members who log into the Azure portal can see resources but cannot perform any actions on them. Azure RBAC role assignments bridge this gap by mapping each group to a specific set of permissions at your subscription scope.

In this step, get ready to:

Assign the Owner role to SG-Administrators at subscription scope.
Assign the Contributor and SQL DB Contributor roles to SG-DevOps and SG-DBTeam.
Verify all three role assignments in the Access control (IAM) blade.

Assign the Owner role to SG-Administrators

The Owner role grants full access to manage all resources, including the ability to assign roles in Azure RBAC. This is the highest privilege level and appropriate for your Administrators group.

In the Azure portal, click Subscriptions in the search bar or left navigation menu.
Select your subscription from the list.
Click Access control (IAM) in the left menu.
Click + Add, then select Add role assignment.

The Add role assignment wizard opens. Because you have an Entra ID P2 license, you will see additional tabs including an Assignment type tab.

On the Role tab, search for Owner.
Select the Owner row, then click Next.
On the Members tab, select User, group, or service principal.
Click + Select members.
Search for SG-Administrators and select it, then click Select.
Click Next.

On the Assignment type tab, ensure Assignment type is set to Active and Assignment duration is set to Permanent.
Click Next.
On the Review + assign tab, click Review + assign to confirm.

A notification appears confirming the role assignment was created successfully. You are returned to the Access control (IAM) blade.

What does the Owner role allow?

The Owner role grants full access to manage all resources in your subscription. Critically, it also includes the ability to assign roles to other users and groups. This is what separates Owner from Contributor.

Microsoft recommends a maximum of 3 subscription Owners to reduce the potential for breach by a compromised owner. You will tighten this further in Step 5 by requiring just-in-time activation.

Assign the Contributor and SQL DB Contributor roles

You will repeat the same flow for SG-DevOps and SG-DBTeam. Each group gets a more tightly scoped role than Owner.

Click + Add, then select Add role assignment.
On the Role tab, search for Contributor.
Select the Contributor row, then click Next.
On the Members tab, select User, group, or service principal, click + Select members, search for SG-DevOps, and select it.
Click Select, then click Next.
On the Assignment type tab, confirm Active and Permanent are selected, then click Next.
Click Review + assign to confirm.

You should see a success notification. Now assign the final role to SG-DBTeam.

Click + Add, then select Add role assignment.
On the Role tab, search for SQL DB Contributor.
Select the SQL DB Contributor row, then click Next.
On the Members tab, select User, group, or service principal, click + Select members, search for SG-DBTeam, and select it.
Click Select, then click Next.
On the Assignment type tab, confirm Active and Permanent are selected, then click Next.
Click Review + assign to confirm.

Why these specific roles?

Contributor grants full resource management but explicitly blocks role assignment actions. Its NotActions include Microsoft.Authorization/*/Write and Microsoft.Authorization/*/Delete. This means your DevOps team can deploy anything but cannot grant themselves or others additional permissions.

SQL DB Contributor lets the DB team manage SQL databases but not SQL servers, networking, or compute resources. It scopes their access tightly to database operations only.

Not seeing the group in the member search?

Make sure you are searching by the exact group name (SG-DevOps or SG-DBTeam). Confirm you selected User, group, or service principal on the Members tab, not Managed identity.

If the group still does not appear, wait a minute and retry. New groups can take a brief moment to propagate.

Why can't I find my security group when adding a role assignment?

Confirm all three role assignments at subscription scope

All three roles are now assigned. Before you move on, verify that each group has the correct role at the subscription level.

Before you check, predict: how many group-type role assignments should you see listed for the groups you just created?
In your subscription's Access control (IAM) blade, click the Role assignments tab.
In the filter bar, set the Type filter to Group.

You should see three entries: SG-Administrators with Owner, SG-DevOps with Contributor, and SG-DBTeam with SQL DB Contributor. The Scope column shows your subscription name for each, confirming these are subscription-level assignments.

Why does scope matter?

In Azure, you can specify a scope at four levels: management group, subscription, resource group, and resource. A role assigned at subscription scope applies to every resource group and resource within that subscription. If you assigned at a resource group scope instead, the permissions would only apply to resources inside that one group.

Your three security groups now have clearly defined permissions at subscription scope. Next, you will test that these roles actually restrict access by logging in as users from each group.

Test Access Isolation

Your three security groups now have distinct RBAC roles mapped at subscription scope. The role assignments tab shows the right names in the right columns. The real question is whether those boundaries actually hold when a team member tries to do something outside their lane.

A misconfigured scope or an overly broad role could silently give the DB team full subscription control. It could also lock DevOps out of deployments they should be able to run. In this step, you will log in as different team members and deliberately push against their boundaries to prove the isolation works.

In this step, get ready to:

Test that SG-DevOps members can create resources but cannot assign roles.
Test that SG-DBTeam members are restricted to SQL database management only.
Confirm your RBAC isolation is working correctly across both groups.

Test DevOps access boundaries

The Contributor role grants full access to manage all resources. It explicitly blocks the ability to assign roles in Azure RBAC. You are about to prove both sides of that boundary with a real login.

Open a private or incognito browser window. This keeps your admin session separate from the test.
Sign in to portal.azure.com as a user who belongs to SG-DevOps.
Navigate to a resource group in your subscription.
Click + Create and select Storage account to start the creation wizard.
Confirm you can proceed through the wizard steps. You do not need to complete the creation. This proves the Contributor role grants resource management access.

Now test the boundary that should block this user.

Before you try the next action, what do you think will happen when a Contributor tries to add a role assignment?

Navigate to your subscription by clicking Subscriptions in the left navigation.
Select your subscription from the list.
Click Access control (IAM) in the left menu.
Click + Add and attempt to select Add role assignment.

The Add role assignment option is disabled. This is exactly the boundary working as intended.

Why can't the Contributor assign roles?

The Contributor role's NotActions include Microsoft.Authorization/*/Write and Microsoft.Authorization/*/Delete. These exclusions block any write operation on role assignments, policy assignments, or locks.

This is why a DevOps team member can deploy infrastructure all day but cannot grant themselves or anyone else elevated access. Only the Owner or a Role Based Access Control Administrator can write role assignments.

Add role assignment button is NOT disabled?

If the DevOps user can still add role assignments, the user likely has an additional role assignment (such as Owner or User Access Administrator) from a different group or a direct assignment. Check the user's effective access under Access control (IAM) and select View my access to identify overlapping role assignments.

Remove any extra privileged roles from the test user, sign out and back in, then retry.

Still not working as expected? Help me troubleshoot why my Contributor user can still assign roles.

Test DB Team access boundaries

The SQL DB Contributor role manages SQL databases but does not include permissions for compute, networking, or storage resources. You are about to hit that wall deliberately.

Open another private or incognito browser window.
Sign in to portal.azure.com as a user who belongs to SG-DBTeam.

What do you think will happen when someone with only SQL DB Contributor tries to create a Virtual Machine?

In the portal search bar, type Virtual machines and select it from the results.
Click + Create and select Azure virtual machine.
Attempt to proceed through the creation wizard. You will receive an authorization error because SQL DB Contributor does not include compute permissions.

The portal blocks the operation with an authorization failure. This confirms the DB Team cannot touch resources outside their SQL scope.

Now confirm the role does grant SQL access.

In the portal search bar, type SQL databases and select it from the results.
Confirm you can access the SQL database management blades without error. The page should load normally, showing any existing databases or an empty list.

What does SQL DB Contributor actually cover?

SQL DB Contributor lets you manage SQL databases but not SQL servers. It does not grant access to the data inside the databases (that is the data plane). It also does not cover security-related features like auditing or threat detection policies.

This is intentional. A narrow role means a compromised DB Team account cannot pivot to managing compute, networking, or granting itself broader access.

DB Team user can create a VM?

If the DB Team user can proceed through the VM creation wizard, the user has additional roles beyond SQL DB Contributor. Return to your admin session and navigate to the subscription's Access control (IAM) blade. Open the Role assignments tab and filter by the test user's name. Confirm they only appear through SG-DBTeam with SQL DB Contributor.

Remove any extra direct role assignments, have the user sign out and back in, then retry.

Need more help? Help me figure out why my SQL DB Contributor user can create VMs.

Confirm and document isolation results

Your two tests prove that the RBAC boundaries are working correctly.

DevOps (Contributor): can create and manage resources across the subscription. Cannot assign roles to anyone.
DB Team (SQL DB Contributor): can manage SQL databases. Cannot create Virtual Machines or other compute and storage resources outside their scope.

This confirms that group membership drives access, and each group's role boundaries hold under real usage.

Your access boundaries are proven and documented. Next, you will tighten the Administrators group further by requiring just-in-time activation for Owner access through Privileged Identity Management.

Enable PIM for the Administrators Group

Your three security groups are in place, roles are assigned, and access isolation is proven. There is one remaining gap: SG-Administrators currently holds standing Owner access 24/7.

If an admin account is compromised, the attacker inherits full subscription control with zero friction. Privileged Identity Management closes this gap by forcing administrators to explicitly activate their elevated role for a limited time window, with MFA and a full audit trail. This is the production equivalent of temporary credentials.

In this step, get ready to:

Remove the standing Owner assignment from SG-Administrators.
Configure an Eligible Owner assignment through PIM with an 8-hour activation window.
Test the just-in-time activation flow as an Administrators group member.

Remove the standing Owner assignment

Before you can create an Eligible assignment in PIM, you need to remove the existing Active/Permanent Owner role assignment for SG-Administrators. Having both an Active and an Eligible assignment for the same role defeats the purpose of just-in-time access.

Switch to the Azure portal tab at portal.azure.com.
Navigate to Subscriptions and select your subscription.
Click Access control (IAM) in the left menu.
Click the Role assignments tab.
Locate the SG-Administrators entry with the Owner role.
Add a checkmark next to SG-Administrators.
Click Remove at the top of the list.
In the confirmation dialog, click Yes.

The Role assignments tab now shows SG-Administrators is gone from the Owner row. Only SG-DevOps (Contributor) and SG-DBTeam (SQL DB Contributor) remain.

Seeing a blocked removal?

If this is the last Owner assignment on the subscription, Azure may block removal. You must be signed in as a Global Administrator to override this. Alternatively, ensure your personal account still has Owner separately before removing the group assignment.

Ask for help: Why can't I remove the last Owner role assignment from my Azure subscription?

Create an Eligible assignment in PIM

With the standing access removed, you will now configure PIM so that SG-Administrators can activate Owner access on demand for up to 8 hours at a time.

Switch to your Microsoft Entra admin center tab at entra.microsoft.com.
In the left navigation, expand Identity governance.
Click Privileged Identity Management.
Click Azure resources.

First time using PIM for Azure resources?

If this is your first time here, you may see a Discover resources page. Click Discover resources, select your subscription from the list, and click Manage resource to onboard it. Confirm with Yes when prompted. This registers the PIM service principal on your subscription.

Select your subscription from the list of Azure resources.
Click Assign.
On the Role tab, select Owner.
On the Members tab, click Select member(s).
Search for SG-Administrators and select it.
On the Assignment type tab, select Eligible.
Set the duration to 8 hours.
Click Review + assign to complete the assignment.

What does Eligible mean?

An Eligible assignment means the user must perform one or more actions to use the role. This includes completing a multifactor authentication check and providing a business justification. The role is not active until the user explicitly activates it.

This eliminates standing access. Even if an admin's credentials are compromised, the attacker cannot use Owner-level permissions without completing the activation workflow.

After the assignment is created, return to the Azure resources view for your subscription in PIM. You should see SG-Administrators listed under Eligible assignments for the Owner role.

Test the just-in-time activation flow

Configuration looks correct on paper, but you need to prove an administrator can actually activate the role and receive time-bound Owner access.

Open a private/incognito browser window.
Sign in to portal.azure.com as a user who belongs to SG-Administrators.
Search for Privileged Identity Management in the portal search bar and open it.
Click My roles in the left navigation.
Click Azure resources.

Before you proceed, what do you expect to see in the list of roles? Will Owner appear as Active or Eligible?

Confirm the Owner role appears as Eligible (not Active).
Click Activate next to the Owner role.
Enter a justification (for example, "Testing PIM activation for project setup").
Complete the MFA prompt when it appears.
Click Activate to confirm.

After activation completes, the Owner role moves to the Active tab with a time-bound expiration. Navigate to your subscription and confirm you now have full Owner access.

Why is this better than standing access?

With this configuration, admin credentials at rest grant zero elevated permissions. The activation creates a time-bound session (maximum 8 hours) with a full audit trail. Every activation is logged with the justification, the user, the time, and the duration.

Microsoft recommends a maximum of 3 subscription Owners to reduce breach risk. PIM takes this further by ensuring those Owners only have active control when they explicitly need it.

Owner role not showing under My roles?

Make sure the user you signed in as is a direct member of SG-Administrators. Nested group membership is not supported for PIM-eligible assignments. Also verify that you selected the correct subscription when you created the Eligible assignment.

Ask for help: Why doesn't my Eligible Owner role appear in PIM My roles?

Your Administrators group now operates on the principle of least privilege. Elevated access only exists for the exact window it is needed, with justification and MFA enforced every time.

Secret mission

Create a Management Group Hierarchy for Multi-Client Scale

Your current RBAC setup works for one subscription. But what happens when you onboard multiple clients, each with their own Dev, UAT, and Prod environments? In this secret mission, you'll build a management group hierarchy that lets you assign permissions once and have them cascade to all child subscriptions automatically.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. The security groups, role assignments, and management groups are free. The only ongoing cost is the Entra ID P2 license required for PIM.

Cost warning

If your Entra ID P2 free trial expires and you do not cancel, you will be charged $9 per user per month. If you do not plan to continue using Privileged Identity Management, disable the trial before it converts to a paid subscription.

Resources you used:

Three Entra ID security groups (SG-Administrators, SG-DevOps, SG-DBTeam).
Test users (if created).
Azure RBAC role assignments at subscription scope (Contributor for SG-DevOps, SQL DB Contributor for SG-DBTeam).
PIM eligible assignments for SG-Administrators (at subscription scope and ClientA management group scope).
Management group hierarchy: FIBI-SAAS, ClientA, Dev, UAT, Prod (Secret Mission).
RBAC role assignments at ClientA management group scope (Secret Mission).
Microsoft Entra ID P2 trial license.

Keep everything running

No action needed. Choose this if you are still actively building on this access control structure or plan to use PIM long-term.

The three security groups and RBAC role assignments persist at no cost. Azure RBAC is free and included with your subscription.
Management groups persist at no cost.
PIM requires maintaining the Entra ID P2 license. Track your 30-day trial expiry date to decide whether to continue or cancel.

Pause - I'll come back to this later

There are no running compute resources to shut down. Your groups, role assignments, and management groups are static configurations that persist without ongoing cost apart from the P2 license for PIM.

If you want to pause PIM costs, note when your P2 trial expires. You can let it lapse and re-enable later if needed.
All role assignments and group memberships remain intact. You can return and pick up where you left off.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow the steps below in order.

Remove PIM eligible assignments: In the Entra admin center, navigate to Identity governance > Privileged Identity Management > Azure resources. Select your subscription, then under Manage select Roles. Click the Owner role, open the Eligible assignments tab, find SG-Administrators, and remove the assignment. Repeat for the ClientA management group scope if you completed the Secret Mission.
Remove RBAC role assignments at subscription scope: In the Azure portal, navigate to your subscription > Access control (IAM) > Role assignments. Select the SG-DevOps Contributor assignment, click Remove, and confirm. Repeat for the SG-DBTeam SQL DB Contributor assignment.
Remove RBAC role assignments at management group scope (Secret Mission): Navigate to Management groups > ClientA > Access control (IAM) > Role assignments. Remove the Contributor assignment for SG-DevOps and the SQL DB Contributor assignment for SG-DBTeam.
Delete management groups (Secret Mission): You must delete from the bottom up. First move any subscriptions back to the Tenant Root Group. Then navigate to Management groups in the Azure portal. Select the Dev management group, click Details, then click Delete and confirm. Repeat for UAT, then Prod, then ClientA, then FIBI-SAAS.
Delete security groups: In the Entra admin center, navigate to Identity > Groups > All groups. Search for SG-Administrators, select it, and click Delete. Repeat for SG-DevOps and SG-DBTeam.
Delete test users (if created): In the Entra admin center, navigate to Identity > Users > All users. Select each test user and click Delete.
Disable the P2 trial: If your Entra ID P2 trial is still active and you no longer need PIM, let it expire naturally or cancel it through your organization's license and subscription management page in the Microsoft 365 admin center.

Nice Work!

You've just built a production-grade, group-based access control system for your Azure subscription using Entra ID security groups and Azure RBAC.

Your team members now get precisely scoped permissions through group membership, and Administrators must explicitly activate their elevated privileges before they can manage access.

You've learned how to:

Build a group-based access control system with three Entra ID security groups mapped to distinct Azure RBAC roles at subscription scope, so onboarding a new team member is as simple as adding them to a group.
Test and prove access isolation where DevOps can deploy resources but cannot assign roles, and DB Team is restricted to SQL database management only.
Configure Privileged Identity Management for the Administrators group, replacing standing Owner access with just-in-time, time-bound, MFA-protected activation.
(Secret Mission) Created a Management Group hierarchy (Tenant Root Group > FIBI-SAAS > ClientA > Dev/UAT/Prod) for multi-client, multi-environment subscription structure with inherited role assignments.

Ready to quiz yourself?