Microsoft 365 service fundamentals for Microsoft AB-900 Microsoft 365 Copilot and Agent Administration Fundamentals: Concepts, Scenarios, and Study Priorities

 

Use the live AB-900 scope as the boundary for “service fundamentals”

Microsoft 365 is a very large platform, so “service fundamentals” can become an unproductive study category unless you define the boundary first. For AB-900, the current English study guide measured as of July 22, 2026 makes that boundary unusually clear. The first skill area—identify the core features and objects of Microsoft 365 services—accounts for 30 to 35 percent of the exam. It expects you to reason about licensing, tenant settings, Exchange objects, SharePoint objects and permissions, Teams objects and policies, core security principles, Microsoft Entra ID, Conditional Access, single sign-on, sign-in troubleshooting, audit evidence, Privileged Identity Management, and application identity. That is broad, but it is not the same as becoming an expert in every Microsoft 365 workload.

The practical goal is to build an administrative map: what object is involved, which control plane owns it, what prerequisite makes the action possible, what permission or policy can still block it, and what evidence proves the result. Those five questions are more valuable than memorizing menu paths. Microsoft also states that the English AB-900 certification content will be updated on October 14, 2026. If your exam date is on or after that date, treat the live study guide as the final authority and compare it with the July 22 list before final review.

Because service fundamentals are only one slice of AB-900, keep them connected to the broader exam architecture described in the AB-900 complete guide; the important connection is that service objects and identity decisions become the permission boundary that Copilot, agents, and governance controls inherit later in the exam.

Start with the object, not with the admin center

A common beginner mistake is to memorize product portals first: Microsoft 365 admin center, Exchange admin center, SharePoint admin center, Teams admin center, Microsoft Entra admin center, Microsoft Purview, and Power Platform admin center. That approach fails as soon as a scenario names a business requirement rather than a portal. If a department needs a shared email address, the object is likely mailbox-oriented. If it needs a collaboration space with files and channels, the design crosses Teams and SharePoint. If the requirement concerns who may sign in under specific conditions, the control belongs to identity and Conditional Access rather than to the workload where the user happens to notice the problem.

Train yourself to translate every request into an object and a scope. “A user cannot access Copilot” is not yet a diagnosis. Is the user licensed? Is the service plan enabled? Can the user authenticate? Does a Conditional Access policy interrupt sign-in? Is the user allowed to access the underlying content? Is a tenant-wide Copilot feature disabled? The same visible symptom can be produced by entitlement, identity, policy, resource permission, or workload configuration. AB-900 rewards the ability to separate those layers.

A good notebook exercise is to create three columns for every object you study: object, owning administrative surface, and one evidence source. A mailbox maps naturally to Exchange administration and can be validated through recipient configuration and mail flow. A SharePoint site maps to SharePoint administration and can be validated through site properties, membership, and access checks. A user or group maps to Microsoft Entra and Microsoft 365 identity administration, with sign-in and audit evidence available when access fails. This makes portal names meaningful instead of arbitrary.

Licensing is entitlement, not permission

The current objective list explicitly asks you to explain how license types assigned to users and groups affect access to Microsoft 365 features. The safest mental model is that licensing answers “is this capability entitled for this identity?” It does not automatically answer “may this identity open this site, file, mailbox, team, or application?” A user can have a valid Microsoft 365 license and still lack permission to a restricted SharePoint site. A user can be a member of a resource and still lack a particular premium service because the required service plan is not enabled.

Group-based assignment adds another layer. A group can be used to deliver licenses at scale, but the same group might also be used for application assignment, policy targeting, or authorization to resources. Those are independent mechanisms even when the group name is the same. When troubleshooting, establish how the group is being used before assuming membership explains the outcome. A licensing group can grant entitlement while a different security group controls resource access.

In scenario questions, look for wording that separates feature availability from resource permission. “The Copilot button is missing” is different from “Copilot is available but cannot summarize a file.” The first may point to licensing or feature control; the second can point to file permission, sensitivity, data policy, or availability of the source. If the scenario says sign-in succeeds, do not automatically choose an authentication fix. Licensing and authorization are separate decision points.

Tenant configuration is broader than a single workload

