Microsoft MS-102: Microsoft 365 Administration Skills

MS-102 is broad enough that hands-on work is the fastest way to connect tenant management, Entra, Defender XDR, and Purview. Use a test tenant, Microsoft 365 developer/demo environment where available, or Microsoft Learn labs. Because the exam retires November 30, 2026, the practical work should map directly to the current April 28 blueprint rather than expanding into unrelated specialist topics.

Lab one: establish tenant and service-health awareness

Explore organization settings, domains, subscriptions, Service Health, notification configuration, network connectivity insights, software-update controls, usage/adoption reports, and Microsoft 365 Backup settings where licensing permits.

Document which signals are tenant health, user adoption, connectivity, and backup rather than treating every dashboard as “monitoring.”

Lab two: create users, groups, licenses, and administrative scope

Create cloud users and a guest, build a Microsoft 365 Group, shared mailbox, and group-based license assignment. Practice bulk operations with Microsoft Graph PowerShell or Entra PowerShell concepts in a safe environment.

Then assign a narrow administrative role and compare it with Global Administrator. Least privilege should be visible in the lab, not only in theory.

Lab three: practice PIM and administrative units

Where licensing permits, make one role eligible through PIM, activate it, and review approval/time-bound behavior. Create or inspect an administrative unit and understand which administrators can manage which user/group scope.

This lab demonstrates that “administrator” is not a single tenant-wide permission class.

Lab four: build hybrid identity synchronization safely

Use a training lab to run IdFix or inspect synchronization prerequisites, then configure Entra Connect Sync or Cloud Sync where available. Review Connect Health and a synchronization error.

Record the user attribute flow from AD DS to Entra and distinguish synchronization state from sign-in/authentication state.

Lab five: design authentication and Conditional Access

Configure or model SSPR, authentication methods, Password Protection, Identity Protection, and Conditional Access. Use report-only mode or a sandbox before enforcing broad policies.

A Conditional Access lab should include normal user, privileged user, risky sign-in, and emergency-access exceptions so you understand both security benefit and lockout risk.

Lab six: investigate a Defender XDR incident

Use Microsoft-provided demo data or a harmless simulation. Start from an incident, inspect alerts, entities, attack story, Secure Score or exposure context, and use advanced hunting only where it adds evidence.

A Defender XDR exercise should end with a documented response—user action, device action, message remediation, or policy improvement—not just an alert review.

Lab seven: protect email and collaboration

Review Defender for Office 365 threat policies, alert policies, attack simulation, and restricted entities. Use benign simulation content only. Trace how a suspicious message or collaboration link becomes an investigation and remediation action.

Then inspect whether the same user has identity or endpoint signals that change the priority of the event.

Lab eight: onboard and assess an endpoint

Use a test device or training lab to onboard Defender for Endpoint, inspect endpoint settings, and review Vulnerability Management. Choose one recommendation and understand the affected software/device context before changing configuration.

Endpoint posture is stronger when remediation can be verified rather than only marked complete.

Lab nine: build Purview labels and DLP

Create a synthetic sensitive information type, sensitivity label, retention label/policy, and DLP policy in a sandbox where licensing permits. Include one collaboration workload and one endpoint scenario.

A Purview compliance lab should show how classification, retention, and DLP solve different parts of the information lifecycle.

Lab ten: run a cross-workload administration case

Use a fictional employee who receives a phishing message, signs in from risky context, downloads a sensitive file, and attempts to share it externally. Decide which evidence appears in Entra, Defender XDR, Defender for Endpoint/Office/Cloud Apps, and Purview, then sequence the response.

Add a custom-domain tabletop to the first lab. Trace domain verification, DNS records, user principal names, and service dependencies. A custom domain problem can affect identity and mail/collaboration in ways that look like user provisioning errors if DNS is ignored.

Add a Service Health versus local-connectivity comparison. Simulate a user reporting slow Microsoft 365 access and check provider health, network connectivity insights, and local network evidence before changing tenant policy. This develops the habit of isolating provider, tenant, and client/network layers.

Add a group-based licensing failure. Remove a required license quantity or create a conflicting assignment and observe how the failure is reported. Record the troubleshooting sequence so “licensed user cannot access service” becomes a familiar operational case.

Add an administrative-unit exercise with two departments. Scope a delegated administrator to one department and verify that the same admin cannot manage the other. This gives a concrete example of role versus scope.

