Microsoft AB-900 Microsoft 365 Copilot and Agent Administration Fundamentals Complete Guide: Skills, Domains, and a Practical Preparation Roadmap

 

Use the current AB-900 blueprint, not an older Copilot study outline

AB-900 is a new Microsoft fundamentals exam whose scope sits at the intersection of Microsoft 365 administration, identity, security, data governance, Copilot, and agents. That combination makes it easy to study the wrong material. A generic Microsoft 365 fundamentals course can leave you weak on AI administration and Purview. A Copilot end-user course can leave you weak on identity, SharePoint permissions, and administrative controls. A security-only approach can overlook licensing, usage monitoring, prompt management, and agent lifecycle. The safest starting point is the current Microsoft study guide and the exact skill domains it names.

For a September 20, 2026 preparation plan, the current English blueprint is the version that measures skills as of July 22, 2026. Microsoft also states that the English-language certification content will be updated on October 14, 2026. That date matters operationally: if your exam is before the change, use the July 22 objectives as your final checklist; if your appointment is on or after the update, re-check the live study guide before freezing your last study week. Do not assume that a guide written in September will remain exact through late October.

Microsoft currently positions the certification at the beginner level for an administrator role and describes the goal as supporting, securing, and protecting an AI-enabled Microsoft 365 environment. The exam page currently shows 45 minutes for the assessment and English as the offered exam language. Microsoft’s scoring guidance states that 700 or greater is required to pass; that is a scaled score, not a claim that 70 percent of questions must be correct.

What AB-900 is really testing

The word “fundamentals” can be misleading if you interpret it as pure vocabulary recall. The current audience profile expects familiarity with Microsoft 365 core services, security, identity and access, data protection, governance, Microsoft 365 Copilot, and agents. It also expects awareness of the administrative surfaces used for Exchange Online, SharePoint, Teams, Microsoft Entra, and Microsoft Purview. You are not being trained as the deepest specialist in every workload, but you do need to know which administrative object, control, or tool belongs to a scenario and what evidence would confirm that it is working.

Think of the exam as testing an administrative map. A user, group, team, SharePoint site, library, mailbox, distribution group, app registration, enterprise application, sensitivity label, DLP policy, conditional access policy, Copilot license, billing policy, and agent are not interchangeable objects. Each lives in a specific control plane, has a specific security boundary, and changes a different part of the environment. Many scenario questions become straightforward when you identify the object being managed before you evaluate the answer choices.

The whole-exam roadmap in this guide is intentionally broader than a question bank. A detailed domain-by-domain AB-900 objectives breakdown is useful when you are ready to turn each published objective into a concrete study task, but first build the cross-domain relationships that explain why those objectives belong together.

Domain weighting should change how you allocate study time

The current blueprint has three domains. Identifying the core features and objects of Microsoft 365 services carries 30 to 35 percent. Understanding data protection and governance tasks for Microsoft 365 and Copilot carries 35 to 40 percent, making it the largest range. Performing basic administrative tasks for Copilot and agents carries 25 to 30 percent. Those percentages are not a license to ignore smaller topics. They are a planning signal: the largest study block should connect data governance to Copilot behavior, while the other two blocks should establish the Microsoft 365 control plane and then apply it to Copilot and agent administration.

A weak plan studies the three domains as separate chapters. A stronger plan uses one tenant scenario and revisits it from all three angles. Suppose a company is enabling Copilot for a finance team. Domain one asks which users, groups, sites, libraries, identities, and security controls define access. Domain two asks whether sensitive financial data is labeled, overshared, retained, discoverable, or subject to DLP and compliance monitoring. Domain three asks how licenses are assigned, which Copilot capabilities are enabled, how usage is monitored, how prompts are governed, and how agents are approved and observed. One business requirement now exercises all three domains without artificial boundaries.

Build the Microsoft 365 object model before memorizing admin centers

The first domain begins with core Microsoft 365 objects. Licenses assigned to users or groups affect which services and features are available. The Microsoft 365 admin center exposes tenant-level configuration such as domain names and organization settings. Exchange administration focuses on objects such as mailboxes and distribution groups. SharePoint administration focuses on sites, libraries, folders, and the permissions that determine who can reach them. Teams administration adds teams, channels, and policies. The exam value is knowing where a change belongs and what downstream behavior it changes.

