Mastering Identity and permissions for Microsoft AB-900 Microsoft 365 Copilot and Agent Administration Fundamentals: What Candidates Need to Understand

 

Start with the live AB-900 scope, then separate durable identity principles from changing portal details

As of September 20, 2026, the live English AB-900 skills are the version measured from July 22, 2026. Microsoft has already announced another English certification update for October 14, 2026, so preparation needs two clocks: the blueprint that applies to an exam taken now and the published change date that applies later. Identity and permission reasoning is durable across both. Portal labels and individual feature controls can move, but the exam still expects a candidate to distinguish users, groups, authentication, authorization, Conditional Access, resource permissions, privileged roles, application identities, audit evidence, and the way Microsoft 365 Copilot operates within existing access boundaries.

This article focuses tightly on those identity and permission decisions. If you need the complete exam context first, the AB-900 preparation roadmap explains how identity connects to Microsoft 365 services, Purview, Copilot, agents, licensing, and administration. Here the goal is different: build a control-by-control mental model that lets you diagnose why access works, why it fails, and why a seemingly convenient fix can violate least privilege.

Do not prepare by memorizing which admin center contains a button. Prepare by asking what object is being controlled, which layer owns the decision, what evidence proves the current state, and what the narrowest safe change would be. That method survives product evolution and produces better answers in scenario questions because it turns several overlapping Microsoft 365 controls into a sequence rather than a list.

Use a five-layer access model: identity, authentication, authorization, entitlement, and resource permission

The fastest way to untangle an access scenario is to name the layer that failed. Identity is the directory object: a user, group, service principal, or other security-relevant principal. Authentication is the process of proving that the claimant is the identity it says it is. Authorization is the decision about what an authenticated identity is allowed to do. Entitlement is whether a license or service plan makes a capability available. Resource permission is the effective access to a particular site, file, team, application, agent, or other object. These layers interact, but they are not substitutes for one another.

A user can authenticate successfully and still be denied a SharePoint document because the site or file permission does not allow access. A user can have permission to a site but lack a Copilot license required for a particular experience. A user can be licensed and permitted to a resource yet be blocked by Conditional Access because the sign-in context does not satisfy organizational policy. An administrator can grant a broad directory role and still fail to solve a resource-specific problem because the role is not the control that governs ordinary user access to that object.

In an exam scenario, translate every symptom into evidence. “The password worked” is evidence that one authentication step succeeded; it is not proof that Conditional Access, MFA, licensing, application assignment, or target-resource permission succeeded. “The Copilot icon appears” is evidence of availability or entitlement; it is not proof that every source document is accessible. “The user is in a group” says nothing until you know what that group is used for. Treat each fact as proof of one state only, then keep tracing the chain.

Users and groups are reusable identity objects, so always ask what mechanism gives the group its effect

AB-900 expects familiarity with core Microsoft 365 objects such as users and groups. The important exam skill is not merely recognizing a group name. It is understanding that a group can participate in several different mechanisms: license assignment, application assignment, policy targeting, collaboration membership, or resource authorization. The same identity object can therefore be present in multiple control paths. When a question says “add the user to a group,” the missing reasoning step is: which configured relationship makes membership relevant to this requirement?

This prevents a common mistake in support work as well as exams. Suppose a user joins a team but cannot open a separate SharePoint site that stores a knowledge source. Adding the user to an unrelated licensing group will not fix the site permission. Conversely, adding the user directly to a site may solve content access while leaving the user unlicensed for the Copilot feature being tested. The symptom appears to be one access problem, but the organization has two independent control planes.

Group-based administration is powerful because it reduces one-off grants, but it also introduces timing and inheritance questions. After a membership change, verify the effective state instead of assuming an instantaneous result everywhere. Check that the user is in the intended group, that the group is actually targeted by the license, policy, application, or resource control in question, and that the downstream service has processed the change. If the effective state is wrong, troubleshoot the configured relationship before creating a second, broader workaround.

Authentication proves identity; it does not decide every permission that follows

