Microsoft AB-900: Identity and Access for AI

Identity and access are foundational to Microsoft AB-900 because Microsoft 365 Copilot and agents operate inside an existing tenant security model. Users, groups, authentication methods, Conditional Access, single sign-on, privileged roles, and application identities determine who can reach both AI features and the data behind them.

The exam does not require advanced identity engineering, but it does expect candidates to distinguish authentication from authorization, recognize Microsoft Entra capabilities, troubleshoot common sign-in issues, and understand how privileged and application access should be controlled.

Separate authentication from authorization

Authentication proves who a user or workload is. Authorization determines what that identity is allowed to do. Confusing the two leads to weak troubleshooting: a user can authenticate successfully and still be denied access because of licensing, group membership, role assignment, or resource permissions.

Microsoft Entra ID underpins identity across Microsoft 365; access can depend on tenant membership, application assignment, and resource permissions even after authentication succeeds.

Use strong authentication without creating fragile access

MFA and passwordless methods reduce the risk that a stolen password becomes full account compromise. Administrators should understand which authentication methods are allowed and how policy can require stronger authentication for sensitive scenarios.

Recovery matters too. Users need secure registration and reset paths, and administrators need emergency procedures that do not weaken the tenant’s normal controls.

Apply Conditional Access to context, not just identity

Conditional Access can evaluate user, application, device, location, risk, and authentication strength before granting access. This allows the tenant to require stronger controls when the context is risky instead of applying the same rule to every sign-in.

Troubleshooting requires checking which policies were evaluated and why a sign-in succeeded or failed. A policy can be technically correct yet still disrupt users if exclusions, dependencies, or device assumptions are misunderstood.

Understand single sign-on and session experience

SSO reduces repeated authentication by allowing users to access multiple services through a trusted identity session. This improves usability while centralizing authentication policy.

Single sign-on does not mean unrestricted access. Each service and resource still applies authorization, and Conditional Access can require a fresh or stronger authentication event when risk or sensitivity justifies it.

Use groups and roles to scale administration

Groups make license assignment, application access, and collaboration easier to manage than large collections of individual grants. Roles delegate administrative capability and should be scoped as narrowly as the platform permits.

The general principle behind role-based access control is important: permissions should follow job function and responsibility rather than convenience.

Protect privileged administration with PIM principles

Privileged Identity Management reduces standing administrative access by making roles eligible and activating them when needed. Time limits, approval, MFA, and justification can make high-impact permissions safer.

Even fundamentals candidates should recognize why permanent Global Administrator access is risky. AI administration does not change the security principle that powerful roles deserve stronger oversight.

Recognize app registrations and enterprise applications

Not every identity is a person. Applications and services use identities to request tokens and access APIs. Administrators should understand that app registrations define application identity while enterprise applications represent service principals in a tenant.

Consent and permissions deserve careful review because an application with broad delegated or application permissions can expose data at scale. The fact that an app supports Copilot or agents does not make excessive permissions acceptable.

Troubleshoot sign-in failures systematically

Start with the user and application, then review authentication method, Conditional Access result, licensing, risk, group membership, and service status. Audit and sign-in logs provide evidence that is more useful than guessing.

Identity Secure Score can highlight areas for improvement, but it should guide investigation rather than substitute for understanding the organization’s requirements.

Connect identity decisions to what AI can reveal

Copilot and agents respect the access model around Microsoft 365 content. That makes identity hygiene, group governance, and resource permissions directly relevant to AI security. A broadly shared site is still broadly shared when an AI assistant makes the content easier to discover.

The right exam mindset is therefore layered: establish identity, evaluate sign-in policy, determine authorization, then inspect the underlying resource permissions. Microsoft AB-100 goes deeper into agentic solution design, but AB-900 expects this administrative identity foundation to be clear.

Identity lifecycle starts before sign-in and continues after a user leaves. Provisioning, group membership, license assignment, role activation, and deprovisioning should be automated where practical. Stale accounts and stale group membership become especially risky when AI makes information retrieval easier across many workloads.

