Part 4: Identity, Access, and Defense

Create a managed identity and prove RBAC access before and after revocation.

Introduction

30 Second Summary

A badge can prove who someone is without giving them permission to enter every room. Digital access creates the same gap, but the difference is easy to miss when all you see is a successful sign-in.

In this project, you will build an Azure identity and defense evidence lab that makes the line between identity and resource access visible. A private dashboard will show a user-assigned managed identity before and after a narrowly scoped Reader assignment.

What You'll Build

Your finished dashboard shows the same managed identity move from no role assignment to Reader access at one resource group while its identity stays unchanged.

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

A private evidence dashboard that separates identity, authentication, and authorization with visible lab results.
A live access demonstration where az900-defense-mi starts with no role assignment at rg-az900-identity-lab before gaining Reader access through Azure RBAC.
An AZ-900 security map that connects Microsoft Entra ID to the live access story. The map covers Zero Trust, defense in depth, plus Foundational CSPM observations from Microsoft Defender for Cloud.
Secret Mission: Prove access revocation by removing Reader from the lab identity. Your dashboard will connect the result to least privilege and assume breach.

Are there any prerequisites?

You need an active Azure subscription with Owner access, or equivalent resource-creation permissions plus Managed Identity Contributor and permission to create role assignments. You will use Microsoft Edge to access the Azure portal plus the Microsoft Entra admin center without enabling premium controls.

Before We Start

Before any portal work begins, commit to the security distinction this lab will prove. Your goal is to show why identity, authentication, and authorization play different roles in controlling Azure access.

Set Up the Identity Evidence Dashboard

A private Azure dashboard in the Azure portal will keep every security observation in one visible workspace. That shared record makes the later before-and-after access checks easy to compare.

First, you will verify both portal sessions. You will then create the evidence dashboard that anchors the rest of the lab.

In this step, get ready to:

Verify the intended Azure subscription plus your access at subscription scope.
Confirm the tenant details shown in the Microsoft Entra admin center.
Save a private dashboard containing the starter Markdown tile.

Verify both portal sessions

The Azure portal shows your subscription resources plus your Azure RBAC access. The Microsoft Entra admin center shows the directory tenant behind those identities.

In Microsoft Edge, open the Azure portal.
Select the intended subscription.
Confirm that the subscription name matches the subscription you plan to use for this lab.
Select Access control (IAM) at the subscription scope.
Select View my access.
Confirm that the displayed access permits resource creation.
Confirm that your access permits role assignments.

What Access Does This Lab Need?

The Owner role covers resource management plus Azure RBAC role assignments.

The User Access Administrator role manages access only. It must be paired with resource-creation permissions plus Managed Identity Contributor for the later lab resource.

Open the Microsoft Entra admin center in a second Microsoft Edge tab.
Select Tenant overview.
Confirm the displayed tenant name.
Confirm the displayed tenant ID.
Confirm the displayed license information.

Both sessions are now ready. You have confirmed the subscription boundary plus the tenant behind it.

Can't Confirm the Required Access?

Check that the Azure portal session uses the account linked to your intended subscription.
If View my access shows only User Access Administrator, confirm your separate resource-creation permissions before continuing.
Confirm that your separate access includes Managed Identity Contributor.
Help me understand whether my Azure access is sufficient for this identity lab.

Create the private dashboard

An Azure dashboard collects related evidence into reusable tiles. New dashboards are private when created.

Switch back to the Azure portal tab from earlier.
Select Dashboard.
Select Create.
Select Custom.

You will see a blank dashboard editor with space for a dashboard name.

Enter AZ-900 Identity and Defense Lab as the dashboard name.
Select Save.

Your evidence workspace now exists as a private dashboard. It is ready for the baseline that the later access checks will build on.

Add the starter evidence tile

A Markdown tile keeps short definitions beside the evidence they explain. This starter tile establishes the security baseline before any lab identity or role assignment exists.

What Does the Starter Tile Capture?

