Java / Microsoft Entra ID Interview questions

Microsoft Entra ID (formerly Azure Active Directory) is Microsoft's cloud-based identity and access management service. It authenticates users, devices, and applications, then decides what each of them is allowed to reach.

It is the identity layer behind Microsoft 365, Azure, and thousands of third-party SaaS apps. Sign-ins happen over HTTPS using modern protocols such as OAuth 2.0, OpenID Connect, and SAML, not Kerberos or LDAP.

Core capabilities include single sign-on, multifactor authentication, Conditional Access, application management, and device identity. Microsoft renamed Azure AD to Entra ID in 2023; the service and its APIs kept working as before.

A tenant is a dedicated, isolated instance of Microsoft Entra ID that an organization receives when it signs up for a Microsoft cloud service such as Microsoft 365 or Azure. It holds the organization's users, groups, devices, app registrations, and policies.

Every tenant has a unique tenant ID (a GUID) and an initial domain such as contoso.onmicrosoft.com. You can add verified custom domains like contoso.com so users sign in with familiar names.

A tenant is a security boundary. Admins of one tenant cannot manage another tenant's objects unless access is explicitly granted, for example through B2B guests. One Azure subscription trusts exactly one tenant, but a tenant can hold many subscriptions.

Entra ID is sold in a few tiers, and each one builds on the previous. Packaging changes from time to time, so confirm details on Microsoft's licensing page before purchasing.

Entra ID has two group types. Security groups control access to resources and can hold users, devices, service principals, and other groups. Microsoft 365 groups are for collaboration and come with a shared mailbox, calendar, and SharePoint site or Teams team; they can include guests.

Membership can be Assigned (manual), Dynamic User, or Dynamic Device. Dynamic membership is rule-based and needs P1. A typical rule looks like this:

(user.department -eq "Finance") and (user.accountEnabled -eq true)

Groups created with isAssignableToRole can be given Entra admin roles. They must use assigned membership, and lower-privileged admins cannot modify them.

Multifactor authentication (MFA) requires a user to prove identity with at least two of three factor types: something they know (a password), something they have (a phone or security key), or something they are (a biometric).

Entra ID supports Microsoft Authenticator, passkeys and FIDO2 security keys, Windows Hello for Business, certificate-based authentication, OATH tokens, SMS, and voice. Passwordless methods are stronger than SMS or voice, which are open to SIM swapping and interception.

You can enforce MFA with security defaults, legacy per-user settings, or, preferably, Conditional Access, which asks for it only when risk or context calls for it. Users register methods once through a combined registration page shared with SSPR.

Self-service password reset (SSPR) lets users reset or change their own password without calling the helpdesk. They first verify identity with registered methods such as the Authenticator app, phone, or email.

You can enable SSPR for everyone or for a pilot group. For hybrid users, enabling password writeback in Microsoft Entra Connect pushes the new password back to on-premises Active Directory. Writeback needs P1 or higher.

Registration is shared with MFA through the combined security info experience, so users enroll once for both. Resets and registrations are recorded in the audit logs and authentication methods reports.

Security defaults are a free, preconfigured set of identity protections for tenants that don't use Conditional Access. New tenants have them switched on by default.

• All users must register for MFA (within 14 days).
• Administrators must use MFA.
• Legacy authentication protocols are blocked.
• MFA is required for privileged actions such as Azure management.

They are all-or-nothing: you can't exclude accounts or tune individual rules, and you can't run them alongside Conditional Access. Once you need exclusions, location logic, or device conditions, disable them and build Conditional Access policies (P1).

Conditional Access is Entra ID's policy engine, best understood as if-then rules: if a sign-in matches certain signals, then apply an access decision. It is the main enforcement point for Zero Trust and requires Entra ID P1.

Policies are enforced after first-factor authentication succeeds. A sensible start is the template that requires MFA for admins, plus a policy that blocks legacy authentication.

An app registration is how you tell Entra ID about an application you build so it can use the identity platform. It creates an application object in the app's home tenant, which is the global definition of the app.

It stores the Application (client) ID, redirect URIs, supported account types, credentials (client secrets, certificates, or federated credentials), exposed API scopes, app roles, and requested API permissions.

Registering is a developer task and doesn't give anyone access by itself. When the app is used in a tenant, a matching service principal, shown as an enterprise application, is created there.

An enterprise application is the tenant-local representation of an app, technically its service principal. It exists for gallery apps such as Salesforce, for apps you registered yourself, and for Microsoft's own first-party apps.