The Microsoft 365 admin center is the tenant-level starting point for many organizational settings. AB-900 names domain names and organization settings because candidates should recognize when a requirement applies to the organization rather than to one workload object. A custom domain, for example, establishes an identity and naming context that many services can use. It is not a SharePoint-site setting just because users notice the domain while opening a SharePoint URL, and it is not an Exchange-only decision just because email addresses use it.

Scope discipline prevents overconfiguration. Suppose a company acquires another business and wants users to receive addresses in a new verified domain. That is an organizational identity and domain task before it becomes a mailbox-addressing task. By contrast, if one shared mailbox needs a new alias, the object is workload-specific. Ask whether the requirement changes the tenant, a group of identities, a workload policy, or an individual resource. The narrower correct scope is usually safer and easier to validate.

The same reasoning applies to organization-wide defaults. A global setting can have side effects across many users or workloads, so you should not choose it when the problem is localized. In practical administration, broad settings deserve change control and impact analysis. In exam scenarios, broad-versus-local scope is often the hidden clue that distinguishes two otherwise plausible answers.

Exchange fundamentals: separate storage, identity, and distribution

For AB-900, Exchange knowledge is intentionally object-focused. A mailbox stores and receives messages for a user, shared function, or resource. A distribution group primarily distributes messages to members. Those objects can look similar to end users because both may have email addresses, but their operational purpose differs. When a scenario needs shared access to stored mail, calendar behavior, or delegated mailbox use, a mailbox-oriented object is the natural starting point. When the need is simply to deliver one message to many recipients, a distribution object is more appropriate.

This distinction matters because choosing the wrong object creates downstream complexity. A team that needs a common inbox should not be forced to reconstruct mailbox behavior from a distribution list. Conversely, a notification list does not need a shared mailbox simply because several people receive the same messages. The fundamentals-level skill is not memorizing every Exchange recipient type; it is selecting the object whose state and lifecycle match the business requirement.

For troubleshooting, separate mail identity from mail flow. If a recipient object exists but mail is not delivered, the next evidence may involve address configuration, group membership, delivery restrictions, or mail-flow behavior. If the object itself is wrong, no amount of transport troubleshooting fixes the design. Start with “what is this recipient supposed to be?” before investigating how a message traverses the service.

SharePoint fundamentals: sites, libraries, folders, and effective access

SharePoint is central to AB-900 because it is both a collaboration platform and an important data boundary for Copilot. The service model starts with sites that contain content, libraries that organize documents, folders that provide additional structure, and permissions that determine who can reach the content. Teams-backed collaboration also commonly relies on SharePoint for file storage, so a candidate who treats Teams and SharePoint as unrelated products will struggle with integrated scenarios.

The study guide asks you to identify appropriate roles and permissions for SharePoint sites. At fundamentals depth, you should be able to reason about owners, members, visitors, sharing, and restricted access without assuming that a license equals permission. A user may be fully licensed and authenticated yet receive access denied because the site permission model excludes them. Another user may have broader access than intended because membership, sharing, or inherited permissions are too permissive.

This becomes more important in an AI-enabled tenant. Copilot can make information that a user already has permission to access easier to find and synthesize. That does not mean Copilot invents new permissions; it means weak permission hygiene can become more visible and consequential. When a scenario describes “Copilot exposed a document to someone,” first ask whether the person already had access to that document. The corrective action may be SharePoint access governance rather than a Copilot feature switch.

Teams fundamentals: structure and policy solve different problems

Microsoft Teams introduces another object hierarchy: teams, channels, memberships, and policies. A team creates a collaboration boundary for a set of users. Channels organize work inside that boundary, with channel type affecting access and collaboration behavior. Policies control how capabilities are made available or restricted. The exam-level distinction is that structure answers “where and with whom does collaboration occur?” while policy answers “what behavior is permitted for targeted users?”

A scenario asking to prevent a capability for a class of users is usually policy-oriented. A scenario asking to create a private collaboration space for a project is object- and membership-oriented. Changing team membership will not fix a tenant policy that blocks a feature, and changing a policy will not automatically add someone to the correct collaboration space. Again, object first, scope second, control third.

Teams also illustrates cross-service dependency. Files shared in standard Teams contexts may reside in SharePoint, user identity comes from Microsoft Entra ID, and policy is administered through Teams controls. If file access works for one channel member but not another, do not stop at the Teams client. Trace identity, group membership, underlying content location, and effective permissions. Fundamentals become operational when you can follow that chain.

Users and groups are reusable security objects with different jobs

