Investigate Identity with Entra ID

Investigate Entra ID access, authentication, and authorization safely.

Introduction

30 Second Summary

The same work account can let you into one screen while another stays out of reach. A successful sign-in confirms who you are without revealing everything you are allowed to manage.

In this project, you will create a read-only identity investigation dossier using Microsoft Entra ID. The dossier uses your access boundary to defend Microsoft Entra ID's Identity as a Service (IDaaS) classification.

What You'll Build

You will present your dossier using real access results that explain exactly what your account can prove about identity permissions.

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

A verified access matrix that labels each identity surface as Accessible, Restricted, or Not available.
An authentication evidence card that explains one observed sign-in or one official learning fallback. A privacy-safe identity model shows how anonymized users and groups lead to an authorization decision.
An IDaaS responsibility map that distinguishes Microsoft Entra ID from IaaS, PaaS, and conventional SaaS. It also connects identity responsibility to Azure Virtual Machines and Azure App Service.
Secret Mission: Diagnose six AZ-900 identity scenarios by identifying each service model, identity feature, permission boundary, and responsible party.

Are there any prerequisites?

Project 1, Compare IaaS and PaaS Hosting, should be completed or planned. Credentials for the account associated with your Azure subscription are required.

No Microsoft Entra administrator role is required because the project verifies your actual access first.

Before We Start

Access to an Azure subscription does not define your Microsoft Entra ID directory permissions. This checkpoint commits you to a privacy-safe plan that records only anonymized or nonsecret observations from read-only routes for Tenant overview, Users, Groups, Microsoft My Account Recent Activity, and accessible sign-in logs while avoiding Create, Edit, Add, Delete, Enable, policy, security information, and download actions.

Verify Your Identity Access Boundary

Azure RBAC controls Azure resources. Microsoft Entra roles control directory resources in Microsoft Entra ID.

Your privacy-safe plan now becomes a real access map. The map keeps later evidence within the boundary your account actually has.

In this step, get ready to:

Confirm that the same account reaches both identity surfaces.
Test each tenant-facing surface without making changes.
Complete an access matrix with a status and safe route for every surface.

Sign in to both identity surfaces

The Microsoft Entra admin center tests tenant-facing directory access. Microsoft My Account tests whether the same identity has a self-service route.

Microsoft Edge keeps both surfaces open in separate tabs. Your organization may show its normal verification prompt after you enter the account.

Press the Windows key to open the search bar.
Type Microsoft Edge and press Enter to open it.
Enter https://entra.microsoft.com/ in the address bar.
Sign in with the account associated with your Azure subscription.
Complete the familiar sign-in verification if your organization requests it.
Open a second browser tab.
Enter https://myaccount.microsoft.com/ in the address bar.
Test whether the same account is accepted as a work or school account.

You'll either reach your work or school account view or find that this self-service route is unavailable. Both outcomes belong in your access matrix.

Record whether Microsoft My Account accepted the same account.

Can't Use the Same Account?

Confirm that you entered the account associated with your Azure subscription on both sites. A personal Microsoft account can follow a different route.

Help me check why the same account cannot access both Microsoft Entra and Microsoft My Account.

Test the tenant-facing pages

The Microsoft Entra admin center is organized around a search bar and a left menu. Each page can have its own permission result.

Keep the Investigation Read-Only

Your read-only guardrails remain in force while you test these pages. An unavailable page is evidence about your access boundary.

Avoid selecting Create, Edit, Add, Delete, Enable, or any policy control.
Record only anonymized or nonsecret observations.

Your access matrix uses three status labels. Each label captures a different permission outcome.

What Do the Statuses Mean?

Accessible means the requested surface renders usable read-only information.
Restricted means the portal recognizes the route but blocks the view for your account.
Not available means the route or requested information does not appear for your account.

Switch back to the Microsoft Entra admin center tab.
Open Tenant overview using the top search bar or left menu.
Classify Tenant overview as Accessible, Restricted, or Not available.
Classify licensing information based on what the page displays.
Open Users using the top search bar or left menu.
Classify Users using one of the three status labels.
Open Groups using the top search bar or left menu.
Classify Groups using one of the three status labels.