This is where admins control how the app behaves in their tenant: configure single sign-on (SAML, OIDC, password-based, linked), assign users and groups, require assignment, set up SCIM provisioning, review consent, and check sign-in activity.

Think of the app registration as the blueprint and the enterprise application as the instance running in your directory.

A service principal is the security identity an application or automation uses inside a tenant. A user account is a person's identity; a service principal is the app's identity. It signs in, holds role assignments, and receives permissions.

There are three kinds: application (created from an app registration), managed identity, and legacy. One is created automatically when you register an app, consent to a multitenant app, or enable a managed identity.

Because permissions are granted to the service principal, both Azure RBAC and Entra roles can target it directly. A common CLI example for a deployment pipeline:

az ad sp create-for-rbac --name "deploy-sp" --role Reader --scopes /subscriptions/<sub-id>

A managed identity gives an Azure resource (a VM, App Service, Function, Logic App, or AKS workload) an Entra identity whose credentials Azure creates, stores, and rotates. Your code never handles a secret.

The code requests a token from the local Instance Metadata Service or the App Service identity endpoint, then presents it to services that support Entra authentication, such as Key Vault, Storage, or SQL Database.

var credential = new DefaultAzureCredential();
var client = new SecretClient(new Uri("https://myvault.vault.azure.net/"), credential);

This removes connection strings and client secrets that tend to leak into repositories, which is why it is the preferred way for Azure-hosted workloads to authenticate.

Azure offers two types of managed identity, and the choice mostly comes down to lifecycle and sharing.

User-assigned identities let you grant RBAC roles once and reuse them across resources, which also avoids waiting on role propagation each time a resource is rebuilt.

Entra role-based access control gives administrators only the directory permissions their job needs. A role assignment combines three things: a security principal (user, group, or service principal), a role definition, and a scope.

There are many built-in roles, for example User Administrator, Helpdesk Administrator, Security Reader, Application Administrator, and Global Administrator. With P1 you can also create custom roles from specific permissions.

Scope can be the whole tenant, an administrative unit, or a single object such as one app registration. Prefer narrow roles over Global Administrator, and keep that role to a handful of accounts.

An administrative unit (AU) is a container that limits where a role applies. Instead of making someone Helpdesk Administrator for the whole tenant, you scope the role to an AU that holds, for instance, only one regional office's users and devices.

AUs can contain users, groups, and devices, with assigned or dynamic membership (P1). Roles that work at AU scope include User Administrator, Groups Administrator, Helpdesk Administrator, and Authentication Administrator.

A restricted management administrative unit goes further: objects inside can only be modified by admins assigned within that AU, so even tenant-wide User Administrators can't touch them. That protects executive accounts or sensitive groups.

Microsoft Entra Connect is the on-premises tool that links Active Directory Domain Services to Entra ID so users have one identity in both worlds. It is the foundation of hybrid identity.

• Synchronization of users, groups, and contacts, with a default delta cycle every 30 minutes.
• Sign-in method choice: password hash sync, pass-through authentication, or federation with AD FS.
• Writeback options such as password, device, and group writeback.
• Entra Connect Health for monitoring.

It runs on a domain-joined Windows Server, and a second server can sit in staging mode as a standby. Filtering by domain, OU, or attribute decides which objects sync.

B2B collaboration lets you invite external people, such as partners, vendors, or contractors, as guest users in your tenant. Guests sign in with their own identity (their work account, a Microsoft account, Google, or an email one-time passcode) while you control what they can reach.

The flow is simple: an admin or permitted user sends an invitation, the guest redeems it, and a guest object with userType = Guest appears in your directory. You then add them to groups, apps, or Teams.

You manage risk with guest access restrictions, Conditional Access, cross-tenant access settings, and access reviews that remove stale guests. You never manage the guest's password; their home identity provider does.

A device can relate to Entra ID in three ways, depending on who owns it and where it is managed.

Joined and hybrid joined devices can be managed with Intune, and compliance state can then be required in Conditional Access.

Privileged Identity Management (PIM) provides just-in-time, time-bound, and approval-based activation of privileged roles so admins don't hold standing access. It covers Entra roles, Azure resource roles, and PIM for Groups, and needs Entra ID P2 or Governance.

Users are made eligible for a role. When they need it, they activate it, possibly with MFA, a justification, a ticket number, and approval. The role is removed automatically when the window ends, for example after 8 hours.

PIM also raises alerts on risky patterns, keeps an audit history of every activation, and supports access reviews of privileged roles. The goal is to shrink the number of permanent Global Administrators.