Users represent identities. Groups aggregate identities so that licensing, resource access, application assignment, or policy targeting can be managed at scale. The mistake is assuming every group has the same security meaning. A Microsoft 365 group supports collaboration scenarios; security groups are often used for access and targeting; distribution groups are messaging-oriented. The specific type and the system consuming it determine what membership actually does.

When you see a group in a scenario, ask two questions: what kind of group is it, and which service is evaluating its membership? If a Conditional Access policy targets a group, Microsoft Entra evaluates that scope as part of the access decision. If a SharePoint permission grants a group access, SharePoint evaluates the resource authorization. If licensing is group-based, the licensing service determines entitlement. Similar-looking membership can therefore produce effects at different layers.

This is also a troubleshooting strategy. If a user was just added to a group and a feature or resource remains unavailable, verify the correct group, expected propagation, assignment mechanism, and effective state. Do not “fix” the problem by adding the user to multiple unrelated groups. That may hide the root cause and create unnecessary privilege.

Authentication, authorization, and SSO must stay separate in your mental model

Authentication answers whether the service can establish who the user is. Authorization answers what that authenticated identity may do. Single sign-on improves the experience by allowing an authenticated identity to access multiple authorized services without repeatedly entering credentials. SSO does not override authorization. A user can sign in once successfully and still be denied access to a site, app, team, or administrative action.

This distinction is one of the most reusable AB-900 skills. If a user cannot complete MFA or is blocked by a risk-based access decision, the failure occurs before resource authorization. If sign-in succeeds but a SharePoint file returns access denied, the identity was authenticated and the remaining question is permission. If an admin can open the admin center but cannot change a setting, role authorization is the likely boundary.

When practicing, rewrite symptoms into layers. “Cannot sign in” becomes authentication or access policy. “Can sign in but cannot use feature” becomes entitlement, feature control, or authorization. “Can use feature but cannot read specific content” becomes resource permission or data policy. “Can read content but cannot administer it” becomes role authorization. That translation dramatically reduces random troubleshooting.

Conditional Access is a policy decision, not a replacement for permissions

Conditional Access evaluates signals and applies access controls when defined conditions match. A policy can consider identity, application, device, location, risk, and other context, then require controls such as multifactor authentication or impose a block. It is useful because access decisions can respond to context rather than relying only on a password. It does not replace the permissions of the target resource.

A good troubleshooting sequence starts with evidence. Determine whether the sign-in attempt reached Microsoft Entra, whether Conditional Access was evaluated, which policies applied, what requirement failed, and whether identity risk or MFA contributed. If the sign-in is successful and no policy blocks access, move down the chain to entitlement and resource authorization. Avoid changing policies based only on the user’s description of “it won’t let me in.”

For exam scenarios, beware of answers that are security-improving but unrelated to the observed stage. Enabling another MFA method may be sensible in general, but it does not fix a user who is already authenticated and lacks a SharePoint permission. Least-change reasoning is part of good administration: change the control responsible for the failed state, then verify.

Zero Trust is a decision model you can apply across services

AB-900 expects the core Zero Trust principles rather than a full enterprise security architecture. Translate the model into three operational ideas: verify explicitly, use least privilege, and assume breach. Verification means use relevant identity, device, risk, and resource context rather than trusting a network location by default. Least privilege means give identities only the access needed for the task and reduce standing administrative rights. Assume breach means design monitoring and controls as though an attacker could obtain a foothold.

These principles explain why service fundamentals and security fundamentals belong together. A Microsoft 365 user is not simply “inside the company.” Access can still be conditioned on authentication strength, device state, risk, or resource sensitivity. An administrator may use Privileged Identity Management to activate a role only when needed rather than holding permanent privilege. Audit logs and Defender signals help detect activity that deserves investigation.

In a scenario, choose the control that enforces the principle at the right layer. PIM addresses privileged role lifecycle. Conditional Access addresses contextual access decisions. SharePoint permissions address resource authorization. DLP addresses handling of sensitive information. Defender XDR contributes detection and investigation. Calling all of them “security” is not enough; the exam expects purpose-level distinctions.

Identity Secure Score, audit logs, PIM, and Defender XDR produce different kinds of evidence