Add a PIM approval scenario where an administrator must activate a privileged role for a limited task. Review audit/activation evidence afterward. The lesson is that privilege should be temporary, justified, and observable.

Add a synchronization troubleshooting worksheet. Include source object, IdFix result, sync engine status, connector scope, cloud object, and sign-in result. When the object fails at one stage, stop there instead of testing later controls that never receive the identity.

Add an authentication-method registration review. Compare MFA methods and passwordless options available in the sandbox and decide which user populations should use them. Then model a lost-device recovery path so strong authentication remains supportable.

Add an Identity Protection case using vendor-provided risky-user or risky-sign-in examples. Decide whether the Conditional Access response should require MFA, password change, or blocking based on severity and business context.

Add a Secure Score recommendation review but resist applying everything automatically. Choose one recommendation, identify affected users/workloads, test impact in a limited scope, and define validation. Posture tools should drive controlled improvements, not blind configuration changes.

Add an advanced-hunting lab using a harmless event set or Microsoft demonstration data. Start with a precise question and save the query with comments. The goal is to connect query output to an investigative decision rather than demonstrate complex syntax.

Add an attack-simulation training exercise using Microsoft’s safe simulation capability where licensing allows. Track delivered, clicked, and reported behavior, then decide what training improvement follows. Simulation is valuable only when results change the awareness program.

Add a restricted-entity recovery flow. Model a user blocked after suspicious sending behavior, investigate the account/device cause, remediate credentials or malware, and only then restore sending capability. Operational recovery should not bypass the reason the restriction was applied.

Add a Defender for Endpoint vulnerability-remediation exercise. Select one outdated application, identify affected devices, patch or mitigate in a test environment, and verify the recommendation state changes. This shows exposure management as a closed loop.

Add a Cloud App Discovery review with synthetic or demo data. Rank discovered apps by business usage and risk, then choose one for sanctioning, monitoring, or restriction. Avoid treating every unsanctioned application as malicious.

Add a sensitivity-label test where a synthetic document receives encryption or marking behavior, then compare with a retention label. Make sure you can explain which user action or lifecycle event each control influences.

Add an Endpoint DLP tabletop involving USB copy, print, clipboard, or browser upload. Decide which endpoint action should be blocked, warned, audited, or allowed with justification. This is more useful than memorizing every policy condition independently.

Add a cross-tenant or guest-collaboration exercise. Invite an external user to a test group or SharePoint/Teams resource, apply Conditional Access, and review access. Then remove the relationship and confirm lifecycle cleanup. Collaboration security depends on offboarding as well as onboarding.

Finish with a runbook handoff. Document the tenant, key admin roles, identity-sync dependencies, Conditional Access emergency path, Defender response contacts, and Purview escalation process. If another administrator cannot operate the environment from the runbook, the practical preparation is still too dependent on personal memory.

Add a Microsoft 365 Backup design worksheet if hands-on licensing is unavailable. Choose a mailbox, SharePoint site, and OneDrive account, define a recovery event, and record which business requirement backup satisfies. Then compare with retention so the two concepts do not collapse into one “keep data” idea.

Add a network-connectivity-insights exercise by reviewing Microsoft guidance or available tenant data. Identify whether internet egress, DNS, proxy, or local path design could affect Microsoft 365 performance. This is especially useful because collaboration issues are often blamed on the service before the network path is examined.

Add a role-group exercise in Defender or Purview. Give a test administrator only the role required to perform one investigation or compliance task, then confirm another administrative function is unavailable. This makes workload-specific delegation concrete.

Add a service-plan troubleshooting case where a user receives the correct base license but one application remains disabled. Inspect the plan state and group assignment. The exercise teaches that “licensed” is not a single binary condition in Microsoft 365.

Add a Content explorer or Activity explorer review using synthetic labeled content where licensing allows. Trace where sensitive information exists, which labels were applied, and which users interacted with it. Reporting becomes meaningful when it can explain whether policies are actually changing behavior.

Add a final tenant cleanup audit. Remove disposable users, groups, guest access, risky Conditional Access experiments, test labels, and simulation artifacts. Confirm emergency-access paths still work. Safe lab practice includes leaving the tenant in a known and supportable state.

End the practical sequence by having another administrator follow your written steps for one task, such as guest offboarding or DLP investigation. Any point where they need undocumented help reveals a runbook gap that should be corrected before you consider the lab complete.

The MS-102 administrator role is practical because the administrator coordinates across these workloads. A final lab should therefore prove that you can move between control planes without losing the identity, threat, or data story.