Microsoft Entra ID Protection detects identity risk using Microsoft's signals and machine learning, then lets you respond automatically. It tracks two kinds of risk: sign-in risk (this attempt looks suspicious) and user risk (this account may be compromised).

Detections include leaked credentials, anonymous IP addresses, atypical travel, unfamiliar sign-in properties, password spray, and anomalous token activity. Risk is rated low, medium, or high.

You respond with risk-based Conditional Access: require MFA at medium sign-in risk, force a secure password change at high user risk. Admins review the Risky users and Risky sign-ins reports. Full capabilities need P2.

Sign-in logs record every authentication: who, which app, from where, on which device, whether Conditional Access applied, and the result code. Audit logs record directory changes such as user creation, role assignments, policy edits, and consent grants. Provisioning logs cover sync activity.

Sign-in logs are split into interactive user, non-interactive user, service principal, and managed identity sign-ins. Portal retention is 7 days for Free and 30 days for P1 and P2.

For longer retention or analysis, route them with diagnostic settings to Log Analytics, a storage account, or Event Hubs.

Microsoft Entra External ID is Microsoft's unified platform for external identities. It covers partner scenarios (B2B collaboration) and customer-facing scenarios (CIAM) using a dedicated external tenant.

In an external tenant you build sign-up and sign-in flows for consumer apps using email and password, one-time passcode, or social providers such as Google and Facebook, with your own branding. It is meant to succeed Azure AD B2C, which is no longer sold to new customers while existing B2C tenants remain supported.

Pick B2B collaboration to give partners access to your internal resources, and an external tenant to authenticate your customers into your own app.

Entra ID is managed programmatically through Microsoft Graph, the unified REST API for Microsoft 365 and Entra data. The older Azure AD Graph API and the AzureAD and MSOnline PowerShell modules are deprecated or retired, so new automation should use Graph.

Connect-MgGraph -Scopes "User.Read.All"
Get-MgUser -Filter "department eq 'Finance'" -Property DisplayName,UserPrincipalName

The same query over REST is GET https://graph.microsoft.com/v1.0/users?$filter=department eq 'Finance'.

Graph uses OAuth, so a script needs either delegated permissions (a signed-in admin) or application permissions (an app identity). Request only the scopes you need.

Entra ID is not a hosted copy of AD DS. They solve different problems and use different protocols, which is why most enterprises run both and sync them.

Apps that depend on Kerberos or LDAP need AD DS or Entra Domain Services; modern web and mobile apps should authenticate against Entra ID directly.

A single-tenant app accepts sign-ins only from accounts in its home tenant. A multitenant app accepts accounts from any Entra tenant, and optionally personal Microsoft accounts, which is what SaaS vendors need.

The choice is the Supported account types setting on the app registration. The application object always lives in the publisher's home tenant. When a customer user or admin consents for the first time, a service principal is created in the customer's tenant that points back to it. From then on the customer controls assignment, consent, and Conditional Access for their copy.

Microsoft Entra Domain Services is a managed, AD DS-compatible domain. Microsoft hosts the domain controllers and you get domain join, LDAP, Kerberos and NTLM, and Group Policy for legacy apps in Azure, without running DCs yourself. Entra ID alone offers none of these.

Identity flows one way, from Entra ID into the managed domain. You manage users in Entra ID (or in on-premises AD synced through Entra Connect), never in the managed domain. Cloud-only users must reset their password after you enable the service so the NTLM and Kerberos hashes get generated.

The managed domain has limits: no schema extensions and no Domain Admin or Enterprise Admin rights. Choose it for lift-and-shift apps that need LDAP or Kerberos, and use Entra ID alone for modern apps.

They are two separate authorization systems that are easy to confuse.

Being Global Administrator does not give access to subscriptions by default. A Global Administrator can switch on Access management for Azure resources to gain User Access Administrator at root scope. Do that only temporarily and treat it as a logged, break-glass action.

With password hash synchronization (PHS), Entra Connect syncs a derived hash of each user's password hash, so users sign in to cloud apps with the same password and Entra ID validates it itself.

1. The sync agent asks a domain controller for password changes using directory replication, under the MSOL_ service account.
2. It takes the existing MD4 hash and runs it through PBKDF2 with HMAC-SHA256, using a per-user salt and 1,000 iterations.
3. The result travels over TLS to Entra ID and is stored there.
4. Changes are picked up roughly every 2 minutes.