You have now checked the tenant overview plus the main directory lists. The final tenant-facing result covers authentication activity.

Open Sign-in logs using the top search bar or left menu.
Classify Sign-in logs using one of the three status labels.

That access check has done its job. Every required surface now has an evidence-based result.

Can't Find a Surface?

Portal access varies by tenant. It can also vary by account type or administrator restrictions.

Retry the surface once using the other navigation route.
Classify the surface as Not available if neither route exposes it.
Help me classify a missing Microsoft Entra surface safely.

Build your access matrix

A route explains how you can continue safely from each result. It also separates tenant-wide evidence from self-service evidence.

How Do the Routes Differ?

The tenant read-only route applies when a tenant page renders without requiring a change.

Reports Reader is the least-privileged role for tenant audit and sign-in logs. Use the Reports Reader route label only when Sign-in logs render.

Microsoft My Account and Microsoft Learn provide the self-service fallback when tenant evidence is restricted or unavailable.

Return to the document that contains your identity investigation plan.
Add a heading named Microsoft Entra access matrix.
Add columns named Surface, Status, Route, and Privacy-safe observation.
Add a row named Tenant overview.
Add a row named Users.
Add a row named Groups.
Add a row named Licensing information when visible.
Add a row named Sign-in logs.

Your five-row structure is ready. The results you just observed now determine each route.

Copy the observed status into every row.
Assign tenant read-only route to each accessible tenant page except Sign-in logs.
Assign Reports Reader route to Sign-in logs only if the page rendered.
Assign Microsoft My Account/Microsoft Learn self-service fallback to each restricted or unavailable surface.
Add one anonymized observation to each row.
Remove any names or email addresses from the matrix.
Remove any tenant IDs or object IDs from the matrix.

Before you review the matrix, do you expect every tenant surface to have the same status?

Review each row to confirm it shows Accessible, Restricted, or Not available.
Confirm that every row names its applicable route.
Confirm that no production identifier appears in the matrix.

You should see five classified rows covering Tenant overview, Users, Groups, licensing information when visible, and Sign-in logs. Different statuses prove that Azure subscription access and Microsoft Entra directory access have separate permission boundaries.

Your identity access boundary is mapped without changing the tenant. Next, you'll use the safest available route to inspect your own authentication evidence.

Inspect Your Authentication Evidence

Your Microsoft Entra ID access matrix now shows which identity surfaces your account can use. That boundary lets you investigate a sign-in without relying on tenant-wide access.

In this step, you will inspect your own authentication evidence through Microsoft My Account or the Microsoft Learn fallback. You will turn that evidence into a privacy-safe card.

In this step, get ready to:

Inspect one familiar sign-in or complete the authentication fallback.
Compare the available authentication evidence.
Build a personal authentication evidence card.

Inspect a familiar sign-in

The Recent Activity page turns your own sign-in history into evidence. A familiar event keeps the investigation personal.

Keep This Investigation Read-Only

Your evidence contains only the fields required for the card. Secrets and production identifiers stay out.

Security information remains unchanged. No unfamiliar activity is treated as safe.

✔️ Microsoft My Account is available

The Microsoft My Account tab from earlier gives you a self-service route to your own sign-in evidence.

Select Recent Activity from the left navigation pane in the Microsoft My Account tab from earlier.
Expand one sign-in item that you recognize.
Record the event status.
Record the application.
Record the authentication method only when the event supports it.
Record the browser or operating-system context.
Record the approximate context or time.
Leave any unfamiliar event unchanged.

ⓧ Microsoft My Account is unavailable

Microsoft Learn provides a safe fallback when your account cannot use Microsoft My Account. The unit takes about six minutes, so set aside a short block of time for it.

Open the Describe Azure authentication methods unit in your browser.
Complete the six-minute unit.
Label your evidence source as Microsoft Learn fallback analysis.