Closely related security tools become easier when you classify them by output. Identity Secure Score is posture-oriented: it helps identify opportunities to strengthen identity security. Audit logs are evidence-oriented: they show recorded user and administrator activity useful for accountability and investigation. Privileged Identity Management is control-oriented: it helps manage privileged role activation and reduce persistent privilege. Microsoft Defender XDR is threat-oriented: it brings together security signals for detection, investigation, and response.

Suppose an administrator needs to know who changed a tenant configuration. The question is historical evidence, so audit activity matters more than a posture score. Suppose the organization wants fewer permanent privileged administrators. PIM addresses the privilege lifecycle. Suppose analysts need to correlate suspicious activity across security domains. Defender XDR fits the threat-detection and investigation need. Suppose identity posture is weak and leadership wants prioritized improvements. Secure Score becomes relevant.

This “what artifact does the tool produce?” method scales well across Microsoft 365. It prevents the common error of selecting a product because its name sounds security-related. For every feature, memorize less and classify more: prevention, enforcement, posture, evidence, investigation, or lifecycle.

App registrations and enterprise applications are two viewpoints on application identity

Application identity is another place where fundamentals candidates can get lost in terminology. An app registration represents an application’s identity definition in Microsoft Entra, including identifiers, credentials, and declared permissions or API relationships. An enterprise application represents the service principal—the application’s instance in a tenant that can be assigned, consented, and governed for access. The two are related but answer different administrative questions.

If a developer is defining how an application authenticates and what permissions it requests, the app registration viewpoint is relevant. If an administrator needs to control who in the tenant can use the application, review consent, or manage tenant-specific access, the enterprise-application viewpoint is more natural. You do not need deep OAuth engineering for AB-900, but you should avoid treating these objects as synonyms.

A useful lab is to inspect an existing enterprise application and trace which users or groups can access it, then view the underlying registration details where available. Ask what would break if credentials expired, what would change if user assignment were required, and what audit evidence would help investigate a configuration change. This makes the objects operational instead of theoretical.

Scenario 1: onboard a new department without confusing entitlement and access

Imagine a company creates a new legal department. Employees need email, Teams collaboration, a restricted SharePoint site, and selected Microsoft 365 features. Start with identities and group design. Create or synchronize users, decide which groups represent licensing and access boundaries, assign the needed service entitlements, and verify account state. Then configure workload resources: mailboxes where required, a team and channels for collaboration, and the associated SharePoint site and libraries with appropriate membership.

Next add the security layer. Confirm authentication methods, Conditional Access requirements, and role assignments for the few users who administer the environment. Do not grant broad administrative roles merely to make onboarding easier. Test from an ordinary user account: sign in, open the expected apps, receive mail, enter the team, and access only the intended site content. If a step fails, diagnose at the layer where state diverged.

Finally, document the expected evidence. A license assignment proves entitlement, successful sign-in proves authentication, group or site membership helps explain authorization, and audit data records administrative changes. This one scenario exercises much of Domain 1 without requiring expert-level configuration.

Scenario 2: the user can sign in but a Microsoft 365 feature is missing

A user reports that Microsoft 365 opens normally but a required feature is unavailable. The worst first step is to reset the password, because successful sign-in already tells you authentication is working. Check entitlement and service plan state, then verify whether the feature is enabled for that user or group. If the feature is present for colleagues with the same license, compare group membership, policy targeting, and tenant configuration rather than changing credentials.

If the feature opens but data is unavailable, move from entitlement to authorization. For a SharePoint-backed experience, confirm site and library access. For Teams, confirm membership and policy. For an application, inspect assignment and enterprise-application access. If a Conditional Access policy had blocked the session, sign-in evidence would normally reveal that earlier in the chain. The sequence is authentication → policy → entitlement → workload configuration → resource authorization.

This sequencing is exam-friendly because distractors often come from adjacent layers. Each option may be a real Microsoft 365 control, but only one explains the stated evidence. Write the observed successful states before selecting an answer. A successful state rules out entire categories of intervention.

Scenario 3: Teams works, but a file does not

A user can open a team and participate in conversation but receives access denied on a specific document. The fact that Teams itself works proves several things: the user can authenticate, reach the service, and has at least some collaboration authorization. Do not conclude that every underlying SharePoint item must therefore be accessible. File permissions, sharing settings, sensitivity, or site/library configuration can create a narrower boundary.

Trace the content location. Determine whether the file is in the expected SharePoint site and library, whether membership should grant access, and whether permissions were broken or sharing changed. Check effective access before adding the user directly. A direct permission might make the symptom disappear while leaving a broken group or site design unresolved.