Guests and external collaborators deserve a separate access strategy. B2B identities can preserve accountability without creating unmanaged local accounts, but resource owners must still review what external users can access. An agent shared with a team may indirectly expose the same knowledge that team members can already reach.

Device context can strengthen access decisions. Conditional Access can require compliant or managed devices for sensitive applications, reducing the chance that valid credentials on an uncontrolled endpoint become enough to reach corporate data. The specific policy should reflect the organization’s device-management maturity and user population.

Risk-based sign-in controls should be paired with monitoring and response. Blocking every anomalous event can cause disruption, while ignoring risk defeats the purpose of identity signals. Administrators should know how to investigate risky sign-ins and how remediation changes the user’s ability to continue working.

Application consent is an identity-governance issue because permissions can be delegated by users or administrators depending on tenant policy. Organizations should define which permissions require admin consent and should review high-privilege enterprise applications periodically. AI-related apps should not be exempt from that discipline.

Audit trails become essential when investigating unexpected AI access. Sign-in logs can show authentication and Conditional Access outcomes, while audit logs show administrative and user activity across Microsoft 365. Combining those sources can distinguish an identity problem from a resource-permission or application configuration problem.

Emergency access accounts should be protected differently from normal administrators and tested periodically. Their purpose is to recover from identity-control failure, so they should not depend on every control they are intended to bypass. At the same time, monitoring should make any use highly visible because emergency accounts are powerful by design.

License assignment and identity should be investigated together when access fails. A user can have a valid account and successful sign-in yet still lack the product entitlement required for Copilot. This is a useful exam distinction because not every access problem is solved by changing authentication policy.

Privileged role separation matters across admin centers. The person who administers SharePoint does not automatically need broad Entra or Purview authority, and an AI program owner does not need Global Administrator. Delegated roles reduce blast radius and make audit trails more meaningful.

Conditional Access exclusions should be rare and owned. Emergency accounts, service dependencies, or migration scenarios may justify an exception, but broad exclusions can silently defeat a policy. Administrators should review exclusions as part of policy maintenance, not only when a security incident occurs.

Identity architecture should also cover non-human integrations used by agents. Certificates, secrets, and federated workload identity each create different operational requirements. Static secrets that are never rotated can become the weakest point in an otherwise well-governed AI solution.

Group design should avoid nesting and naming practices that make effective access impossible to understand. When users inherit permissions through several layers of groups, administrators can struggle to explain why Copilot can surface particular content. Clear ownership and periodic group review improve both security and troubleshooting.

Single sign-on should be considered together with session controls. A long-lived session can preserve convenience, but sensitive applications may need reauthentication or stronger assurance under specific conditions. Conditional Access can enforce those decisions without requiring users to enter credentials for every ordinary action.

Identity incidents should have a containment path. Disabling an account, revoking sessions, removing risky application consent, and reviewing recent activity are different actions that may be needed depending on what was compromised. The faster administrators can identify the identity object involved, the faster they can choose the correct response.

Identity design should account for service outages as well as attacks. If a required authentication dependency is unavailable, administrators need to know which users and workloads are affected and whether emergency access is possible. Resilience of the identity plane is therefore part of AI service continuity.

Periodic access reviews are especially valuable for privileged groups and sensitive collaboration sites. They give owners a structured opportunity to confirm that members still need access instead of allowing permissions to accumulate indefinitely as employees move between roles.

The exam-level lesson is to troubleshoot access in layers. Confirm the account, authentication event, Conditional Access outcome, entitlement, group or role assignment, and resource permission in order. That sequence prevents administrators from changing security policy when the real problem is licensing or content access.

That layered method is also safer. It preserves strong controls instead of weakening them during troubleshooting and produces evidence that can be audited later if the access issue turns out to be part of a broader security incident.

For AB-900 preparation, keep the focus on practical administration: identify the identity object, follow the access path, use logs, and preserve least privilege while resolving the user’s need.