You now have a privacy-safe evidence source. That gives your authentication card a trustworthy foundation.

Can't Access Your Activity?

Use the Microsoft Learn fallback if Microsoft My Account rejects the account or does not show your activity. Keep the rest of the investigation read-only.

Ask for help if you are unsure which route matches your access matrix: help me choose a privacy-safe authentication evidence route

Compare the authentication result

One result gives you an authentication story. A comparison helps you separate observed evidence from assumptions.

How Do Authentication Methods Differ?

Authentication establishes the identity of a person by requiring credentials.
SSO lets a user sign in once to access multiple trusted applications.
MFA requires an extra factor so a compromised password alone is insufficient.
Passwordless authentication establishes identity without requiring a password.

✔️ I used Recent Activity

Return to Recent Activity in the Microsoft My Account tab from earlier.
Enter Unsuccessful in the activity search field.
Record whether the search returns a result.
Compare the result status with your familiar event when one appears.
Compare the application with your familiar event when one appears.
Leave any unfamiliar result unchanged.

Your comparison now records either an unsuccessful result or the absence of one. Both outcomes are valid read-only evidence.

ⓧ I used Microsoft Learn

Return to the completed Microsoft Learn authentication unit.
Identify the credential that established your identity during the sign-in experience.
Determine whether one sign-in opened multiple trusted applications.
Determine whether the experience required an extra factor.
Determine whether the experience avoided a password.
Classify the experience as password, SSO, MFA, or passwordless only where the evidence supports it.

Your analysis now names only an authentication method supported by the available evidence.

Your comparison now distinguishes evidence from guesswork. That is the standard your final card needs to preserve.

Build your evidence card

Authentication establishes identity. Authorization determines what that identity may access.

What Belongs on Your Card?

Authentication method: record the supported method or state that the available evidence does not identify one.
Application: record the application tied to the event or sign-in experience.
Status: record the observed result or the result analyzed through Microsoft Learn.
Browser or operating-system context: record only the general context.
Approximate context: record an approximate time or other nonsecret context.

Authentication establishes identity. Authorization determines permitted access.

SSO, MFA, and passwordless belong to authentication. Azure resource roles belong to authorization.

Return to the document that contains your Microsoft Entra access matrix.
Add a section titled Personal authentication evidence card below the matrix.
Add the five evidence labels shown in the callout.

You should now see a blank evidence card with a place for every required detail.

Fill each label using your familiar event or Microsoft Learn fallback analysis.
Add the authentication and authorization definitions from the callout.
Read the two definitions aloud.

You should hear two separate questions. The first asks who the identity is. The second asks what it may access.

Add the sentence that separates SSO, MFA, and passwordless from Azure resource roles.

Before you review your finished card, do you expect every claim to trace back to your familiar event or the Microsoft Learn fallback?

Review every label against the evidence source you used.

You should see one privacy-safe card with five evidence labels. You should also see clear statements that separate authentication methods from authorization controls.

Spot Personal Details?

Remove names or email addresses before capturing your card. Remove object identifiers or IP addresses as well.

Keep only the general evidence labels from this step. Help me make my authentication evidence card privacy-safe

That is a careful piece of identity investigation. Next, you will model how users and groups connect an authenticated identity to permitted access.

Model Users, Groups, and Authorization

Your authentication evidence card now proves how your own sign-in establishes identity. It still cannot show which directory relationships lead to permitted access.

Authorization needs a model of user types. It also needs group relationships that lead to one permitted resource.

In this step, get ready to:

Compare employee/member identities with guest identities without copying production identifiers.
Model two group relationships using anonymized or fictional structures.
Trace one authorization decision across directory and Azure permission boundaries.

Compare member and guest identities

A user type shapes the directory information an identity can see by default. In Microsoft Entra ID, member users have broader default directory visibility than guest users.

Live user pages can expose personal data. Your model only needs structural labels plus safe summary details.

Create a new privacy-safe identity model in the same format you used for your authentication evidence card.