An identity answers who or what is requesting access.

Authentication proves that identity.

Authorization grants or denies access to a resource.

Select Edit on the dashboard from earlier.
Locate Markdown in the Tile Gallery.
Select Add.

You will see the Edit Markdown pane for the new tile.

Select Inline editing in the Edit Markdown pane.
Fill the evidence tile by pasting this content into the editor:

# Identity, Access, and Defense

- Identity asks: Who or what is this?
- Authentication proves an identity.
- Authorization grants or denies access to a resource.
- Lab status: Ready

What Does This Evidence Show?

The tile separates recognition from proof. It also separates proof from permission.

The Lab status: Ready line marks the baseline before the lab creates an identity or grants access.

Select Done.
Select Save.

Before you reload, predict whether the dashboard will preserve the heading plus the ready status.

Select Dashboard in the Azure portal.
Select AZ-900 Identity and Defense Lab.

You should see the starter Markdown tile with the Identity, Access, and Defense heading plus the Lab status: Ready line. Your dashboard now has a saved baseline for every access change that follows.

Don't See the Saved Tile?

Check that you selected Done after editing the Markdown.
Check that you selected Save after leaving the Markdown editor.
Compare the tile content with the full reference below.
Help me troubleshoot a missing or incomplete Markdown tile on my Azure dashboard.

✔️ Awesome, I've got everything!

Great. Your private dashboard contains the complete starter evidence tile.

ⓧ I'd like to double check the full code

Compare the saved Markdown tile in AZ-900 Identity and Defense Lab with this complete reference.

# Identity, Access, and Defense

- Identity asks: Who or what is this?
- Authentication proves an identity.
- Authorization grants or denies access to a resource.
- Lab status: Ready

Your evidence dashboard is ready for a live security demonstration. Next, you will create the workload identity whose access changes this dashboard will record.

Create a Workload Identity

Your private Azure dashboard now gives you one place to capture security evidence. The next part of the lab needs a real identity that Azure can recognize before any access is granted.

A workload identity represents software that needs access to resources. You will create a user-assigned managed identity as a separate Azure resource without storing credentials.

In this step, get ready to:

Start the user-assigned managed identity creation flow.
Create an isolated resource group for the lab.
Record the new identity on your evidence dashboard.

Start the identity creation flow

A user-assigned managed identity has an independent lifecycle. This makes it useful when software needs a reusable Azure identity without a stored password.

Switch back to the Azure portal session from earlier.
Enter Managed Identities in the search bar.
Select Managed Identities under Services.
Select Add at the top of the Managed Identities page.

You'll see the Create User Assigned Managed Identity page with fields for the identity's subscription, resource group, region, and name.

Why a user-assigned identity?

A human test user would require directory-administrator access. It would also introduce a temporary password.

A user-assigned managed identity keeps this lab credential-free. Its independent lifecycle makes the identity easy to inspect as its own Azure resource.

Create the isolated lab resources

The resource group gives the identity a clearly named lab scope. Managed identities can be used at no extra cost.

Select the subscription you verified earlier in the Subscription field.
Select Create new in the Resource group field.
Enter rg-az900-identity-lab as the new resource-group name.
Choose an available Azure region near you in the Region field.
Enter az900-defense-mi in the Name field.
Select Review + create.

Azure checks the resource details. The validation summary should confirm that the identity is ready to create.

The new principal can take a few moments to become searchable after creation. A brief delay here is normal.

Select Create after validation succeeds.

You'll see a successful deployment result when Azure finishes creating the resource group and managed identity.

Can't create the identity?

Confirm that the Subscription field shows the subscription you verified earlier.
Check that your access includes resource-creation permission plus Managed Identity Contributor.
Ask for help with the creation failure using help me diagnose why Azure cannot create my user-assigned managed identity.

Record the visible identity

The identity's resource details provide evidence that it exists independently in Azure. Your dashboard records that evidence before the access comparison begins.