Avoid learning this as a portal-navigation quiz. Imagine a new department that needs a collaboration space, a shared mailbox, restricted document access, and Copilot for only a subset of staff. A team or SharePoint site does not replace a mailbox. A distribution group does not create a SharePoint permission boundary. A license assigned to a user does not override a missing site permission. A Teams policy can control a Teams behavior without changing the user’s membership in a sensitive SharePoint site. Map each requirement to the object that owns it.

Licensing questions deserve the same discipline. A user can be correctly created and authenticated while still lacking access to a feature because the required service plan is absent. Conversely, assigning a license does not grant permission to every data source the service can reference. Keep entitlement, identity, authorization, and data permission as separate concepts. This distinction becomes critical once Copilot is introduced, because an AI experience can only be as well-governed as the underlying identities and content permissions.

Identity and security form the trust boundary for every later Copilot scenario

The blueprint expects you to understand Zero Trust principles, authorization, authentication methods, threat protection and intelligence, and Microsoft Defender XDR capabilities. The useful mental model is “verify explicitly, use least privilege, and assume breach,” then ask which control implements that idea in a Microsoft 365 scenario. Authentication establishes who is signing in. Authorization determines what that identity is allowed to do. Conditional Access evaluates signals and conditions before allowing or constraining access. Single sign-on reduces repeated authentication without eliminating the need for authorization.

Microsoft Entra ID is the identity foundation behind many of these decisions. You should understand users and groups, authentication methods, conditional access policies, risky sign-in evidence, and the purpose of Privileged Identity Management. PIM is not simply another group; it is about controlling and time-bounding privileged role activation. Identity Secure Score is a posture signal that can highlight opportunities to strengthen identity configuration, while audit logs provide evidence of user and administrator activity. These tools answer different questions and should not be treated as substitutes.

Sign-in troubleshooting is a good place to practice layered reasoning. If a user cannot access a service, first determine whether authentication failed, conditional access blocked or challenged the sign-in, the user lacks the necessary authorization, or the target service lacks the correct license or object permission. A risky sign-in signal can influence a policy decision; it does not automatically prove the password is wrong. An MFA failure is different from a SharePoint permission denial. Exam questions often reward the candidate who identifies the stage that actually failed.

Know the difference between an app registration and an enterprise application at a conceptual level. An app registration defines an application identity and its configuration in the home tenant; the enterprise application represents the service principal instance used for access and policy in a tenant. You do not need to become an application developer for AB-900, but you should recognize which object is involved when a scenario discusses application identity, consent, sign-in, or tenant-specific access.

Data protection and governance are the center of gravity, not an optional compliance appendix

The largest blueprint area is Microsoft Purview and the controls surrounding Microsoft 365 and Copilot data. The named capabilities include Information Protection, Data Loss Prevention, Insider Risk Management, Communication Compliance, Data Security Posture Management for AI, and Data Lifecycle Management. You also need sensitivity labels, data classification, and retention. Rather than memorize product names independently, group them by the question they answer: What is the data? How sensitive is it? Who can use it? Where can it travel? How long should it remain? What risky behavior is occurring? What evidence must be preserved or reviewed?

Sensitivity labels express classification and can apply protection behavior. DLP policies evaluate content and context to restrict or warn on risky handling. Retention controls the lifecycle of information, which is not the same goal as access control. Insider Risk Management looks for patterns that may indicate risky user behavior. Communication Compliance helps identify policy or conduct concerns in communications. Compliance Manager helps evaluate compliance posture and recommendations. eDiscovery content search supports investigation and collection. Activity Explorer and audit records help you understand what users and administrators actually did.

These distinctions become more important with generative AI because Copilot can surface information quickly. The correct response to that risk is not to treat Copilot as a new permission system. Microsoft documents that Microsoft 365 Copilot grounds responses through Microsoft Graph and respects the user’s existing access boundary. If a user cannot access a source, Copilot does not grant new permission to it. The security problem is therefore often upstream: overly broad SharePoint permissions, broad sharing links, poorly classified data, or weak governance can make content legitimately accessible to too many users before Copilot ever sees it.

That is why oversharing appears explicitly in the current objectives. You should know that SharePoint data access governance reporting and SharePoint Advanced Management capabilities, including restricted access control, can be part of the response. The practical reasoning is to identify which content is accessible, why it is accessible, whether that access is appropriate, and which control narrows the boundary without breaking legitimate collaboration. “Turn off Copilot” is not a substitute for fixing a site whose permissions were already wrong.

Understand how Microsoft Graph, permissions, and Purview controls shape Copilot responses