Your access matrix determines which evidence route is safe for this comparison.

✔️ Users is accessible

Switch back to the Microsoft Entra admin center tab from earlier.
Select Users with the top search bar or left menu.
Inspect the user list in read-only mode.
Select one profile that your account can view.
Preserve the read-only boundary by leaving every change control untouched.

The useful evidence is the account structure. Names, email addresses, and object IDs stay outside your model.

Record whether the account structure shows a member or guest user type.
Record one visible structural detail such as account state or a group summary.
Replace the live identity with Employee/Member or Guest in your model.
Use Microsoft's default-permissions table to add the missing user type to your comparison.

ⓧ Users is restricted or unavailable

A restricted page is valid evidence about your access boundary. Microsoft's documented defaults provide the structural comparison without exposing tenant data.

Open Microsoft's default-permissions table to compare member users with guest users.
Record that the Employee/Member pattern can read directory information with documented exceptions.
Record that the Employee/Member pattern can enumerate users and groups by default.
Record that the Employee/Member pattern can read nonhidden group membership by default.
Record that the Guest pattern has restricted directory permissions by default.
Record that the Guest pattern cannot enumerate all users, groups, or directory objects by default.
Label the comparison as an official-documentation fallback.

Whichever route you used, your model should now show Employee/Member plus Guest as anonymized user types. It should contain only structural evidence.

Map two group relationships

Groups turn individual identities into reusable access relationships. A safe model preserves membership structure without retaining live identifiers.

Your access matrix determines whether you use visible group structure or a fictional fallback.

✔️ Groups is accessible

Switch back to the Microsoft Entra admin center tab from earlier.
Select Groups with the top search bar or left menu.
Inspect the group types available to your account.
Select one nonhidden group that your account can view.
Inspect its membership structure in read-only mode.
Preserve the read-only boundary by leaving every change control untouched.

The live labels have now served their purpose. Your model keeps only the relationship pattern.

Rename the observed group structure Group A in your model.
Add Group B from another visible structure or a fictional fallback.
Connect Employee/Member to Group A.
Connect Guest to Group B.

ⓧ Groups is restricted or unavailable

Fictional groups let you model the relationship safely. They make no claim about a real tenant.

Add a fictional group named Group A to your model.
Connect Employee/Member to Group A.
Add a fictional group named Group B to your model.
Connect Guest to Group B.
Label both group relationships as simulated structures.

You now have the privacy-safe result: two structural group relationships with no tenant identifiers.

Trace the authorization boundary

Microsoft Entra roles govern directory administration. Azure RBAC governs Azure resources.

The Owner role grants Azure resource management at its assigned scope. It does not grant a Microsoft Entra administrator role.

Add the authorization chain identity -> group -> permitted resource to your model.
Set the identity node to Employee/Member or Guest.
Set the group node to Group A or Group B.
Label the final node permitted resource.
Annotate Microsoft Entra roles as the permission system for directory administration.
Annotate Azure RBAC as the permission system for Azure-resource access.
Add a note stating that subscription Owner does not equal a Microsoft Entra administrator role.
Compare your authentication evidence card with the new authorization chain.

Before you review the finished model, predict which permission system controls directory administration.

Review the model for two anonymized user types.
Review the model for two group relationships.
Review the model for one identity -> group -> permitted resource chain.
Review the model for separate Microsoft Entra role and Azure RBAC annotations.
Review the model for the subscription Owner boundary note.

You should see Employee/Member plus Guest. You should also see two group relationships leading to the authorization chain.

Your annotations should assign directory administration to Microsoft Entra roles. They should assign Azure-resource access to Azure RBAC.

You have now turned privacy-safe directory structure into a defensible authorization decision.

Your identity model now connects directory structure to an authorization decision. Next, you will test that model against authentication activity through the least-privileged route your access matrix proved.

Trace Authentication Activity Safely

Your users-and-groups model explains how authorization can flow from an identity to a permitted resource. However, a static model cannot show when an authentication attempt happened or whether it succeeded.