Return to the Managed Identities list from earlier.
Select az900-defense-mi from the list.
Check that Resource group shows rg-az900-identity-lab.
Check that Region shows the region you selected.

You can now see the managed identity as its own Azure resource inside the lab resource group.

Return to Dashboard from earlier.
Select AZ-900 Identity and Defense Lab.
Select Edit in the dashboard toolbar.
Select the edit control on the Markdown tile.
Replace - Lab status: Ready with - Lab identity: az900-defense-mi exists..
Select Done.
Select Save.

Your Markdown tile now ends with Lab identity: az900-defense-mi exists..

✔️ Awesome, I've got everything!

Confirm that the Markdown tile is saved on AZ-900 Identity and Defense Lab.

ⓧ I'd like to double check the full code

Compare your saved Markdown tile with this full version:

# Identity, Access, and Defense

- Identity asks: Who or what is this?
- Authentication proves an identity.
- Authorization grants or denies access to a resource.
- Lab identity: az900-defense-mi exists.

What should match?

The first three bullets preserve the original identity definitions.
The final bullet records the managed identity you created.

Before you complete the final check, do you expect the new identity to appear as its own resource or inside the dashboard?

Enter Managed Identities in the Azure portal search bar.
Select Managed Identities under Services.
Find az900-defense-mi in the identity list.

You'll see az900-defense-mi listed in rg-az900-identity-lab.

Identity missing from the list?

Wait a few moments for the new principal to become searchable.
Confirm that the portal still shows the subscription you selected during creation.
Ask for help finding the resource using help me find my new Azure managed identity.

That's the core resource created. Your lab now has a visible workload identity with its own Azure lifecycle.

Your workload identity is ready for an access check. Next, you'll inspect what Azure reports for this identity at the lab resource-group scope.

Expose the Authorization Gap

Your user-assigned managed identity now exists as a separate Azure resource. The next question is whether that identity can access anything in its resource group.

Azure RBAC separates an identity from its authorization. This step checks access at the resource-group scope.

The Azure portal shows the live result. Your private dashboard preserves that result as evidence.

In this step, get ready to:

Inspect the managed identity's access at rg-az900-identity-lab.
Record the pre-RBAC result on AZ-900 Identity and Defense Lab.

Check the identity at resource-group scope

A role assignment connects a principal to a role at a specific scope. Checking the lab resource group reveals assignments applied there or inherited from a broader scope.

Switch back to the Azure portal tab from earlier.
Use the portal search bar to find rg-az900-identity-lab.
Select rg-az900-identity-lab from the search results.

Why check the resource-group scope?

Azure RBAC scopes can be a resource, resource group, subscription, or management group. This check focuses on the exact scope that contains az900-defense-mi.

The assignments pane also includes roles inherited from broader scopes. That gives you a complete view of the identity's effective assignments at the lab resource group.

Before you run the access check, predict whether identity creation also created a role assignment.

Select Access control (IAM) in the resource group menu.
Select the Check access tab.
Select Check access.
Select Managed identity.
Find az900-defense-mi using the search field.
Select az900-defense-mi to view its assignments pane.

You'll see that az900-defense-mi has no Azure RBAC role assignment at this scope or inherited to it.

This gap is intentional. The identity exists. Its resource access has not been authorized.

What did this access check prove?

Authentication proves which identity is requesting access. Authorization grants or denies that identity access to a resource.

The access check examines the principal at the selected scope. With no role assignment, Azure RBAC has no role that grants resource access there.

Record the pre-RBAC result

The assignments pane provides a live access check. The dashboard turns that temporary result into evidence you can compare after authorization changes.

Return to the AZ-900 Identity and Defense Lab dashboard from earlier.
Select Edit in the dashboard header.
Select the existing Markdown tile to edit it.
Select Inline editing.
Place your cursor after the line ending with Lab identity: az900-defense-mi exists..
Append the pre-RBAC evidence by pasting these lines:

- Before RBAC: az900-defense-mi exists, but it has no role assignment at rg-az900-identity-lab.
- Lesson: Authentication establishes identity; authorization determines permitted resource access.

What does this evidence capture?

The first bullet preserves the observed role-assignment gap at the exact resource-group scope.
The second bullet connects that result to the difference between authentication and authorization.

Select Done to finish editing the Markdown tile.

The tile preview now shows the pre-RBAC result beneath the existing identity evidence.

Select Save to preserve the dashboard changes.

Before you return to the saved dashboard, predict which evidence lines should remain after reload.

Select Dashboard in the Azure portal menu.
Select AZ-900 Identity and Defense Lab.

You'll see the starter Markdown tile with the new Before RBAC and Lesson lines beneath the identity evidence.

You have turned a missing permission into visible evidence that identity and authorization are separate controls.

Dashboard still shows the old text?

Select Done to commit the Markdown tile edit.
Select Save to commit the dashboard edit.
help me troubleshoot why my Azure dashboard Markdown changes are not being saved.

✔️ Awesome, I've got everything!

Your saved dashboard now preserves the identity and its missing resource-group authorization as separate facts.

ⓧ I'd like to double check the full code

Compare the saved Markdown tile with this complete reference:

# Identity, Access, and Defense

- Identity asks: Who or what is this?
- Authentication proves an identity.
- Authorization grants or denies access to a resource.
- Lab identity: az900-defense-mi exists.
- Before RBAC: az900-defense-mi exists, but it has no role assignment at rg-az900-identity-lab.
- Lesson: Authentication establishes identity; authorization determines permitted resource access.

How should the tile compare?

The final two bullets are the additions from this step. Together they preserve the access-check result and the security lesson it demonstrates.

The authorization gap is now visible and documented. Next, you'll close it with a narrowly scoped role assignment and prove that access has changed.

Grant Least-Privilege Access

Your managed identity already exists. The dashboard proves that it has no access at the lab resource-group scope.

This step closes that authorization gap with Azure RBAC. A Reader assignment at only rg-az900-identity-lab applies least privilege without granting modification permissions.

In this step, get ready to:

Select the Reader role at the lab resource-group scope.
Assign active permanent access to az900-defense-mi.
Verify the new authorization and record the result on your dashboard.

Select the narrow Reader role

A role assignment connects three parts: a principal that receives access, a role that defines permitted actions, and a scope where those permissions apply. Your scope stays limited to the lab resource group.

In the Azure portal tab from earlier, return to rg-az900-identity-lab.
Select Access control (IAM) from the resource-group menu.
Select the Role assignments tab.
Select Add.
Select Add role assignment.
On the Role tab, select Reader.
Select Next.

You will see the Members tab. Reader remains selected as the role that you are preparing to assign.

Why Reader at This Scope?

Reader can view control-plane resource information. It cannot change resources.

The resource-group scope keeps that permission inside rg-az900-identity-lab. This is the smallest scope needed for the demonstration.

🙋‍♀️ Unable to Add a Role Assignment?

Return to View my access at the subscription scope. Confirm that your role includes permission to create role assignments.
Confirm that you are working in the intended subscription from earlier.
Help me diagnose why I cannot add the Reader role assignment.

Assign the role to the workload identity

The principal determines who receives the role. Select the existing user-assigned managed identity so the permission applies to the workload identity from your earlier access check.

On the Members tab, select Managed identity.
Select Select members.
In Select managed identities, choose the user-assigned managed identity type.
Select az900-defense-mi.
Select Select.
If the Assignment type tab appears, keep Active selected.
Keep Permanent selected.
Select Review + assign to open the final review.

The review connects az900-defense-mi to Reader at rg-az900-identity-lab.

This grants read-only access within the lab resource group. The identity cannot modify the resources there.

Create the role assignment by selecting Review + assign.
Wait for the portal to finish creating the assignment.

You will return to the role-assignment view. The new assignment identifies az900-defense-mi as the principal with Reader access at this resource-group scope.

What Changed?

