AB-900 is a fundamentals exam, but hands-on practice still matters because many objectives describe real administrative objects and decisions. The most useful lab work does not try to turn the candidate into an expert Microsoft 365 engineer. It gives enough direct exposure to recognize the difference between a user, group, license, policy, label, site permission, Copilot setting, and agent lifecycle action when the AB-900 exam presents them in a scenario.
A small Microsoft 365 developer or trial environment is ideal when available, but even candidates with read-only enterprise access can learn by observing approved admin interfaces, documentation, screenshots, and controlled demonstrations. The key is to practice the relationships the exam measures, not to make risky changes in a production tenant.
The following exercises are intentionally bounded. Each one should end with an explanation of what changed, which administrative layer was involved, and what downstream effect the change would have on Copilot or agent access.
Exercise 1: trace one user from identity to licensed services
Choose a test user and trace the user through the Microsoft 365 administration model. Identify the account, group memberships, assigned licenses, and the services enabled by those licenses. Then identify where authentication methods, Conditional Access evaluation, and sign-in information would be reviewed. The objective is to see one identity move through multiple control layers.
Use the Microsoft 365 admin center for the tenant-level view and Microsoft Entra for identity-specific details. Do not change policies merely to create activity. The useful practice is being able to answer: where would I look, what object am I inspecting, and what kind of problem would this evidence help diagnose?
Finish by describing what would happen if the user had a Copilot license but lacked permission to a SharePoint site. That simple thought experiment connects licensing with authorization and prepares you for later Copilot scenarios.
Exercise 2: compare authentication, authorization, and Conditional Access
Create three written scenarios rather than three configuration changes. In the first, the user fails MFA. In the second, the user signs in successfully but lacks access to a resource. In the third, the user is blocked because a Conditional Access policy requires a condition the session does not meet. For each case, identify where you would investigate and what kind of evidence you would expect.
Review Conditional Access alongside basic authentication and authorization concepts until the boundaries are clear. This is one of the most valuable foundational exercises because AI-enabled administration still depends on ordinary identity logic.
Add PIM as a fourth case: an administrator needs elevated permissions temporarily. The correct concept is privileged-role activation, not a permanent license change or a new authentication method.
Exercise 3: audit a SharePoint site for oversharing risk
Use a test or approved site and review who can access it, how sharing is configured, and whether the audience is broader than the business purpose requires. If you cannot use a real environment, work from a documented sample and draw the permission chain from user or group to site, library, folder, and file.
The purpose is to make SharePoint sharing tangible before adding Copilot. Ask whether an AI assistant using the same permitted context would make sensitive information easier to discover. If the answer is yes, the correct fix starts with the access model, not with blaming the AI experience.
Document the evidence you would want before changing access: site ownership, group membership, sharing links, inherited permissions, and data-access governance findings where available. That creates a repeatable administrative reasoning process.
Exercise 4: classify a small set of documents by governance need
Take five fictional documents: a public brochure, an internal project plan, a customer contract, a payroll file, and a legal-hold record. For each, decide whether the primary concern is classification, access, retention, loss prevention, investigation, or several of those together. Then map the need to Microsoft Purview capabilities.
Use information protection concepts to distinguish sensitivity labels from retention and data loss prevention from simple access control. The goal is not to build production policies. It is to stop treating every governance requirement as if it had the same answer.
Add one Copilot question for each document: if the user is authorized to access it, what governance controls still matter? That reinforces the idea that Copilot respects existing permissions but does not eliminate the need for classification, lifecycle, and policy enforcement.
Exercise 5: inspect the Copilot administration lifecycle
Walk through the administrative lifecycle conceptually: assign a license, confirm the user can access Copilot, review which features are enabled, identify where usage and adoption are monitored, and understand how prompt artifacts are managed when the applicable blueprint version includes those tasks.
Do not reduce the exercise to clicking through menus. Write down the business question each view answers. Licensing asks who is entitled to use the service. Feature controls ask what is available. Usage analytics asks whether the service is adopted. Billing policy asks how consumption is funded. Prompt management asks how reusable prompt assets are governed.
The exam can then present any of those questions without requiring you to memorize a screenshot. You will know the administrative intent behind the interface.
Exercise 6: compare a built-in Copilot capability with a custom agent
Choose a business task such as summarizing a project, researching an internal topic, or guiding an employee through a process. Decide whether the requirement is satisfied by built-in Copilot capability or whether a custom agent is justified. Then identify the governance questions that appear once an agent is introduced: who can use it, how it is approved, what data or actions it reaches, and how its lifecycle is monitored.
Keep the depth aligned with AB-900. The deeper engineering work belongs to AB-620. Here, the objective is to recognize administrative ownership and the difference between providing access to a standard Copilot feature and governing a separately created agent.
This exercise is valuable because it connects product selection with governance. Not every business request needs a custom agent, and creating one introduces operational responsibility.
Exercise 7: build a sign-in and activity evidence checklist
Create a one-page diagnostic checklist containing sign-in logs, risky sign-ins, audit logs, Identity Secure Score, Defender signals, Purview alerts, activity explorer, compliance findings, and SharePoint access reports. For each source, write the specific kind of question it answers.
This prevents a common beginner mistake: opening whichever security portal is most familiar regardless of the problem. The Microsoft 365 Defender layer helps with threat-oriented evidence, while Purview and SharePoint provide different governance and access perspectives.
Then practice with short cases. Suspicious sign-in? Start with identity evidence. Sensitive content shared externally? Look at access and DLP evidence. A user reports Copilot surfaced an unexpected document? Verify the underlying permission path before searching for an AI-specific failure.
Exercise 8: rehearse an agent access and monitoring decision
Write a simple fictional agent that answers HR policy questions. Define the intended audience, the data it should use, who should approve it, how users receive access, and where administrators would review adoption or lifecycle information. Do not add advanced orchestration. The administrative questions are enough.
If your organization uses Power Platform, observe how the Microsoft 365 and Power Platform administration surfaces divide responsibility. If that environment is unfamiliar, background from PL-900 can help you understand the platform vocabulary without changing the focus of AB-900.
End by identifying one reason the agent should be restricted or retired. That forces you to think about lifecycle rather than only creation.
Hands-on preparation should produce explanations, not screenshots
A screenshot proves that you found a menu once. An explanation proves that you understand the administrative model. After every exercise, write two or three sentences explaining the object, control, evidence, and expected outcome. Those notes are far more useful for final review than a folder full of interface captures.
The best AB-900 lab work is small, safe, and connected. It shows how identity determines access, how content permissions affect Copilot, how Purview governs data, and how administrators control licenses, features, prompts, and agents. That practical context turns a broad fundamentals blueprint into a set of recognizable decisions.
Add one end-to-end exercise that crosses every domain
Once the individual exercises are comfortable, run one end-to-end scenario. Create a fictional department with a small user group, a SharePoint site containing a mixture of ordinary and sensitive documents, a Copilot-enabled user, and a simple departmental agent. Define the intended access model first. Then identify the licenses, group membership, site permissions, sensitivity or DLP concerns, and the agent audience. The value is not in reproducing a full enterprise tenant; it is in seeing how one business requirement touches every major AB-900 layer.
Next, introduce a controlled failure. Remove the user from the group that grants site access, or imagine a Conditional Access rule blocking the sign-in, or mark one document as sensitive and describe how DLP should respond to prohibited sharing. Then state which evidence would reveal the problem and which administrative change would correct it. This turns configuration knowledge into diagnosis and prevents the common habit of treating every symptom as a Copilot problem.
Finish the exercise by reviewing what an administrator would monitor after rollout: whether the user can access the service, whether Copilot is being adopted, whether data-governance alerts appear, whether the agent is being used by the intended audience, and whether the solution still matches policy. That final monitoring step converts the lab from a one-time setup activity into an operational lifecycle, which is much closer to the way the blueprint frames AI administration.