This step adds activity evidence through the least-privileged route your access matrix proved. You will connect one event to your authorization model without exposing anyone's identity.

In this step, get ready to:

Inspect one activity event through an approved read-only route.
Connect the event to your users-and-groups authorization model.
Record the role and license boundaries behind identity activity features.

Choose your evidence route

Your access matrix already identifies the activity route your account can use. That route is the Microsoft Entra admin center, Microsoft My Account, or Microsoft Learn.

Use the Sign-in logs row in your access matrix to choose the matching tab below.

Keep the Evidence Privacy-Safe

Identity activity can contain sensitive details. Your comparison only needs enough evidence to explain the event.

Record the event status.
Record the application.
Record the date or approximate time.
Record only the authentication evidence displayed by your route.
Omit names, email addresses, object IDs, and IP addresses.
Leave the activity in the browser without downloading it.

✔️ Sign-in logs are accessible

This route applies because Step 1 proved that tenant Sign-in logs render for your account.

Return to the Microsoft Entra admin center tab from earlier.
Select Entra ID from the product menu.
Select Monitoring & health from the left menu.
Select Sign-in logs.
Open one existing event that you are allowed to view.
Keep the event details visible for your comparison.

You now have a tenant event that shows whether an authentication attempt succeeded or failed.

ⓧ Sign-in logs are restricted

Your personal activity remains available when the tenant route is restricted. This route keeps the investigation focused on your own account.

Switch back to the Microsoft My Account tab from earlier.
Select Recent Activity from the left navigation pane.
Expand one familiar sign-in item.
Leave any unfamiliar activity unchanged.
Keep the familiar item visible for your comparison.

You now have a personal activity event without relying on tenant-wide permissions.

ⓧ No activity surface is available

The official authentication unit provides a safe fallback when neither activity surface is available.

Return to the Microsoft Learn authentication unit from earlier.
Create one fictional event that states a credential, second factor, application, and success or failure result.
Label the event Simulated.
Keep the simulated event visible for your comparison.

You now have a clearly labeled event that demonstrates the same authentication structure without using tenant data.

Can't Use the Selected Route?

Return to the Sign-in logs row in your access matrix.
Choose the next fallback tab that matches what your account can access.

If the available route still seems unclear, help me choose the safest activity route.

Build the activity comparison

An activity event captures an authentication outcome. Your earlier model supplies the authorization context that surrounds it.

Create an event section with the labels Status, Application, Date or approximate time, Authentication evidence, and Access route.
Fill each label using only the privacy-safe details from your selected event.

You should now see five labeled fields. The access route should identify tenant Sign-in logs, Microsoft My Account Recent Activity, or the simulated Microsoft Learn fallback.

Relate the event to the anonymized Employee/Member or Guest identity type from your model.
Add your existing identity -> group -> permitted resource chain beside the event.

Your comparison now places the activity event beside the group-based authorization decision.

Add one sentence explaining that a successful sign-in establishes identity without proving access to the permitted resource.

Good work. Your comparison now shows where authentication evidence ends and authorization context begins.

Record permission and license boundaries

Tenant activity depends on both role permission and license capability. The next notes separate the activity views included with Microsoft Entra ID Free from features that need higher licensing.

Add a role note stating that Reports Reader is the least-privileged Microsoft Entra role for tenant audit and sign-in logs.
Add an activity-log note stating that Microsoft Entra ID Free includes audit and sign-in logs.

You should now see that an included capability still requires the correct directory permission.

Add a provisioning-log note stating that provisioning logs require P1, P2, or Microsoft Entra Suite.
Add a Usage and insights note stating that the feature requires P1, P2, or Microsoft Entra Suite.

Your monitoring notes now distinguish the included activity logs from licensed monitoring features.

Add a policy note stating that Conditional Access requires P1.
Add a risk-policy note stating that risk-based Conditional Access requires P2.

Your policy notes now show the license boundary between standard Conditional Access and risk-based policies.