The principal is the existing user-assigned managed identity named az900-defense-mi.
The role is Reader, which permits control-plane viewing without resource changes.
The scope is the resource group named rg-az900-identity-lab.

🙋‍♀️ Assignment Not Appearing?

Refresh the role-assignment view after a short wait because new assignments can take time to appear.
Confirm that the principal is az900-defense-mi.
Help me find my new Reader role assignment.

Prove authorization changed

The earlier access check showed an identity with no role assignment. Repeating the same check reveals whether authorization changed while the identity stayed fixed.

Before you recheck, do you expect the identity itself to change, or only its authorization?

Return to the Check access tab in Access control (IAM).
Select Check access.
Select Managed identity.
Find az900-defense-mi.
Select the identity to open its assignments pane.

You will see Reader at rg-az900-identity-lab. The principal remains az900-defense-mi.

What Does This Prove?

The managed identity existed before the assignment. Azure now authorizes that same identity to view resource information at the selected scope.

That is the core proof: the identity stayed stable while its permitted access changed.

Return to Dashboard in the Azure portal.
Select AZ-900 Identity and Defense Lab.
Select Edit.
Select the existing Markdown tile to edit it.
Add the post-RBAC result below the existing lesson by pasting this line:

- After RBAC: Reader at rg-az900-identity-lab. Identity stayed the same; authorization changed.

What Does This Line Record?

The first sentence records the Reader role at the resource-group scope.
The second sentence captures the experiment's result. Authorization changed while the identity remained the same.

Select Done.
Select Save.
Reload AZ-900 Identity and Defense Lab.

You will see the original no-access evidence followed by the new Reader result. Your dashboard now shows that authorization changed without replacing the identity.

Post-RBAC Result Missing?

Select Edit again. Confirm that the new line sits inside the existing Markdown tile.
Select Done before saving the dashboard.
Help me fix the missing post-RBAC dashboard result.

✔️ Awesome, I've got everything!

Great work. Your access check now shows Reader at the lab resource-group scope. Your dashboard records the change.

ⓧ I'd like to double check the full code

Compare your saved Markdown tile with this complete dashboard content.

# Identity, Access, and Defense

- Identity asks: Who or what is this?
- Authentication proves an identity.
- Authorization grants or denies access to a resource.
- Lab identity: az900-defense-mi exists.
- Before RBAC: az900-defense-mi exists, but it has no role assignment at rg-az900-identity-lab.
- Lesson: Authentication establishes identity; authorization determines permitted resource access.
- After RBAC: Reader at rg-az900-identity-lab. Identity stayed the same; authorization changed.

Your lab now proves how a narrow role assignment changes access at a chosen scope. Next, you will connect this live RBAC result to Azure's wider identity and defense controls.

Map Entra Controls and Layered Security

Your workload identity now has read-only access through Azure RBAC. That result proves how authorization controls access at a specific scope.

AZ-900 also asks you to choose the right Microsoft Entra ID directory controls. It also asks how authentication protects access.

In this step, you will connect those controls to policy and security posture. You will keep premium controls and paid protection plans unchanged.

In this step, get ready to:

Review the Microsoft Entra control areas without changing their settings.
Record the free posture information shown by Microsoft Defender for Cloud.
Map Zero Trust and defense in depth around your live Reader-access evidence.

Inspect Microsoft Entra controls safely

The Microsoft Entra admin center groups directory identities, sign-in methods, external access, and policy controls. Your goal is to identify each control's purpose while leaving the tenant configuration untouched.

Some controls can change how people sign in across an organization. Keeping this review read-only protects the tenant while still giving you the AZ-900 decision map.

Switch back to the Microsoft Entra admin center session from earlier.
Select Tenant overview on the home page.
Use Tenant overview to confirm the tenant name, tenant ID, and license information.
Select Users and groups under Entra ID.
Select External identities under Entra ID.
Select Conditional Access under Entra ID.
Select Multifactor authentication under Entra ID.
Select Authentication methods under Entra ID.
Leave every setting unchanged.