The plain-text password and the original hash are never sent. PHS removes any on-premises dependency from cloud sign-in, enables leaked-credential detection in ID Protection, and works well as a backup for the other methods.

It depends on what you need to control. All three keep a single identity, but they differ in where the password is checked.

Microsoft's general guidance is to use PHS unless a specific requirement forces another method, and to enable it even as a fallback when using PTA or federation.

Cloud Sync uses lightweight provisioning agents whose configuration lives in the cloud. Connect Sync is the full on-premises engine with its own SQL database and rich rule editing.

Choose Cloud Sync when you have multiple disconnected AD forests (common after acquisitions), want a simple setup, or want high availability by installing several agents. It also suits organizations that don't need heavy customization.

Choose Connect Sync when you need device writeback, directory extension attribute sync, custom sync rules with attribute transformations, or pass-through authentication, which Cloud Sync does not offer.

The feature gap keeps shrinking, so check Microsoft's current comparison table before deciding. Many tenants start on Cloud Sync and move to Connect only when a missing feature blocks them.

Entra ID evaluates all enabled policies, not first-match. Every policy whose assignments match the sign-in applies, and the user must satisfy the combined grant controls. A block always wins over a grant.

Example: Policy A requires MFA for all cloud apps, and Policy B requires a compliant device for Exchange Online. Signing in to Exchange needs both. Within one policy, grant controls can be set to require all selected controls or just one of them. If session controls conflict, the most restrictive one applies, and an exclusion beats an inclusion in the same assignment.

flowchart TD
A["First-factor sign-in succeeds"] --> B["Find all matching policies"]
B --> C{Any policy blocks?}
C -- Yes --> D["Access blocked"]
C -- No --> E["Combine grant controls"]
E --> F{All controls satisfied?}
F -- Yes --> G["Token issued"]
F -- No --> H["Prompt user for missing control"]

To debug, use the What If tool or the Conditional Access tab on a sign-in log entry.

The main risk is locking people out, so roll out in stages.

1. Set up and test emergency access accounts first.
2. Start from Microsoft's templates, one policy at a time, with a clear naming convention.
3. Create the policy in report-only mode so it logs what it would have done without enforcing it.
4. Review the impact in the Conditional Access insights workbook and test scenarios with What If.
5. Switch it on for a pilot group, then widen to everyone.
6. Monitor sign-in logs for unexpected failures and keep exclusions documented.

A solid baseline is: MFA for admins, MFA for all users, block legacy authentication, and risk-based policies if you have P2. Add device compliance requirements once Intune enrollment is reliable.

Emergency access (break-glass) accounts guarantee you can still manage the tenant when normal admin sign-in fails, for example when a Conditional Access policy misfires, MFA is unavailable, or federation is down.

Microsoft recommends at least two accounts with these traits:

• Cloud-only, using the onmicrosoft.com domain, not synced or federated.
• Permanently assigned Global Administrator, not eligible through PIM.
• Very long random passwords stored securely offline, plus a phishing-resistant method such as a FIDO2 key where possible.
• Excluded from at least some Conditional Access policies, or protected by a dedicated strong one.

Never use them for daily work, and alert on any sign-in so misuse is noticed immediately. Test them on a schedule.

The authorization code flow is the standard way a web or mobile app gets tokens on behalf of a signed-in user. Modern apps add PKCE (Proof Key for Code Exchange) so a stolen code is useless.

sequenceDiagram
participant U as User Browser
participant A as Client App
participant E as Entra ID
participant R as Web API
A->>U: Redirect to authorize endpoint with PKCE challenge
U->>E: Sign in and consent
E->>U: Redirect with authorization code
U->>A: Code delivered to redirect URI
A->>E: POST to token endpoint with code and code verifier
E->>A: ID token, access token, refresh token
A->>R: Call API with access token
R->>A: Protected data

The app first sends the user to /oauth2/v2.0/authorize with its client ID, scopes, redirect URI, and a hashed code challenge. After sign-in and consent, Entra ID returns a short-lived authorization code. The app then redeems it at /oauth2/v2.0/token with the original code verifier, and receives tokens. The API validates the access token's signature, issuer, audience, and expiry before serving data.

Both give users single sign-on to apps, and Entra ID supports both on enterprise applications. The difference is the technology underneath.

For a new app, choose OIDC. Choose SAML when a third-party product supports only SAML or when you're integrating an existing SAML-based app.

Entra ID issues three token types, each with a different audience and purpose.