Copilot’s grounding model is a bridge between AI behavior and classic Microsoft 365 administration. The user enters a prompt; relevant organizational context can be retrieved through Microsoft Graph within that user’s authorized access; the grounded prompt is processed; and the response is returned in the user’s application context. The exam does not require you to reproduce every architecture diagram, but it does require you to understand why identity and content permissions are prerequisites for safe AI behavior.

Permissions alone are not the entire governance story. Microsoft Purview can add protection and monitoring around AI interactions. Sensitivity labels can communicate and enforce data handling requirements. DLP can restrict Copilot from processing content that meets configured conditions, including content with selected sensitivity labels. Audit and activity data can record AI-related activity. DSPM for AI brings data-risk discovery and recommendations into the AI context. The important principle is layered control: access permission answers whether the user can reach the data, while classification, DLP, retention, monitoring, and investigation controls answer what should happen to that data and how activity should be governed.

Responsible AI should be treated as an operational requirement rather than a slogan. An administrator should understand that AI output can be incomplete or context-dependent, that sensitive information needs existing governance, and that enabling features should be accompanied by appropriate monitoring and user guidance. The exam objective sits beside security and governance because responsible deployment depends on both technical controls and clear accountability.

Learn the risk-and-evidence tools by the signal they produce

Several Purview objectives sound similar until you attach them to evidence. Compliance Manager gives compliance posture and improvement guidance. Data Explorer helps locate sensitive information. Insider Risk Management surfaces user-risk patterns according to configured policies. DLP alerts point to policy matches involving protected information. Communication Compliance identifies communications that meet configured policy conditions. Activity Explorer shows activities around labeled or sensitive content. DSPM for AI focuses on AI-related data security posture and activity. eDiscovery content search helps investigators search relevant files and email.

When a scenario asks what to use, underline the verb. “Find where sensitive information exists” points toward classification and exploration. “Stop a sensitive item from being processed in a risky context” points toward a policy control such as DLP. “Review user activity around sensitive data” points toward activity and audit evidence. “Assess compliance risk and recommended actions” points toward Compliance Manager. “Investigate potentially inappropriate communications” is different from “investigate insider data handling.” This verb-to-tool mapping is more durable than memorizing marketing descriptions.

Copilot and agents add a new administrative lifecycle

The third domain moves from the data and identity foundation into basic Copilot and agent operations. You should be able to compare built-in Copilot capabilities with agents, distinguish the monthly license model from pay-as-you-go options including SharePoint-related usage, identify which Copilot features can be enabled or disabled, and recognize use cases for Researcher, Analyst, and custom agents. These are administrative decisions because they affect entitlement, cost, capability, and governance.

A useful distinction is between granting a product entitlement and governing an AI experience. Assigning a Copilot license answers whether a user is entitled to licensed capabilities. A pay-as-you-go billing policy answers how eligible metered usage is funded and tracked. Enabling or disabling a feature changes availability but does not repair underlying data permissions. Monitoring usage tells you whether adoption is occurring; it does not prove that sensitive data is governed correctly. Each control has a different job.

The current objectives also include monitoring Copilot usage and adoption through Copilot Analytics and the Microsoft 365 admin center, along with managing prompts by saving, sharing, scheduling, and deleting them. Treat prompts as manageable artifacts rather than ephemeral text. If an organization allows shared or scheduled prompts, administrators need to think about ownership, audience, content sensitivity, lifecycle, and whether the prompt encourages access to data that should have been restricted at the source.

Agents have their own lifecycle. Candidates should understand configuring user access, creating an agent, the approval process, and monitoring usage, operational insights, and lifecycle through Microsoft 365 and Power Platform administrative experiences. The key reasoning is lifecycle order: create or acquire, control who can use it, approve or govern it, publish or expose it appropriately, observe what it does, and retire or change it when requirements change. A technically functional agent is not automatically an approved enterprise agent.

Practice agent governance as a permission-and-lifecycle problem

Suppose a department creates an agent grounded on a SharePoint site. A useful AB-900 walkthrough asks five questions. Who can use the agent? Which data sources can the agent reference for each user? Who approves the agent for wider distribution? Which tenant controls govern the content and interactions? Which administrative view shows adoption, activity, or lifecycle state? This is better preparation than simply learning the button sequence for agent creation because it connects the feature to the security model.

Remember that agents do not create a magical bypass around Microsoft 365 permissions. If a user cannot access a SharePoint source, the agent should not retrieve that source for the user merely because the maker could access it. Conversely, an overshared site remains a problem because an agent can make already-authorized information easier to discover. The governance task is to make the permission boundary correct before relying on AI-layer controls to compensate for it.