This scenario is especially useful for Copilot readiness. If Copilot cannot use a document that the user cannot open manually, fixing the Copilot license will not solve the data boundary. Conversely, if the user can open the document but Copilot behavior differs, then move to the AI, governance, or feature-control layer. Always prove the underlying service access first.

Build a small lab around state changes, not screenshots

Hands-on work is most useful when it produces observable before-and-after state. Create a test user and a test group. Record which license is assigned, what the user can access, and which groups control which outcomes. Change one thing at a time: add a service entitlement, grant site membership, target a policy, or remove a permission. After each change, predict the result before testing it. Prediction is what converts clicking into learning.

Use at least three administrative surfaces in one exercise. For example, configure a user in Microsoft 365/Entra, validate a SharePoint site permission, and inspect a Teams policy. Then write an incident note describing what each portal owns. If you cannot explain why you moved to a different control plane, you are navigating by memory rather than by architecture.

When access fails, collect evidence before making another change. Capture the user state, license state, group membership, sign-in result, policy result, workload membership, and relevant audit activity. You do not need a production-scale lab. A minimal tenant or carefully studied screenshots and documentation can work if you still force yourself to predict cause and effect.

Use the objective list to decide what to study deeply and what to stop

The first domain can tempt you into Exchange transport rules, SharePoint architecture, Teams voice, advanced Defender hunting, or identity protocol internals. Those topics are valuable in role-based certifications but can consume disproportionate time here. Stop when you can identify the right object, explain the core security principle, choose the right administrative surface, trace an access failure, and explain what evidence validates the choice.

For an objective-by-object map, use the AB-900 objectives breakdown to check that every published bullet has a concrete decision rule in your notes. Then return to scenarios rather than continuing to collect definitions. For each objective, create one “works as designed” case and one failure case. If you can explain both without notes, the concept is likely stable enough for fundamentals depth.

Allocate extra time to distinctions that recur across the exam: license versus permission, user versus group, mailbox versus distribution, team/channel versus policy, site/library versus sharing, authentication versus authorization, Conditional Access versus resource permission, posture versus audit evidence, PIM versus permanent role assignment, and app registration versus enterprise application. Those pairs create realistic distractors.

A repeatable decision method for AB-900 service scenarios

When a scenario appears, first identify the desired outcome in one sentence. Second, name the object whose state must change. Third, decide whether the scope is tenant, identity/group, workload, application, or resource. Fourth, locate the owning control plane. Fifth, identify prerequisites such as licensing or role authorization. Sixth, use the evidence already provided to eliminate controls that operate earlier or later in the chain.

For troubleshooting, write the last known-good layer. If authentication succeeds, do not return to password troubleshooting unless the scenario provides new authentication evidence. If the license is confirmed and the feature opens, move to configuration or resource access. If the user can open the resource manually, move to the feature-specific or governance layer. This makes long scenarios smaller.

Finish by asking whether the proposed change is the narrowest control that solves the requirement. Fundamentals exams often include answers that would technically produce the result by granting excessive access or changing a global setting. Prefer the option that matches scope and preserves least privilege. That is sound administration and usually the better exam choice.

Final study priorities before you move into Copilot and agents

You are ready to move on when you can sketch Microsoft 365 as a set of related control planes rather than a single portal. You should be able to place users and groups in identity, licenses in entitlement, mailboxes and distribution groups in Exchange, sites/libraries/folders in SharePoint, teams/channels/policies in Teams, application identities in Entra, and security evidence in the appropriate identity, audit, or threat tools. You should also be able to explain how these objects interact without claiming that one layer automatically grants another.

Run a closed-note test with ten short requests: new domain, shared inbox, notification list, restricted project site, private collaboration space, feature missing for one user, sign-in blocked by policy, admin role needed temporarily, application should be limited to one group, and “who changed this setting?” For each, name the object, control plane, prerequisite, and verification evidence. Any hesitation becomes a focused review item.

Finally, re-check the live AB-900 study guide close to the exam. Microsoft has announced an English content update for October 14, 2026, so a candidate testing after that date should confirm whether service-object terminology, feature names, or objectives changed. The durable skill is the reasoning model: object, scope, control, prerequisite, and evidence. Product labels can evolve; disciplined administration transfers.