Before you review the comparison, do you expect every required field and boundary to be visible?

Review your completed comparison against its event, route, authorization, role, and licensing sections.

You should see a privacy-safe event record with status, application, date or approximate time, and authentication evidence.

You should also see the access route, the link to identity -> group -> permitted resource, and all five role or license notes.

Your event record now connects authentication evidence to its permission boundary. Next, you'll place that identity evidence into the cloud shared-responsibility map.

Map IDaaS Responsibilities

Your authentication activity comparison now connects identity evidence to the route that exposed it. This step turns that work into an AZ-900 shared responsibility map.

Microsoft Entra ID can look like conventional SaaS because you reach it in a browser. Its purpose is to provide identity capabilities across applications.

That service purpose supports an Identity as a Service (IDaaS) classification. The map also shows which responsibilities remain with you across every cloud service model.

In this step, get ready to:

Classify Microsoft Entra ID alongside Azure Virtual Machines as IaaS, Azure App Service as PaaS, and Microsoft 365 as SaaS.
Compare what the customer consumes with the operational layer Microsoft manages for each service.
Preserve customer identity responsibilities across the VM and App Service workloads.

Classify the four service models

A service model reflects what the customer consumes. The service purpose is the key clue when two products share a browser-based interface.

Return to the project notes that contain your authentication activity comparison.
Create a four-column table titled AZ-900 shared-responsibility map.

You should now see an empty comparison table ready for four service models.

Label the first column Microsoft Entra ID with the classification IDaaS.
Label the second column Azure Virtual Machines with the classification IaaS.

Your first two columns now separate identity capabilities from virtualized compute.

Label the third column Azure App Service with the classification PaaS.
Label the fourth column Microsoft 365 with the classification SaaS.

All four columns now have a product and its corresponding cloud service model.

Describe Microsoft Entra ID as supplying directory, authentication, and access-control capabilities across applications.

Why Is Microsoft Entra ID IDaaS?

Microsoft Entra ID supplies identity capabilities that other applications use. Organizations use these capabilities to establish identities and control access.

Microsoft 365 delivers a ready-made productivity application to its users. That service purpose makes it conventional SaaS.

Compare consumption with managed layers

Each column needs two perspectives. One names what the customer consumes. The other names the operational layer Microsoft manages.

State that the Microsoft Entra ID customer consumes directory, authentication, and access-control capabilities across applications.
State that Microsoft manages the hosted identity platform for Microsoft Entra ID.

The IDaaS column now connects the service classification to its cross-application identity purpose.

State that the Azure Virtual Machines customer consumes virtualized compute for workloads.
State that Microsoft manages the physical infrastructure and virtualization layer for Azure Virtual Machines.

The IaaS column now shows that the customer receives compute while Microsoft operates the underlying physical layer.

State that the Azure App Service customer consumes a managed environment for custom application code.
State that Microsoft manages the underlying infrastructure, operating system, and application platform for Azure App Service.

The PaaS column now shows how managed application hosting removes more operational work from the customer.

State that the Microsoft 365 customer consumes a ready-made productivity application.
State that Microsoft manages the hosted application, platform, and infrastructure for Microsoft 365.

Strong work. Every column now connects a service purpose to the operational layer Microsoft manages.

Preserve customer responsibilities

Microsoft manages more operational layers as you move from IaaS to PaaS and SaaS. Customers still retain core responsibilities across every model.

Add a shared customer responsibilities row across the bottom of your map.
Add data to the shared customer responsibilities row.

Your map now shows that customer information remains a customer responsibility across all four models.

Add configurations and settings to the shared customer responsibilities row.
Add identities and users to the shared customer responsibilities row.

The map now keeps customer-controlled settings beside the people and identities that receive access.

Add endpoints to the shared customer responsibilities row.
Add accounts to the shared customer responsibilities row.

Your retained-responsibility row now covers the devices that connect to services and the accounts used to reach them.

Add access management to the shared customer responsibilities row.
Write that the customer retains identity and access responsibility for the Azure Virtual Machines workload.