Access tokens are short-lived, typically 60 to 90 minutes by default. Refresh tokens last much longer but can be revoked, and they are never sent to APIs. An API should validate the access token's signature, iss, aud, expiry, and its scp or roles claims.

The Primary Refresh Token (PRT) is a special long-lived token that enables single sign-on on registered, joined, and hybrid joined devices. It is issued on Windows 10/11 and, through brokers or SSO plug-ins, on macOS, iOS, and Android.

When a user signs in to the device with their work account, or with Windows Hello for Business, the device authenticates to Entra ID and receives a PRT. It is bound to the device using keys protected by the TPM where available, so it can't simply be copied elsewhere.

When the user opens a browser or app that needs Entra ID, the OS component presents the PRT and silently obtains tokens, so no prompt appears. The PRT is valid for 14 days and renewed about every 4 hours while in use. It also carries device and MFA claims, which is how Conditional Access can check compliance without prompting again.

You can verify it with dsregcmd /status and look for AzureAdPrt : YES.

Continuous Access Evaluation (CAE) lets Entra ID and resource providers react to security events in near real time instead of waiting for an access token to expire.

Normally an access token lives 60 to 90 minutes, so a disabled user could keep working until it lapses. With CAE-capable clients and services such as Exchange Online, SharePoint Online, Teams, and Microsoft Graph, tokens can last up to 28 hours, but the service can reject them immediately after a critical event:

• The user account is deleted or disabled.
• The password is changed or reset.
• MFA is enabled for the user.
• An admin explicitly revokes the user's refresh tokens.
• ID Protection flags high user risk.

CAE also supports near real-time enforcement of IP-based Conditional Access policies. When an event fires, the service returns a 401 with a claims challenge, and the client goes back to Entra ID to reauthenticate under current policy.

An authentication strength is a Conditional Access grant control that names exactly which combinations of methods are acceptable. It replaces the blunt "require MFA" when you need to be specific.

You can also build custom strengths, for example allowing only specific FIDO2 key models. A typical design requires phishing-resistant MFA for administrators and sensitive apps, and the standard MFA strength for everyone else. Users who haven't registered a qualifying method are prompted to register one. This feature needs P1.

Phishing resistance comes from public-key cryptography bound to the site's origin. A passkey or FIDO2 key keeps a private key that never leaves the authenticator; Entra ID stores only the public key.

1. Entra ID sends a random challenge to the browser.
2. The browser passes the challenge along with the site's real origin.
3. The user unlocks the authenticator with a biometric or PIN.
4. The authenticator signs the challenge only if the origin matches the one registered for that credential.
5. Entra ID verifies the signature with the stored public key.

A look-alike phishing domain gets nothing: the authenticator won't sign for the wrong origin, and there's no password or one-time code for the victim to type. Push, SMS, and OTP codes, by contrast, can be relayed live by an attacker-in-the-middle proxy. Windows Hello for Business and Authenticator-based passkeys follow the same model.

PIM turns a permanent admin role into one the user must request, justify, and use for a limited time. The behavior is defined in each role's settings: maximum duration, whether MFA, justification, or a ticket is required, who approves, and who is notified.

flowchart TD
A["Eligible user selects Activate"] --> B["PIM checks role settings"]
B --> C{MFA or justification required?}
C -- Yes --> D["User completes MFA and enters reason"]
C -- No --> E{Approval required?}
D --> E
E -- Yes --> F["Approvers notified and decide"]
E -- No --> G["Role becomes active"]
F -- Approved --> G
F -- Denied --> H["Request ends, no access"]
G --> I["Role auto-expires at end of window"]
I --> J["Activation recorded in audit history"]

Assignments are either eligible (must activate) or active (usable now), and either permanent or time-bound. Aim for eligible, time-bound assignments, short activation windows such as 4 to 8 hours, and approval for the most sensitive roles like Global Administrator.

Access reviews let you periodically verify that people still need the access they have, then remove what they don't. You define what is reviewed, who reviews it, and how often.

• Scope: group memberships, app assignments, Entra and Azure roles (through PIM), and access packages. Guest users are a very common target.
• Reviewers: resource or group owners, managers, specific people, or users reviewing their own access.
• Cadence: one-time or recurring, such as quarterly, with a set duration.
• Help for reviewers: recommendations based on recent sign-in activity, and optional required justification.

You also choose what happens if reviewers don't respond; removing access is the safe default. With auto-apply on, decisions are enforced automatically when the review ends. Access reviews are part of ID Governance licensing.