Authentication methods such as passwords, multifactor authentication, passwordless methods, and federated or single-sign-on experiences belong to the identity-verification layer. Their purpose is to establish sufficient confidence in the sign-in. The exact method can affect risk and policy evaluation, but a successful authentication result does not grant unrestricted Microsoft 365 access. That distinction is foundational because scenario distractors often offer an authentication change for a problem that occurs after authentication has already succeeded.

Single sign-on reduces repeated authentication prompts by allowing an established identity context to be reused across supported applications and services. It is a usability and identity-integration capability, not a bypass around authorization. If a user signs into Microsoft 365 successfully through SSO but receives “access denied” on a protected site, repeating sign-in configuration may be irrelevant. The next question should be whether policy, application assignment, or resource permission rejected the request.

MFA has the same boundary. If a sign-in log shows that an MFA requirement was not satisfied, the authentication or Conditional Access path deserves investigation. If MFA succeeded and the user then lacks a specific file permission, changing MFA methods is unlikely to fix the file. Practice describing what each piece of evidence rules in and rules out. The exam becomes easier when you stop treating every identity symptom as a password problem.

Conditional Access is a policy decision point, not a generic “security switch”

Conditional Access is best understood as a policy engine that evaluates signals and conditions around access, then applies a grant or session requirement according to configured policy. At fundamentals depth, you should be able to recognize why a sign-in might be blocked or challenged and why the same user can receive different outcomes under different circumstances. Location, device state, application context, user or group targeting, authentication strength, and sign-in risk can all contribute to policy evaluation depending on the organization’s configuration.

The crucial troubleshooting habit is to use sign-in evidence before editing policy. If a newly deployed Conditional Access policy coincides with a group of users losing access, confirm whether the policy applied, which condition matched, and which control caused the outcome. Do not disable all Conditional Access as the first response. A broad disablement may restore service while removing a security boundary for every other user. The better answer usually identifies the policy and scope that actually explain the symptom.

Also separate Conditional Access from target-resource permission. Conditional Access decides whether and under what conditions access is granted at the sign-in or session layer. SharePoint permissions, Teams membership, application roles, and other resource controls still decide what the identity can do after reaching the service. A policy can let the user into SharePoint while the site denies a document; a site can grant a document while Conditional Access prevents the session from reaching SharePoint at all.

Risky sign-ins and identity posture are evidence sources, not automatic diagnoses

Microsoft Entra can surface sign-in and identity risk information that helps administrators investigate suspicious activity. In an AB-900 scenario, a risky sign-in is a signal that deserves policy or investigation attention; it is not a universal explanation for every access failure. If the scenario explicitly provides risk evidence, ask how organizational controls are configured to respond. If the scenario instead provides a clean sign-in followed by a resource denial, move to authorization and permission evidence rather than inventing an identity compromise.

Identity Secure Score is another example of a security signal with a specific purpose. It helps communicate identity-security posture and recommended improvement opportunities. It is not the same thing as an audit record of who changed a setting, and it is not a per-request permission evaluator. When the question asks for evidence about administrative activity, audit logs are more direct. When it asks where the organization can identify posture improvements, a secure-score concept is more relevant. Match the evidence source to the question being asked.

Privileged Identity Management addresses standing privilege and privileged-role lifecycle

Privileged Identity Management matters because administrative privilege is different from ordinary user access. A permanent high-privilege assignment increases exposure: a compromised account, accidental action, or stale role can have broader consequences. PIM supports a model in which privileged access can be eligible, activated when needed, time-bound, and governed according to organizational policy. At AB-900 depth, understand the purpose rather than memorizing a portal workflow.

A useful scenario distinction is “needs a privileged administrative capability temporarily” versus “needs permanent access to a business resource.” PIM fits the first kind of requirement when the organization wants tighter control over privileged roles. It does not replace site membership, application assignment, or file permission for ordinary resource access. Giving a user a powerful directory role to solve a document-access problem is both overprivileged and architecturally wrong.

Least privilege therefore has two dimensions: choose the narrowest role or permission, and keep it active only for the necessary scope and duration. In study exercises, rewrite every “grant access” scenario with those questions. What exact action is required? Which object owns that action? Is there a role or permission narrower than global administration? Does the access need to be permanent? What evidence will confirm that the grant worked without opening unrelated resources?

App registrations and enterprise applications represent different sides of application identity