The VM connection now shows that Microsoft-managed infrastructure does not remove the customer's identity duties.

Write that the customer retains identity and access responsibility for the Azure App Service workload.

Your responsibility map now carries identity and access duties into both workloads from Project 1.

Before you read the map aloud, which customer duty do you expect to remain present across all four models?

Read the four service classifications aloud from left to right.
Check that each column names what the customer consumes.
Check that each column names the operational layer Microsoft manages.
Check that all six retained customer responsibility categories are present.

You should hear Microsoft Entra ID as IDaaS, Azure Virtual Machines as IaaS, Azure App Service as PaaS, and Microsoft 365 as conventional SaaS. Each column should also preserve the customer's retained responsibilities.

✔️ My map matches

Your AZ-900 shared-responsibility map is complete. You can now defend each classification using service purpose and retained customer duties.

ⓧ I'd like to double check

Your AZ-900 comparison should state that Microsoft Entra ID is IDaaS supplying directory, authentication, and access-control capabilities across applications. It should classify Azure Virtual Machines as IaaS, Azure App Service as PaaS, and Microsoft 365 as conventional SaaS.

For each service, the map should state what the customer consumes and which operational layer Microsoft manages.

The map should retain customer responsibility for data, configurations and settings, identities and users, endpoints, accounts, and access management. That retained responsibility should apply to both VM and App Service workloads.

Secret mission

Secret Mission: Solve the Identity Triage Challenge

AZ-900 scenarios often hide the answer inside a few requirement clues. Build six scored cards that identify identity features or cloud service models. Use the evidence to resolve permission boundaries plus shared responsibility while keeping the investigation read-only.

Clean Up Your Resources

Because this investigation stayed read-only, it created no Azure resources or ongoing project costs. Decide whether to keep the evidence available, close the browser tabs for later, or finish with no cleanup action.

Resources you used:

Read-only browser tabs for Microsoft Entra ID, Microsoft My Account, and Microsoft Learn.

Keep everything running

No action needed. Choose this if you want to revisit your identity evidence or continue studying now.

Keep your completed access matrix as part of your AZ-900 study dossier.
Keep your authentication evidence card with the dossier.
Keep your identity model, activity comparison, responsibility map, and six-card challenge together.
Continue using only the established read-only routes when you revisit the investigation.

Pause - I'll come back to this later

Pausing ends the browser session while preserving your completed dossier for another AZ-900 study session.

Close the Microsoft Entra admin center browser tab.
Close the Microsoft My Account browser tab.
Close the Microsoft Learn browser tab.
Keep your completed dossier for your next study session.

Delete - I don't want to use this again

This project left no cloud or tenant state to remove. Finishing requires no Azure resource deletion or Microsoft Entra identity cleanup.

Close every browser tab used for the investigation.
Leave your existing Azure subscription unchanged.
Leave existing tenant identities, policies, licenses, and account settings unchanged.

Nice Work!

Strong finish. You've completed a privacy-safe investigation of Microsoft Entra ID that turns read-only evidence into clear AZ-900 decisions.

What you learned:

Built a read-only access matrix that separates Microsoft Entra roles from Azure RBAC. Protected production identifiers by recording only access status.
Explained authentication with privacy-safe activity evidence. Modeled authorization through the identity -> group -> permitted resource chain.
Classified Microsoft Entra ID as IDaaS. Matched Azure App Service to PaaS. Matched Azure Virtual Machines to IaaS. Matched Microsoft 365 to SaaS. Preserved the customer's responsibility for identities and access management across all four models.
Secret Mission: Diagnosed six AZ-900 scenarios from their clues. Connected one sign-in to SSO. Connected a stolen-password case to MFA. Chose PaaS for custom-code deployment without operating-system patching. Selected Reports Reader for tenant sign-in logs. Kept Azure subscription Owner separate from Microsoft Entra permissions. Retained customer access-management responsibility in SaaS.

Ready to quiz yourself?