Approval also needs to be separated from access. A user may technically be able to create an agent while the organization still requires an approval process before broad deployment. Monitoring then answers what happens after deployment. If usage is unexpectedly high, low, costly, or associated with risky content, the administrator needs evidence before changing policy. This basic lifecycle reasoning transfers well to scenario questions because it distinguishes creation, entitlement, governance, and operations.

Build a small lab that produces evidence instead of screenshots

A practical AB-900 lab does not need to reproduce a large enterprise. Use a tenant or authorized training environment and create a small set of identities and groups with deliberately different access. Assign or remove a relevant service entitlement where available. Create a SharePoint site with a controlled library, then compare what two users can see. Review the Microsoft 365 admin center, Teams administration, SharePoint administration, Entra, and Purview so you can explain which plane owns each decision.

For identity, create a troubleshooting worksheet rather than changing live production controls casually. Walk through the sign-in evidence you would inspect for an MFA problem, a conditional access block, a risky sign-in, or an authorization problem. Review where audit information appears. If you have a lab that safely permits it, compare a standard user with an eligible privileged role and note what PIM changes about privilege activation. The objective is to learn what evidence separates one failure class from another.

For governance, label a representative file, inspect how classification is surfaced, and study how a DLP or retention policy would use different conditions and actions. Review Activity Explorer or equivalent reporting in a permitted environment. Examine how an overshared SharePoint resource would be identified and what a least-disruptive remediation might look like. Do not build a lab around intentionally leaking real sensitive information; synthetic data is enough to understand control behavior.

For Copilot and agents, trace the lifecycle even if your training tenant does not have every license. Identify where licenses or billing policies would be managed, where usage and adoption are reviewed, where feature controls live, how an agent is created or surfaced, and how access or approval is governed. If you can use the feature safely, create a simple agent against non-sensitive training content and test it with identities that have different source permissions. The result you care about is the access boundary and administrative evidence, not a flashy response.

Use four troubleshooting scenarios to integrate the whole blueprint

Scenario one: a licensed user cannot use the expected Microsoft 365 capability. Do not jump to Copilot configuration. Confirm the user identity, assigned license or group-based licensing path, service status where relevant, and whether the target workload itself is available. If the capability depends on content access, verify the user can reach the underlying site or mailbox directly. This separates entitlement from data authorization.

Scenario two: Copilot surfaces a document that a manager believes should be private. Treat the event as a data-governance investigation. Confirm whether the user already has direct permission to the document or its containing site. Identify the sharing mechanism and whether the item is overshared. Check classification and sensitivity labeling. Determine whether DLP, restricted access, or permission remediation is appropriate. Then review audit or activity evidence. The fastest fix is not necessarily an AI switch; it is the control that corrects the real exposure.

Scenario three: an agent works for its maker but not for another approved user. Separate agent access from source access. Verify that the second user is allowed to use the agent, then verify that the second user can access the knowledge sources the agent expects. Check whether the agent has completed the required approval or publication step. Finally, use operational or administrative insights to determine whether the failure is access, configuration, or availability. This prevents you from granting unnecessary permissions to the underlying data.

Scenario four: Copilot usage grows unexpectedly and finance raises a cost concern. Determine whether the usage is licensed, pay-as-you-go, or a mixture; identify the relevant billing policy; review usage and adoption evidence; and confirm which workload or user population is generating activity. A cost problem should be solved with entitlement, billing, and adoption evidence rather than by changing data protection settings that have no relationship to consumption.

A practical preparation roadmap from first review to exam readiness

Start by printing or copying the current objective list into a tracker and marking the October 14 update warning. Do a diagnostic pass without deep study. For each bullet, classify yourself as “can explain,” “can identify in a scenario,” “can perform or trace,” or “not yet stable.” The verb matters. You may be able to define Conditional Access but still fail to distinguish a conditional access block from a basic authorization failure. You may recognize Purview DLP but still confuse it with retention.

Next, spend a foundation block on Microsoft 365 objects and identity. Build the user-group-license-workload-permission model first. Add Exchange, SharePoint, and Teams object distinctions. Then practice authentication versus authorization, Entra security features, Zero Trust, PIM, app registrations, enterprise applications, sign-in evidence, and audit. This block should make it possible to explain why a user can sign in successfully yet still lack access to a service or item.