AB-900 includes app registrations and enterprise applications because modern Microsoft 365 access is not only human-to-service. Applications can have identities, permissions, consent, and tenant-specific policy. Think of the registration as the definition of the application identity and its core configuration; think of the enterprise application as the tenant-side service principal that administrators can govern for that tenant. You do not need developer-level protocol expertise to reason about which object an administrator is looking at.

Use the scenario language. If the organization is defining an application’s identity, credentials, redirect configuration, or requested API permissions in its home context, think about the app registration. If the tenant administrator is controlling the application instance in the tenant, assigning users, reviewing consent or permissions, or applying tenant-specific access policy, think about the enterprise application/service-principal side. The exam can test this boundary without requiring code.

Troubleshoot application access the same way you troubleshoot user access: verify the principal, verify authentication, verify consent or authorization, verify assignment or policy, and verify target-resource permission. Avoid solving an application problem by giving a human user broader permissions, or solving a user assignment problem by recreating the application identity. Distinguishing object type prevents destructive “reset everything” responses.

SharePoint permissions are central because Copilot can surface what the signed-in user is already allowed to reach

SharePoint sites, libraries, folders, and files create a permission hierarchy that matters far beyond ordinary document browsing. Microsoft 365 Copilot can use Microsoft 365 data within the user’s permitted context, so poor content permissions can become an AI-era oversharing problem. The important security principle is not that Copilot invents new access. It is that existing access that was previously obscure or rarely exercised may become easier for an authorized user to discover and use through an AI experience.

That makes permission hygiene an architectural prerequisite for Copilot rollout. If a site is intended for a small finance group but broad organization-wide access was granted years ago, an affected user may legitimately retrieve content the business did not intend them to see. The fix is not to disable Copilot globally when the root cause is an overly broad SharePoint permission. Correct the permission boundary, then validate that the user’s effective access and AI experience both reflect the intended design.

At fundamentals depth, be able to reason about site-level roles and more granular permissions without assuming that “member of Microsoft 365” means “member of every site.” Check direct grants, group-based grants, inherited access, sharing links, and the business purpose of the site. When troubleshooting oversharing, use governance and access-reporting evidence to find the broad grant rather than manually opening random files and guessing.

Copilot permission scenarios become clearer when you separate availability, retrieval, and protection

For Copilot, ask three permission questions in order. First, is the user entitled to and allowed to use the Copilot experience? Second, what Microsoft 365 resources can that identity actually access? Third, what protection and governance controls apply to the data and interaction? Licensing or feature policy answers the first question. SharePoint, Teams, Exchange, and other resource permissions heavily influence the second. Microsoft Purview and related security controls help govern the third. Treating these as one “Copilot permission” hides the real design.

Microsoft Graph is part of the data-access architecture that helps Copilot work with Microsoft 365 context, but Graph does not mean “bypass permissions.” A strong mental model is identity-filtered context: the service can use organizational data that the signed-in identity is permitted to access, subject to the relevant product and governance controls. In an exam scenario, therefore, an unexpectedly broad result should trigger a review of underlying access and oversharing before you assume that Copilot itself granted a new permission.

This is also where sensitivity labels, DLP, retention, and other governance concepts interact with access without becoming identical to access. A sensitivity label can classify or protect information; DLP can respond to risky handling; retention governs lifecycle. None of those should be casually substituted for fixing an incorrect site permission. Choose the control that matches the failure mode, then layer protections where the business requires them.

Agent access adds another authorization boundary on top of the data-source boundary

An agent can introduce its own availability, assignment, approval, and lifecycle controls, but the agent still operates within an identity and data-governance environment. A user may be able to open Copilot but not a particular agent because the agent was not deployed or made available to that user. A user may be able to open the agent but receive limited answers because the knowledge source is not accessible. Those are different failures and should lead to different corrective actions.

Use a two-gate test. Gate one asks whether the user is authorized to use the agent. Gate two asks whether the user and the agent experience can reach the required source data under the intended permissions. If gate one fails, investigate deployment, assignment, approval, availability, or policy. If gate one succeeds but only certain content is absent, investigate the source resource and governance boundary. Do not grant a broad site role merely because an agent appears incomplete.