You have now viewed the directory, external identity, policy, and authentication areas that appear in the AZ-900 identity objectives.

Why keep these controls read-only?

Conditional Access requires Microsoft Entra ID P1. Risk-based Conditional Access requires Microsoft Entra ID P2.

This project keeps those areas read-only because your tenant license is unknown. You can still learn which control fits each scenario without changing sign-in behavior.

Observe Foundational CSPM

Microsoft Defender for Cloud combines posture management with cloud workload protection. Foundational CSPM provides Secure score, Recommendations, and Asset inventory at no cost.

This area also exposes paid protection controls. Staying on the overview lets you collect evidence without changing the subscription's cost profile.

Switch back to the Azure portal session from earlier.
Enter Microsoft Defender for Cloud in the portal search bar.
Select Microsoft Defender for Cloud from the search results.
Open the overview for the intended project subscription.

You should now see the security posture overview for the selected subscription.

Observe the displayed Secure score information.
Observe the displayed Recommendations information.
Observe the displayed Asset inventory information.
Record the combined result as your Defender for Cloud observation. Use not yet populated for information that is still processing.
Leave Enable all unchanged.
Leave Defender CSPM unchanged.
Leave every workload protection plan unchanged.

Good work. You captured a live posture observation without enabling a paid Defender plan.

Missing posture information?

Confirm that the overview is scoped to the intended subscription.
Record not yet populated when assessment data is still processing.
Ask for help with the overview if the subscription remains unavailable.

Complete the dashboard decision map

Your existing dashboard already contains the live before-and-after RBAC evidence. The final sections turn that result into a wider identity and defense decision map.

Return to the Azure portal dashboard from earlier by selecting Dashboard.
Select AZ-900 Identity and Defense Lab.
Select Edit.
Select Inline editing for the existing Markdown tile.
Append this directory and identity section below the existing RBAC evidence:

## Directory and identity choices
- Microsoft Entra ID: Cloud identity and access management for users, devices, apps, and resources.
- Microsoft Entra Domain Services: Managed domain join, Group Policy, LDAP, and Kerberos/NTLM for legacy workloads without self-managed domain controllers.
- Human identity: Represents a person.
- Workload identity: Represents software such as an application, service, script, or container.

What does this section map?

Microsoft Entra ID manages cloud identities and access decisions.
Microsoft Entra Domain Services supports legacy domain features without self-managed domain controllers.
A human identity represents a person. A workload identity represents software that needs access.

Select Done.
Select Save.

You should see a new section comparing the two directory services. You should also see the human and workload identity definitions.

Missing the directory section?

Confirm that you appended the content below the existing post-RBAC line.
Check that each heading starts with two number signs.
Ask for help fixing the Markdown layout.

Authentication controls prove identity in different ways. Access controls decide what that proven identity may do.

Select Edit on the dashboard.
Select Inline editing for the Markdown tile.
Append this authentication and access section at the bottom:

## Authentication and access choices
- SSO: Authenticate once, then access multiple resources that rely on the same identity.
- MFA: Supply more than one piece of evidence to verify identity.
- Passwordless: Sign in without entering a password, using methods such as Windows Hello for Business, passkeys, or Microsoft Authenticator passwordless.
- External identities: Partners or guests authenticate with their existing credentials while the host organization controls authorization.
- Conditional Access: An if-then Zero Trust policy engine evaluated after first-factor authentication.
- Azure RBAC: Assign a role to a principal at a scope to authorize Azure resource access.

What does this section map?

SSO lets someone authenticate once before accessing resources that use the same identity.
MFA asks for more than one piece of evidence. Passwordless authentication removes the need to enter a password.
Conditional Access evaluates policy after first-factor authentication. Azure RBAC authorizes access by combining a principal, role, and scope.

Select Done.
Select Save.

You should see six authentication and access choices beneath the directory section.

Missing an access choice?