Entitlement management bundles resources into access packages that people can request, instead of admins adding users to groups one by one. Packages live in catalogs that define which resources, such as groups, apps, SharePoint sites, and Teams, can be included.

1. An admin or catalog owner builds an access package with its resources.
2. A policy defines who can request it (internal users, specific partner organizations, any external user), the approval stages, and an expiry.
3. A user requests the package and, if approved, receives all included access at once.
4. Access expires automatically unless renewed, and reviews can be attached.

For external users, approval can auto-create the guest account, and when their last package expires the guest can be removed. This keeps partner access time-boxed and auditable without manual cleanup.

The two permission types decide who the app acts as when it calls an API such as Microsoft Graph.

Application permissions are far more powerful. Mail.Read as an application permission can read every mailbox unless you restrict it, so grant them sparingly and prefer delegated access where a user is present.

Admin consent is required when an app asks for something a regular user can't approve: every application permission, delegated permissions marked as admin-restricted (for example Directory.ReadWrite.All), and any permission at all when tenant policy turns off user consent.

Tenant-wide user consent has three settings: no user consent, user consent only for verified publishers requesting low-risk permissions (the safer, recommended choice), or consent to any app (not recommended).

When users are blocked, enable the admin consent workflow so they can request approval from designated reviewers. Admins can also grant consent in the portal under Enterprise applications, or with a URL like https://login.microsoftonline.com/<tenant>/adminconsent?client_id=<app-id>.

Tight consent settings guard against illicit consent grant attacks, where a malicious app tricks a user into granting access to their mail or files.

Workload identities, meaning service principals and managed identities, don't use MFA, so protect them through credentials, scope, and monitoring.

• Prefer managed identities for anything running in Azure.
• Outside Azure, use federated identity credentials so GitHub Actions, Kubernetes, or other trusted IdPs get tokens without stored secrets.
• If a secret is unavoidable, choose certificates over client secrets, keep lifetimes short, and track expiry.
• Grant the least-privileged permissions, and be especially wary of application permissions like Directory.ReadWrite.All.
• Assign owners, and remove unused apps and stale credentials regularly.
• Use Conditional Access for workload identities (a Workload ID Premium feature) to block sign-ins from outside trusted locations or from risky service principals.
• Watch the service principal sign-in logs for new locations or unusual activity.

Cross-tenant access settings control how your tenant interacts with other Entra tenants. They work in two directions: inbound (their users reaching your resources) and outbound (your users reaching theirs). B2B collaboration and B2B direct connect are configured separately.

There are two layers. Default settings apply to all external organizations, and organizational settings are added per partner tenant ID and override the defaults. In each you can allow or block specific users, groups, and applications.

Trust settings let you accept MFA, compliant-device, and hybrid-joined claims from a partner's tenant, so their users aren't asked for MFA twice. You can also auto-redeem invitations for trusted partners. Separately, tenant restrictions v2 limits which external tenants your own users can sign in to from your network or devices.

A common pattern is to block outbound and inbound by default, then allow only named partners such as Fabrikam with the needed apps.

Work from the evidence in the logs rather than guessing.

1. Collect the user, approximate time, app, and the error text. A correlation ID or request ID from the error page speeds things up.
2. Open Sign-in logs, filter by user, and open the failed event. Check the status, failure reason, and the AADSTS code.
3. Review the Authentication details, Device info, and Conditional Access tabs to see which policy applied and which control failed.
4. Reproduce the scenario with the What If tool.
5. Fix the cause, ask the user to retry, and confirm the new log entry succeeds.

Send the logs to a Log Analytics workspace through Entra's Diagnostic settings. Select the categories you need, such as AuditLogs, SignInLogs, NonInteractiveUserSignInLogs, and ServicePrincipalSignInLogs. The feature needs P1 or P2.

Once data arrives, query it with KQL, build workbooks, and create Azure Monitor alerts or feed Microsoft Sentinel. Failed sign-ins grouped by error and app:

SigninLogs
| where TimeGenerated > ago(24h) and ResultType != "0"
| summarize Failures = count() by ResultType, AppDisplayName
| order by Failures desc

And privileged role additions:

AuditLogs
| where OperationName == "Add member to role"
| project TimeGenerated, InitiatedBy, TargetResources

Good alert candidates are role assignments, Conditional Access policy changes, emergency account sign-ins, and spikes in risky sign-ins.

Think in layers, and make each one reduce standing power or exposure.

Start with the admin model and authentication, since a compromised privileged account does the most damage. Then move outward to apps, governance, and monitoring, measuring progress with Microsoft's Identity Secure Score.