The same discipline applies to custom agents that have actions or connections. An organization should understand what identity is used, what the action can reach, and what approvals or policies govern that path. AB-900 remains a fundamentals exam, so you do not need to engineer every connector. You do need to recognize that adding an agent does not dissolve identity boundaries; it adds another managed object whose access and lifecycle must be intentional.

Audit logs answer “what happened”; permission configuration answers “what is allowed”

A frequent troubleshooting error is to use the wrong evidence source. Permission configuration tells you what should be allowed now. Audit logs can help show user or administrator activity and changes. Sign-in logs show authentication and policy evaluation evidence. Usage analytics describe adoption. Security posture scores identify improvement opportunities. These sources overlap in time but answer different questions. The exam rewards selecting the tool that directly addresses the requirement instead of choosing the most security-sounding product.

Imagine a site suddenly becomes visible to a larger audience. To understand current exposure, inspect effective permissions and access-governance information. To understand who changed the sharing configuration, use audit evidence. To determine whether a particular user’s sign-in was blocked, use sign-in evidence. To decide whether the organization has a broader identity-security improvement backlog, a posture view may help. One incident can require all four, but each serves a different phase of diagnosis.

Scenario 1: the user can sign in to Microsoft 365 but cannot open a Copilot-referenced SharePoint file

Start with the evidence already proven. Successful Microsoft 365 sign-in means you should not reset the password merely because the file is inaccessible. If Copilot itself opens, basic entitlement and service access may also be working. Now test the resource boundary: can the user open the file or containing site directly? Is access inherited through the expected group? Does the sharing model match business intent? If direct access fails, fix the SharePoint permission or group relationship rather than changing Copilot policy.

If direct access succeeds but Copilot still does not surface the expected content, move carefully into product availability, indexing, governance, or experience-specific troubleshooting. The key exam habit is sequencing: do not jump to the deepest product setting until the earlier layers are proven. A good answer changes the smallest control that the evidence actually implicates.

Scenario 2: a new Conditional Access policy blocks only one administrator group

Do not disable the tenant’s security controls globally. Review the affected sign-in and determine whether the policy targeted that group, what condition applied, and what grant requirement failed. If the group was included accidentally, correct the targeting. If the users lack an authentication method required by the intended policy, remediate that prerequisite. If the block is expected because the sign-in context violates policy, the correct action may be to change the context rather than weaken the rule.

Then validate blast radius. Check that users outside the intended scope remain unaffected and that the administrators can perform the required work under compliant conditions. This combines identity, group targeting, authentication, policy, and evidence in one scenario without treating any single layer as “the access system.”

Scenario 3: an agent works for its creator but not for the target department

The creator’s success proves that the agent exists and can operate in at least one context. It does not prove organizational deployment, target-user assignment, or source-data access. Verify whether the agent is approved or available for the intended audience and whether the department is in the correct assignment or policy scope. Then check whether those users can access the underlying knowledge source independently. The failure can sit at either gate.

Avoid the tempting shortcut of copying the creator’s permissions wholesale. A creator may have broad development or source access that ordinary users should not receive. Least privilege means making the consumer path work under the department’s legitimate permissions, not making every consumer equivalent to the builder.

Scenario 4: a user is licensed for Copilot but a feature is missing

A license is evidence of entitlement, not proof that every feature is enabled, deployed, assigned, or immediately available. Check the relevant service plan and organizational feature policy, then verify whether the feature has user, group, tenant, or other scope. If the missing item is an agent, check agent availability and assignment. If the missing result is content, check content permission. Do not respond to every “missing feature” symptom by reassigning the same license.

This scenario is useful because it forces you to use the five-layer model. The identity can be healthy, authentication can succeed, entitlement can be present, and still the final capability can be absent because policy, assignment, or resource permission is different. Write that chain explicitly in your notes until it becomes automatic.

Build hands-on exercises around permission boundaries, not only portal navigation

A small lab can teach more than a long screenshot tour. Create two test users and two groups with deliberately different access. Give both users the same base license, then vary SharePoint site access, application or agent availability, and policy targeting. Predict each user’s effective experience before testing it. If the result surprises you, identify the exact layer you misunderstood. The learning objective is causal reasoning, not button memory.