Confirm that the section contains six separate bullet lines.
Check that every bullet begins with a hyphen.
Ask for help comparing the six entries.

Zero Trust provides three principles for evaluating every request. Your Reader assignment already demonstrates least privilege through a narrow role and scope.

Select Edit on the dashboard.
Select Inline editing for the Markdown tile.
Append the three Zero Trust principles at the bottom:

## Zero Trust
1. Verify explicitly
2. Use least privilege access
3. Assume breach

How do the principles fit together?

Verify explicitly evaluates the available identity and request signals.
Use least privilege access limits each identity to the access it needs.
Assume breach limits impact when an attacker is already present.

Select Done.
Select Save.

You should see a numbered list containing all three Zero Trust principles.

Seeing one continuous line?

Confirm that each numbered principle starts on its own line.
Check that the numbers use a full stop after each digit.
Ask for help correcting the numbered Markdown list.

Defense in depth places overlapping safeguards around data. Defender for Cloud supplies posture information that helps you find weaknesses across those layers.

Select Edit on the dashboard.
Select Inline editing for the Markdown tile.
Append the final defense and posture sections at the bottom:

## Defense in depth
Physical security > Identity and access > Perimeter > Network > Compute > Application > Data

## Defender for Cloud
- Foundational CSPM: Secure score, recommendations, and asset inventory at no cost.
- Observation: [[DEFENDER_OBSERVATION="your Defender for Cloud observation"]]
- Paid Defender plans enabled by this project: None

What do these sections prove?

The defense-in-depth line shows seven overlapping layers between physical security and data.
The Defender for Cloud section connects your live posture observation to Foundational CSPM.
The final line records that this project enabled no paid Defender plans.

Select Done.
Select Save.

You should see all seven defense layers. You should also see your recorded Defender for Cloud observation.

Missing your posture observation?

Confirm that you recorded the observation before editing the dashboard.
Check that the observation appears after the Observation: label.
Ask for help restoring the recorded observation.

✔️ Awesome, I've got everything!

Your dashboard now contains the complete identity, access, and layered security map. Make sure the latest dashboard edit is saved.

ⓧ I'd like to double check the full code

Compare your Markdown tile with this complete version. It includes the original identity evidence and every section added in this step.

# Identity, Access, and Defense

- Identity asks: Who or what is this?
- Authentication proves an identity.
- Authorization grants or denies access to a resource.
- Lab identity: az900-defense-mi exists.
- Before RBAC: az900-defense-mi exists, but it has no role assignment at rg-az900-identity-lab.
- Lesson: Authentication establishes identity; authorization determines permitted resource access.
- After RBAC: Reader at rg-az900-identity-lab. Identity stayed the same; authorization changed.

## Directory and identity choices
- Microsoft Entra ID: Cloud identity and access management for users, devices, apps, and resources.
- Microsoft Entra Domain Services: Managed domain join, Group Policy, LDAP, and Kerberos/NTLM for legacy workloads without self-managed domain controllers.
- Human identity: Represents a person.
- Workload identity: Represents software such as an application, service, script, or container.

## Authentication and access choices
- SSO: Authenticate once, then access multiple resources that rely on the same identity.
- MFA: Supply more than one piece of evidence to verify identity.
- Passwordless: Sign in without entering a password, using methods such as Windows Hello for Business, passkeys, or Microsoft Authenticator passwordless.
- External identities: Partners or guests authenticate with their existing credentials while the host organization controls authorization.
- Conditional Access: An if-then Zero Trust policy engine evaluated after first-factor authentication.
- Azure RBAC: Assign a role to a principal at a scope to authorize Azure resource access.

## Zero Trust
1. Verify explicitly
2. Use least privilege access
3. Assume breach

## Defense in depth
Physical security > Identity and access > Perimeter > Network > Compute > Application > Data

## Defender for Cloud
- Foundational CSPM: Secure score, recommendations, and asset inventory at no cost.
- Observation: [[DEFENDER_OBSERVATION="your Defender for Cloud observation"]]
- Paid Defender plans enabled by this project: None