Make the largest study block data governance and Copilot data security. Map every Purview feature to the risk it addresses and the evidence it produces. Trace how Copilot uses Microsoft Graph within the user’s permission boundary. Study sensitivity labels, classification, DLP, retention, oversharing, Compliance Manager, Data Explorer, Insider Risk, Communication Compliance, Activity Explorer, DSPM for AI, and eDiscovery. Work through at least two cases where the correct answer is a permission or governance fix rather than an AI configuration change.

Then add the Copilot and agent operations block. Compare capabilities and licensing models. Learn where basic entitlement, billing, feature control, usage monitoring, adoption monitoring, prompt management, user access, agent creation, approval, and lifecycle monitoring fit. Build scenario chains that ask what happens before deployment, at deployment, and after deployment. The exam is easier when you can order the steps instead of memorizing them.

Finish with mixed scenario review. Alternate identity, governance, and AI-administration cases so you cannot rely on chapter context to tell you what the question is testing. For each answer, state which administrative object is changing, which control plane owns it, what evidence you would check first, and what risk the action addresses. If you cannot answer those four questions, the concept is not yet operational enough.

Common preparation mistakes and how to correct them

The first mistake is overstudying end-user Copilot features. AB-900 is an administration credential. End-user capability matters when it changes what administrators license, enable, secure, or monitor, but the exam is not primarily a prompt-writing or productivity tutorial. Redirect time toward governance, permissions, admin centers, and lifecycle controls.

The second mistake is treating Purview as one product. Build clear boundaries between classification, sensitivity labels, DLP, retention, insider risk, communication compliance, compliance posture, activity evidence, AI posture, and eDiscovery. If you cannot explain what signal or action distinguishes two tools, you are not ready for a scenario that places both in the options.

The third mistake is assuming Copilot expands permissions. It respects existing identity-based access boundaries, which means permission hygiene is fundamental. The practical risk is that AI can make already-accessible information easier to discover and synthesize. Study oversharing as an authorization and governance problem, then layer AI-specific controls on top.

The fourth mistake is memorizing admin-center names without understanding object ownership. A question rarely becomes easier because you remember a navigation breadcrumb. It becomes easier when you know that a requirement concerns a mailbox, a SharePoint site, a Teams policy, an Entra identity control, a Purview governance control, a Copilot entitlement, or an agent lifecycle action.

The fifth mistake is freezing the study plan too early. Microsoft has already announced an English-content update for October 14, 2026. If your appointment crosses that date, refresh the study guide and compare objective changes. A current exam guide is a versioned operational document, not a timeless syllabus.

Readiness signals that matter more than a practice score alone

You are approaching readiness when you can explain the three domain weights and reconstruct the main subdomains without looking them up, but recall is only the first layer. You should be able to take a short scenario, identify the object being managed, distinguish authentication from authorization, state why a Purview control fits a specific data risk, explain how Microsoft Graph and existing permissions constrain Copilot, and trace an agent from access through approval to monitoring.

Your troubleshooting answers should also be ordered. If a user cannot access a Copilot-grounded document, you should know whether to inspect identity, entitlement, direct data permission, conditional access, service configuration, or AI-layer controls first based on the evidence. If a DLP alert appears, you should know why that is different from a retention event or an insider-risk signal. If an agent works for one user but not another, you should check agent access and source permissions before granting broad tenant privileges.

Finally, make your last checkpoint version-aware. Record “skills measured as of July 22, 2026” and the announced October 14, 2026 English update in your study notes. On the day you freeze your plan, open the live Microsoft study guide again. Certification content changes faster than static study notes, and AB-900 is specifically about technologies whose administrative capabilities are evolving quickly.

Where AB-900 fits after you pass

AB-900 is most useful as a foundation for administrators who need to understand how Microsoft 365 operations change when Copilot and agents become part of the environment. Passing the exam should not be the end of the learning path. The next step is to deepen whichever operational area your role owns: Microsoft 365 administration, identity and access, security operations, Purview governance, SharePoint information architecture, or Copilot and agent lifecycle management.

Choose the next skill by responsibility rather than by badge sequence. If you own identity, go deeper into authentication, conditional access, least privilege, PIM, application access, and sign-in investigation. If you own data governance, deepen labeling, DLP, retention, eDiscovery, insider risk, and oversharing remediation. If you own Copilot operations, deepen readiness, feature configuration, licensing, adoption analytics, agent governance, and production monitoring. The value of AB-900 is the shared map that helps those specialties communicate.