Add a troubleshooting journal. For each exercise, record intended state, observed state, evidence source, hypothesized failed layer, narrowest corrective action, and post-change validation. Do not write “fixed permissions.” Write “user authenticated successfully; group membership was correct; site membership was missing; added user to intended site group; direct file access and dependent experience validated.” That level of precision is how fundamentals become operational skill.

Use the AB-900 objectives breakdown as a scope check after each exercise. The point is not to turn a fundamentals exam into an enterprise identity-engineering project. Stop when you can identify the object, separate authentication from authorization, explain the purpose of Conditional Access and PIM, distinguish application identity objects, trace resource access, select the right evidence source, and defend a least-privilege correction in realistic scenarios.

Scenario 5: a group change appears correct, but the intended access still does not arrive

Suppose an administrator adds a user to the group that is intended to receive a Copilot entitlement and access to a departmental site. The directory membership looks correct, but the user still cannot use the expected experience. Do not immediately create a direct assignment as a permanent workaround. Verify each dependency separately: confirm the group is actually the one targeted by the license or policy, confirm the membership has been processed, confirm the service plan is enabled, confirm the site uses the intended group for authorization, and test the user experience after the relevant services have reflected the change. A direct grant may mask a broken group design and make later cleanup harder.

This scenario teaches an important administrative principle: desired state and effective state are not the same thing. A directory screen can show the intended membership while a downstream service is still processing it, or the group can be correct while the resource is wired to a different group. The safe troubleshooting path is to prove every relationship in the chain before widening access. For exam questions, that means favoring validation of the configured mechanism over an unrelated broad role or duplicate permission.

Permission changes should have a validation and rollback plan

Even at fundamentals depth, treat access changes as controlled changes. Before modifying a broad group, site role, Conditional Access scope, or agent audience, state who will gain or lose access, what dependent experiences could change, and how you will validate the result. For high-impact controls, use a test user or limited pilot scope when possible. After the change, verify both the positive case and a negative case: the intended user should gain the required capability, while an out-of-scope user should remain unable to reach it. That second test catches accidental overexposure.

Rollback thinking also improves exam reasoning because it forces you to consider blast radius. Disabling a tenant-wide policy, granting a global role, or opening a site to everyone may make a symptom disappear, but it creates a larger security problem and destroys useful diagnostic evidence. A narrow change preserves the rest of the environment and tells you whether your hypothesis was correct. Least privilege is therefore not only a security principle; it is also a troubleshooting discipline.

Prepare for the October 14 update without studying a future blueprint as if it were already live

Microsoft has published that the English AB-900 certification will update on October 14, 2026. If your exam appointment is before that date, the live July 22 scope is the governing reference. If your appointment is on or after the update, compare the then-current study guide with your notes before final practice. Do not mix future wording into today’s blueprint and then assume every previewed change is already being scored.

Identity knowledge is still a strong investment because the durable relationships remain: identities authenticate; policy evaluates context; authorization and resource permissions govern access; privileged roles deserve tighter lifecycle controls; applications have identities and tenant representations; audit evidence explains activity; and Copilot or agents operate inside Microsoft 365 access and governance boundaries. When a wording change arrives, map it onto that model rather than rebuilding your understanding from scratch.

Final readiness test: explain the access chain without saying “it is a permissions issue”

Before you consider this topic ready, take any access scenario and narrate the chain precisely. Name the principal. State how authentication is proven. Identify Conditional Access or other policy evaluation if relevant. Confirm entitlement. Name the application, agent, site, file, team, or other resource whose permission matters. Identify the evidence source that proves the current state. Choose the narrowest change. Then state what you will validate afterward. If you can do that consistently, the overlapping Microsoft 365 controls stop looking like interchangeable security features.

The phrase “permissions issue” is too vague to guide action. AB-900 identity questions become manageable when you can replace it with a sentence such as “authentication succeeded, the user is licensed, the agent is available, but the SharePoint knowledge source is not granted through the intended group” or “the resource permission is correct, but Conditional Access blocks the sign-in before the service is reached.” That is the level of reasoning to carry into the exam and into real Microsoft 365 administration.