What does the full reference include?

This reference preserves the original RBAC evidence. It adds the complete directory, authentication, Zero Trust, defense, and posture map underneath it.

Before you reload the dashboard, which parts of the security story do you expect to see alongside the live Reader result?

Reload AZ-900 Identity and Defense Lab in the Azure portal.

You should see the original identity evidence and the live Reader result. You should also see both decision sections.

You should see all three Zero Trust principles and all seven defense-in-depth layers. Your Defender for Cloud observation should appear above the confirmation that no paid plans were enabled.

That's the full security map complete. Your dashboard now connects a real authorization result to the wider AZ-900 identity and defense model.

Secret mission

Secret Mission: Revoke Access and Prove Zero Trust

A permanent Reader assignment leaves standing access after the lab task is complete. Remove that assignment, prove the identity remains without Reader authorization, and record the full access lifecycle on your dashboard.

Clean Up Your Resources

Your user-assigned managed identity has no extra cost. Foundational CSPM remains available at no cost.

This project enabled no paid Microsoft Defender for Cloud plans. Decide whether to keep your resources for another demonstration, pause the lab, or delete the remaining resources.

Resources you used:

The private Azure dashboard named AZ-900 Identity and Defense Lab.
The Azure resource group named rg-az900-identity-lab.
The user-assigned managed identity named az900-defense-mi.

Keep everything running

No action is needed. This option preserves the completed security evidence for another review.

Keep the AZ-900 Identity and Defense Lab dashboard as your identity and defense reference.
Keep the rg-az900-identity-lab resource group for another access demonstration.
Keep the az900-defense-mi managed identity for future Azure RBAC practice.
Leave Microsoft Defender for Cloud unchanged.

Pause - I'll come back to this later

There is no running compute workload to stop. The Reader role is already removed, so the lab is paused without standing access at the resource-group scope.

Keep the AZ-900 Identity and Defense Lab dashboard as your saved evidence.
Keep the rg-az900-identity-lab resource group for later revision.
Keep the az900-defense-mi managed identity without a Reader assignment.
Leave Foundational CSPM unchanged.

Delete - I don't want to use this again

This option removes every remaining lab resource. The Reader assignment is already absent, so deletion can start with the managed identity.

Delete the managed identity:

Return to az900-defense-mi in the Azure portal from earlier.
Select Delete.
Select Yes in the confirmation message.

The managed identity should no longer appear under Managed Identities.

Delete the resource group:

Return to rg-az900-identity-lab in the Azure portal.
Select Delete resource group.
Enter rg-az900-identity-lab when prompted.
Complete the deletion.

Once Azure completes the deletion, the resource-group list should no longer show rg-az900-identity-lab.

Delete the private dashboard:

Return to Dashboard in the Azure portal.
Select AZ-900 Identity and Defense Lab.
Select Delete in the page header.
Select OK in the confirmation message.

The private dashboard should no longer appear under Dashboard.

Nice Work!

You did it! Your private evidence dashboard in Azure proves that a workload identity can stay constant while its authorization changes.

You've learned how to:

Built a private identity and defense dashboard that separates identity, authentication, and authorization. Captured the before, grant, and revoke states in one visible workspace.
Created a user-assigned managed identity named az900-defense-mi without storing credentials. Used Azure RBAC to grant the Reader role at rg-az900-identity-lab. Verified that resource access changed while the principal stayed the same.
Compared Microsoft Entra ID with Microsoft Entra Domain Services for cloud identity and legacy domain needs. Mapped SSO, MFA, passwordless authentication, external identities, and Conditional Access to their roles in access decisions. Connected Zero Trust to defense in depth using Foundational CSPM observations from Microsoft Defender for Cloud.
Secret Mission: Removed the Reader role assignment from az900-defense-mi at rg-az900-identity-lab. Verified that access was revoked. Connected the result to least privilege and assume breach.

Ready to quiz yourself?