MS-102 Microsoft 365 Administrator Study Guide¶

Independent AI-assisted resource — HUMAN REVIEW PENDING. The October 28, 2026 team refresh reconciles the complete guide and detailed objectives with current public exam, product and learning evidence. See the current group report and the sources-and-objectives record. Known source conflicts and unexecuted exercises remain explicit. This is not human review or live product validation. The official blueprint is authoritative.

Study guide at a glance

Start here

Report an issue with MS-102

Blueprint checked2026-10-28

Review stateReview required

Guide-only active reading1 hr 15 min–2 hr

Prerequisites: Functional experience across Microsoft 365 workloads and Microsoft Entra ID plus working knowledge of networking, AD DS, DNS and PowerShell; hands-on tenant, hybrid identity, Defender XDR, Defender for Office 365, Defender for Endpoint, Defender for Cloud Apps, Purview and Conditional Access administration is strongly recommended.

Exam essentialsRead the objective map, key distinctions, and readiness checklist.

Deep understandingWork through every domain, including decisions, failure modes, and related items.

Hands-on labsBegin with Lab 1: Tenant, domain, health, network, update, and recovery baseline, then use the remaining labs to produce evidence you can inspect and explain.

Official objective domains

Deploy and manage a Microsoft 365 tenant25–30%
Implement and manage Microsoft Entra identity and access25–30%
Manage security and threats by using Microsoft Defender XDR30–35%
Manage compliance by using Microsoft Purview10–15%

The active-reading range uses 90–130 words per minute for technical material. Labs, troubleshooting, note-taking, spaced review, and prerequisite gaps add time; it is not a total preparation promise.

Current baseline: Skills measured as of April 28, 2026.
Retirement: The exam and Microsoft 365 Certified: Administrator Expert certification retire November 30, 2026, at 11:59 PM Central Standard Time. They cannot be earned or renewed after that date.
Replacement: Microsoft had not named a direct replacement on the official blueprint, credential page, or retirement page as rechecked October 28, 2026. Do not infer one from a neighboring certification.
Upcoming blueprint change: Retirement is announced; no separate pre-retirement objective revision is announced.
Practice Assessment: A free Microsoft Practice Assessment is available.
Official source: MS-102 study guide

October 28 implementation notes¶

Confirmed — VERIFY CURRENT (October 28, 2026). Shortening selected offboarding items from 90 to seven days requires two approvals from approvers aged at least two days. With exactly two configured approvers, the requestor can count; with three or more, two other approvers must approve. A request expires after 30 days without quorum. This governs faster permanent deletion, not ordinary restore authorization or every Backup action. Undo is possible before purge; purge is irreversible. What's new in Microsoft 365 Backup · Offboarding in Microsoft 365 Backup

Confirmed — VERIFY CURRENT (October 28, 2026). Backup Activity Logs show policy/restore operations, including failures and partial success, and support filtered CSV export. Their retention is a fixed 365 days; read-only operations are omitted. Workload-admin visibility follows role scope. Use these logs for troubleshooting and Microsoft Purview Audit for the compliance audit record; an empty operational view does not prove no one accessed the service. What's new in Microsoft 365 Backup · Privacy, security, and compliance in Microsoft 365 Backup

These dated operational notes supplement the objective treatment in this refresh. Product and tenant exercises were not run. Unresolved support and documentation gaps remain stated at the affected topic.

How to use this guide¶

MS-102 is an integration exam. A Microsoft 365 administrator must understand where tenant, identity, security, endpoint, application, and data controls meet—not merely recognize the admin portals. For every objective, practice this operating chain:

business requirement
  -> tenant, user, device, application, or data object
  -> authoritative administration plane and least-privilege role
  -> policy configuration and license dependency
  -> staged deployment and negative test
  -> alert, audit, health, and usage evidence
  -> rollback, recovery, and owner

Read the four domain sections, work the three integrated scenarios, complete or tabletop all ten labs, and answer the 44 original checks with the answer key. Use a disposable Microsoft 365 developer or test tenant where possible. Some Defender, Purview, Entra ID Governance, Backup, and advanced analytics features require specific licenses; never alter a production tenant simply to reproduce a lab.

This credential also requires one qualifying associate certification: Endpoint Administrator, Teams Administrator, Identity and Access Administrator, or Information Security Administrator. Confirm the current prerequisite choices and completion rules on the Administrator Expert credential page before scheduling. Source discrepancy — October 28, 2026: That credential page lists four options, including Information Security Administrator; the study-guide audience lists only three. Do not silently discard the fourth credential-page option or infer eligibility from a course. Confirm ambiguous qualification with Microsoft Credentials support.

About related items: A Related item: callout adds prerequisite, operational, architectural, or adjacent context that makes the current topic easier to understand. It is useful supporting knowledge, not a claim that the item appears verbatim in the published exam objectives.

The course retirement table lists AB-650T00 as the replacement for MS-102T00 training on November 30. A replacement course does not establish a direct replacement expert credential or waive the associate prerequisite. The credential page's empty training collection also does not invalidate the separately available five-day course and nine direct Learn paths below.

Living-guide watch — September 28, 2026¶

The November 30, 2026 retirement remains the controlling lifecycle fact. Before practicing hybrid identity, check the Entra Connect version history, including the September 30, 2026 minimum-version enforcement boundary. Do not turn a current operational prerequisite into an invented blueprint revision.

Use the recurring Entra, Defender XDR, Purview, and Microsoft 365 Copilot feeds to validate names, portals, previews, and service behavior while the exam remains available. External courses and community explanations can help with troubleshooting mental models, but prioritize the retiring blueprint rather than chasing every newly released feature.

This deep review maps all 54 objectives in 12 groups to learning content. Operational changes below supplement the unchanged April blueprint. One source gap remains: current Backup policies support two-year recovery windows, while the restore-frequency table documents only the first year. Do not promise a second-year recovery-point schedule from that table.

Exam profile and complete objective map¶

Official domain	Weight	Administrative question
Deploy and manage a Microsoft 365 tenant	25–30%	How is the tenant configured, delegated, licensed, monitored, updated, and recoverable?
Implement and manage Microsoft Entra identity and access	25–30%	How are identities synchronized, authenticated, risk-evaluated, and granted secure access?
Manage security and threats by using Microsoft Defender XDR	30–35%	How are exposure, email, endpoints, cloud apps, alerts, incidents, and response operated together?
Manage compliance by using Microsoft Purview	10–15%	How are sensitive information, labels, retention, DLP, evidence, and response governed?

Published objective-to-guide map¶

Published objective area	Primary coverage	Practice evidence
Tenant creation, domains, organization settings, Service Health, network insights, Microsoft 365 Apps updates, usage, and Backup	Section 1	Scenarios 1 and 3; Labs 1 and 4
Users, external users, contacts, groups, shared mailboxes, licensing, and bulk administration	Section 1	All scenarios; Lab 2
Microsoft 365, Entra, Defender, and Purview roles; administrative units; PIM	Section 1	All scenarios; Lab 3
Connect Sync, Cloud Sync, Connect Health, synchronization troubleshooting, and IdFix	Section 2	Scenario 2; Lab 5
Authentication methods, SSPR, Password Protection, and authentication troubleshooting	Section 2	Scenarios 1–2; Lab 6
Identity Protection, Conditional Access, and MFA	Section 2	All scenarios; Lab 6
Exposure Management, Secure Score, XDR incidents/alerts/reports, advanced hunting, and Threat Intelligence	Section 3	All scenarios; Lab 7
Defender for Office 365 policies, alerts, investigations, attack simulations, and restricted entities	Section 3	Scenarios 1 and 3; Lab 7
Defender for Endpoint onboarding, settings, and vulnerability management	Section 3	Scenarios 2–3; Lab 7
Defender for Cloud Apps connection, policies, activity log, Cloud Discovery, and response	Section 3	Scenarios 1 and 3; Lab 7
Sensitive information types, retention, sensitivity labels, explorers, and label reporting	Section 4	All scenarios; Lab 8
Workload and endpoint DLP, alerts, events, and reports	Section 4	All scenarios; Lab 8

1. Deploy and manage a Microsoft 365 tenant¶

Establish the tenant boundary before configuring workloads¶

A tenant is the primary identity and service boundary for Microsoft 365. Record its initial domain, verified custom domains, data residency commitments, subscriptions, service ownership, emergency access accounts, administrative model, naming conventions, and recovery contacts before adding production users. A custom domain is proved through DNS; adding the domain does not migrate mail, change every user's sign-in name, or automatically create the service records required by Exchange, Teams, and device enrollment. Microsoft's domain guidance should be checked before changing production DNS.

Separate four kinds of configuration evidence:

Evidence	Question answered	Typical source
Desired configuration	What should exist?	Approved design, automation, change record
Effective configuration	What does the service currently enforce?	Admin center, Graph, workload PowerShell
Service condition	Is Microsoft reporting a current incident or advisory?	Service Health and message center
User experience	Can a representative client reach and use the service?	Connectivity test, synthetic transaction, support telemetry

Service Health is tenant-specific and should have notification recipients and an incident process. A green service-health view does not prove that DNS, proxy, identity, device, or local network configuration is healthy. Network connectivity insights help locate Microsoft 365 egress and connectivity problems; they are not a substitute for packet-path, DNS, proxy, and client evidence. Start with Microsoft's network connectivity overview, then correlate tenant insights with local telemetry.

Microsoft 365 Apps update management is a policy and rollout problem. Define channel, target groups, deadlines, exclusions, rollback, health signals, and support ownership. A dashboard can report update progress, but it cannot make a device reachable or repair an incompatible add-in. Review the current Microsoft 365 Apps cloud-update guidance because supported controls and channel behavior change.

Usage reports measure service activity; Adoption Score adds organizational insights and recommendations. Neither proves business value or employee performance. Minimize report access, understand privacy settings, and combine aggregated adoption evidence with support, process, and outcome measures. Microsoft's activity reports overview documents available reports and administrative access.

Microsoft 365 Backup is a separately configured recovery capability for supported workloads. Define protected scope, retention, restore permissions, recovery objectives, cost ownership, and test cadence. Native retention, recycle bins, version history, litigation requirements, and backup solve overlapping but different problems. Confirm current workload and restore behavior in the Microsoft 365 Backup overview.

Worked example 1: choose the recovery operation before promising an RPO¶

For a protected SharePoint site damaged two days ago, restore documentation distinguishes full-site recovery points every ten minutes for the most recent 14 days from granular file/folder points that are roughly daily, occasionally only weekly. For days 15–365, the documented SharePoint/OneDrive schedule is weekly; Exchange has ten-minute points through the documented first year. A ten-minute whole-site schedule does not promise a ten-minute individual-file point.

Suppose a recovery drill requires 20 minutes to identify a clean point, 15 for authorization, 30 for restore and 10 for application/user verification: 75 minutes, missing a 60-minute business recovery target by 15. These are synthetic timings, not Microsoft performance commitments. Published median throughput is not a tenant SLA. New protection does not create old backups, and increasing retention cannot recreate already expired points.

Current backup policy controls support 3 months, 6 months, 1 year or 2 years; existing policies default to one year. A shorter window, including moving an item to a shorter-window policy, starts a 30-day grace period before older points are deleted. Changing an active policy is distinct from a paused policy or running job. The older first-year frequency table does not establish the second-year cadence: inspect actual available points and current documentation before committing to that requirement.

Full Workload Backup is preview. It discovers eligible new items every 24 hours; custom policies, including paused ones, take precedence. A paused custom policy therefore must not be assumed to gain full-workload protection. Exclusions apply to full-workload coverage, not custom policies. Static group filters flatten membership once; preview dynamic rules reevaluate daily. Removing a unit stops new protection but preserves existing points for their applicable window. Disabling pay-as-you-go initiates offboarding; it is not merely hiding an invoice. See the Backup change log.

Granular restore is GA, including original-location conflict handling; the overview's older “coming soon” row and April blog's future in-place wording are superseded by the specific restore instructions. In-place granular restores inherit destination-folder permissions. Full-site rollback can discard subsequent edits, and users are not automatically prevented from editing during restoration. Check supported sites, IRM/locked-library limitations, holds and multi-geo behavior before selecting an operation. Append-only backup storage prevents overwrites; it is not an irrevocable deletion lock. Purview retention and backup recovery windows are independent.

Related item: Configuration management matters even when the portal is the primary interface. Export role assignments, domains, policies, licenses, and health configuration on a schedule. Without a dated baseline, an administrator can observe drift but cannot prove when or why it occurred.

Manage identities, collaboration objects, and licenses as lifecycles¶

For a user, distinguish the account object, authentication state, licenses, workload provisioning, group memberships, mailbox or collaboration resources, device relationships, data ownership, and retention obligations. A deletion request can affect each on a different timeline. Build joiner, mover, leaver, guest-expiration, legal-hold, mailbox-conversion, and data-transfer procedures rather than treating account deletion as the whole lifecycle.

Cloud users are mastered in Entra ID; synchronized users are normally mastered in the configured on-premises source for synchronized attributes. External users have a home identity outside the resource tenant and a guest or member representation inside it. Contacts are addressable directory objects without the same identity and sign-in behavior as users. A Microsoft 365 group supplies a membership and collaboration boundary across services; a distribution group primarily distributes messages; a security group grants access; a shared mailbox provides delegated mailbox access. Choose the object from the requirement, not from a familiar admin center.

Licensing is assignment plus successful downstream service provisioning. Direct assignment is simple for exceptions but becomes difficult to govern at scale. Group-based licensing connects entitlement to group membership and can expose assignment errors that must be resolved. Nested group membership does not inherit licenses: only direct user members of the licensed group receive its assignment. Track available units, disabled service plans, conflicting assignments, usage location, group processing errors, and reclaimed licenses. Review group-based licensing before designing automation.

Worked example — bounded Entra PowerShell inventory¶

Compare a bounded Microsoft Entra PowerShell user inventory with the existing Graph inventory by immutable object ID. Verify tenant context, consent, module version, properties, pagination and time window. Get-EntraUser -Top 3 is a sample; -All requests the collection. Neither proves licensing or workload provisioning. Retain partial failures and compare IDs rather than row order/display names.

Connect-Entra -Scopes 'User.Read.All'
Get-EntraUser -Top 3 | Select-Object Id, DisplayName, UserPrincipalName
# -All only when the approved inventory requires every page.

Question: Three rows match Graph; did all 600 bulk changes succeed?

Answer: No. Compare full intended ID set, per-object results and downstream state; a sample does not establish population completion.

Primary reference 1

Worked example 2: membership is not successful provisioning¶

A licensed group contains 50 direct users and a nested group with 20 additional users. Three direct users have assignment errors. If nobody has another assignment, only 47 users have a successful assignment, not 70; the 20 nested-only users do not inherit it, and three direct users still need repair. Record each error and verify the service plans and workload provisioning after repair. Do not confuse a membership count with effective entitlements.

When moving between licensed groups, add the destination membership, wait for and verify successful license application, then remove the old membership. Group processing is asynchronous. Removing the source first can interrupt service.

The memberOf preview ends November 3, 2026. Affected dynamic groups, dynamic administrative units and entitlement auto-assignment rules stop updating and retain their last state. Inventory the rules and downstream licensing/access dependencies; replace with supported attribute rules or assigned membership, then validate membership, delegation and access. This is not removal of all dynamic groups, and stale membership does not mean access was revoked.

Bulk administration should be repeatable, scoped, logged, and idempotent. Prefer the current Microsoft Graph PowerShell SDK for new cross-service automation, request only required scopes, validate a small batch, record per-object results, and handle throttling and partial failures. The Graph PowerShell overview explains its authentication and command model. A successful command is not the same as successful service provisioning; query the resulting object and workload state.

# Illustrative inventory pattern; test command names and permissions in a lab.
Connect-MgGraph -Scopes 'User.Read.All'
Get-MgUser -All -Property Id,DisplayName,UserPrincipalName,AccountEnabled,AssignedLicenses |
  Select-Object Id,DisplayName,UserPrincipalName,AccountEnabled,AssignedLicenses

Do not place secrets in scripts, transcripts, or exported reports. Record tenant ID, Graph context, requested scopes, query timestamp, pagination, failures, and the secure storage location for output.

Related item: Entitlement management and access reviews can govern some access packages and group membership beyond the explicit MS-102 wording. They do not replace the administrator's need to understand the underlying group, role, license, and workload effect.

Delegate control without creating hidden global administrators¶

Microsoft 365 and Entra roles are different role systems. Defender XDR and Purview also have role and role-group models. Map each task to its authoritative plane and the narrowest supported role. Microsoft's Microsoft 365 role overview, Defender XDR unified RBAC guidance, and Purview permissions guidance describe boundaries that can overlap during migration or coexistence. VERIFY CURRENT before changing a production role model.

Administrative units restrict the scope of supported Entra role assignments to selected users, groups, or devices. They do not partition the tenant or scope every Microsoft 365 workload role. Restricted-management administrative units add stronger protections and operational constraints; validate supported objects and recovery access. The administrative-unit documentation is the source for current support.

PIM changes a supported role from permanent standing access to eligible or time-bound activation. Configure maximum duration, justification, approval where appropriate, authentication context or strong authentication, notifications, access reviews, and emergency recovery. PIM does not make an overpowered role least privileged and does not govern every workload role. Review the PIM overview.

Keep at least two tested, cloud-only emergency-access accounts protected and monitored according to Microsoft's current recommendations. Do not use them for routine administration. Exercise recovery without weakening Conditional Access for ordinary administrators.

Related item: A delegated administrator can become effectively global through group ownership, application consent, role-management permission, or the ability to alter synchronization. Review privilege paths, not only direct role membership.

2. Implement and manage Microsoft Entra identity and access¶

Treat synchronization as a data pipeline with authority and recovery¶

Microsoft Entra Connect Sync uses an on-premises synchronization engine and supports a broad set of hybrid identity scenarios. Microsoft Entra Cloud Sync uses lightweight provisioning agents and cloud-managed configuration, with different topology and feature support. Do not choose solely because one is newer. Compare authoritative source, forests and domains, object types, filtering, writeback requirements, custom rules, high availability, network constraints, and migration path against the current Connect Sync and Cloud Sync documentation.

Before synchronization:

Inventory forests, UPN suffixes, accepted domains, duplicate attributes, unsupported characters, proxy addresses, object counts, and service accounts.
Decide source anchor and scoping rules; document which system masters every synchronized attribute.
Run IdFix and resolve findings deliberately rather than blindly accepting changes.
Stage a pilot organizational unit or group and define rollback.
Establish connector, agent, scheduler, export, accidental-delete, and credential monitoring.
Test create, update, disable, rename, move, soft-delete, restore, and source-of-authority behavior.

Use Connect Health synchronization monitoring where supported, but also inspect connector-space, synchronization-service, provisioning, audit, and sign-in evidence. A healthy agent does not prove every object exported correctly. Troubleshoot in sequence: authoritative source object, scope/filter, import, join/metaverse, synchronization rule, export, cloud object, then workload effect. Preserve connector errors and object IDs before retrying.

Related item: Password hash synchronization can provide sign-in resilience even when another authentication approach is primary, but enabling or changing it is a security and architecture decision. Test incident, outage, and rollback procedures instead of assuming the normal sign-in flow will always be available.

Keep sync version, authentication and monitoring failures separate¶

Confirmed — VERIFY CURRENT (October 28, 2026). The current Connect hardening requirements name Connect Sync 2.6.84.0 or later; the earlier 2.5.79.0 minimum is superseded. Connect Health still has the separate 4.5.2466.0 minimum for its Sync, AD DS and AD FS agents. The version history records 2.5.79.0 support ending October 23, 2026. Absence of Health alerts does not establish successful synchronization.

Related item: Next authentication deadline. Microsoft now requires both 2.6.84.0+ and application-based authentication by April 7, 2027; unmet requirements can stop synchronization. Inventory installed build and actual authentication configuration separately. A current binary alone does not prove migration from the legacy account model.

Proposed practice extension — not executed: Add two synthetic servers: supported version with legacy authentication, and retired 2.5.79 with a functioning Health agent. Explain each independent failure boundary and evidence required to repair it; do not upgrade or change tenant authentication for this research.

Answer checkpoint: Does upgrading to a supported binary alone satisfy the April 2027 requirement? No; application-based authentication is separately required.

The minimum is not the preferred current release. On September 28, version history lists 2.6.92.0, released September 23, fixing a 2.6.91.0 PTA-agent registration failure. It also lists 2.5.79.0 support ending October 23. Use the Entra admin-center download and validate OS/.NET/TLS, topology, backup/export, staging and rollback; auto-upgrade does not always deliver the newest release. Inspect app-scoped Conditional Access after 2.6.91's Graph permission changes. A migration wizard does not prove Cloud Sync meets every existing topology requirement.

Application-based authentication uses an application and certificate for sync. New installations configure it; existing legacy-account servers are not silently converted by background synchronization. Confirm actual configuration rather than inferring it from the installed version. In managed mode, Connect owns certificate rotation, and a suspended scheduler prevents it. BYOC makes the administrator responsible for certificate lifecycle; BYOA additionally makes them responsible for the app and permissions. Inventory app ID, certificate expiry, private-key protection, rotation state and scheduler. Do not solve application authentication failures by weakening unrelated user MFA policies.

Build authentication as registration, policy, recovery, and evidence¶

Authentication methods policy determines which methods groups may register and use. Prefer phishing-resistant methods for privileged and high-risk access where supported, then design bootstrap and recovery. Temporary Access Pass can help bootstrap passwordless registration; SSPR provides user-driven recovery only when registration, licensing, writeback, policy, and verification dependencies are satisfied. Review the current authentication-methods policy and SSPR behavior.

The current SMS/voice transition separates passkey availability, registration and system-preferred MFA from Conditional Access enforcement. Microsoft-provided SMS/voice delivery is scheduled to end February 1, 2027 for most covered users, with Global Administrators and external users moving to July 1. Internal guest users remain in the February cohort. Provider alternatives have their own preview/support requirements. Keep this as post-exam operational planning and verify tenant notices; a preferred method is not proof every sign-in used it.

Microsoft Entra Password Protection applies global and custom banned-password logic in the cloud and can extend protection to on-premises AD DS through proxy and DC agents. It is not a substitute for phishing-resistant authentication. Verify deployment, audit/enforce mode, agent health, proxy redundancy, and event logs using the on-premises Password Protection guidance.

For an authentication failure, capture correlation ID, timestamp, user, resource, client, device, network, authentication requirement, method attempted, Conditional Access result, risk, and error code. Then distinguish:

authentication-method registration or availability;
password, lockout, or source synchronization;
token, session, or client behavior;
Conditional Access grant/session control;
device compliance or join state;
workload authorization after successful sign-in.

Resetting a password or excluding a user from policy without identifying the failed control can turn a support case into a security gap.

Related item: Authentication strength describes allowed combinations for a Conditional Access grant. It is more precise than merely requiring “MFA,” because not every MFA combination offers the same phishing resistance.

Convert identity risk into controlled access decisions¶

Identity Protection detects supported user and sign-in risks and supports investigation, confirmation, dismissal, and policy-driven remediation. Risk detections are evidence signals, not proof of compromise. Validate the user, sign-in context, device, IP, correlated incidents, and remediation status in the Identity Protection overview.

Conditional Access evaluates identity, target resource, conditions, and access controls after primary authentication. Design a small composable policy set rather than one giant rule. Include explicit coverage for administrators, users, workload identities where supported, legacy authentication, device/platform, location, risk, authentication strength, sign-in frequency, and emergency access exclusions. Start in report-only mode, analyze results, pilot, enforce, and retain rollback. The Conditional Access overview and session-controls reference explain the current evaluation model.

Worked example 3: compare Conditional Access with email policy precedence¶

For a matching Conditional Access policy, assume the selected grant is compliant device OR app protection. A second matching policy requires MFA. A sign-in with app protection but no compliant device satisfies the first policy; without MFA it still fails the second. All applicable policies must be satisfied; an applicable block prevents access. An OR inside one policy does not combine all policies into a global OR. Use grant controls, report-only results, What If and actual sign-in logs; successful authentication still does not grant a workload role.

For new mobile application access policies, use app-protection requirements where supported. The approved-client-app migration note says that from June 30 legacy policies are read-only: existing enabled policies continue enforcing and can be disabled/deleted, but cannot be newly created or edited. Test the replacement with supported clients before removing old protection.

Do not confuse these controls:

Control	Primary purpose	It does not replace
Authentication method policy	Allow method registration/use	Conditional Access targeting
Conditional Access	Contextual access decision	Workload authorization
Identity Protection	Detect and remediate identity risk	Incident investigation
PIM	Time-bound privileged-role activation	Least-privilege role design
Device compliance	Report device state	Endpoint detection and response

Related item: Token theft and session persistence mean that successful MFA is not the end of identity defense. Correlate token/session behavior, continuous access evaluation where supported, Defender signals, and revocation during response.

3. Manage security and threats with Microsoft Defender XDR¶

Operate from exposure to incident and verified remediation¶

Microsoft Security Exposure Management connects assets, initiatives, attack paths, recommendations, and exposure insights. Microsoft Secure Score measures improvement actions within its supported control model. Neither is a universal risk score or proof of compliance. Use asset criticality, exploitability, exposure, threat evidence, control ownership, business impact, and remediation cost to prioritize. Review attack paths and Microsoft Secure Score against current licensing and feature availability.

In Defender XDR, an alert represents a suspicious signal; an incident groups related alerts and entities into an investigation. Begin with scope and timeline, then examine affected users, devices, mailboxes, applications, cloud activities, evidence, and automated actions. Preserve evidence before containment when safe. Use advanced hunting to test hypotheses across available tables, not to search blindly. Validate query time range, schema, ingestion, joins, and null behavior. Microsoft maintains current product guidance in the Defender XDR documentation.

Threat Intelligence provides actor, campaign, indicator, and vulnerability context. An indicator match is not automatically malicious in the local environment, and absence of a match is not proof of safety. Record source, confidence, validity period, affected assets, action, exception, and review date.

Related item: Incident closure should include root cause, affected scope, containment, eradication, recovery, control improvement, and evidence retention. Changing status to resolved without validating recovery hides repeat exposure.

Protect email and collaboration with layered policy¶

Exchange Online Protection provides baseline mail filtering; Defender for Office 365 adds supported Safe Links, Safe Attachments, investigation, simulation, and response capabilities by plan. Use preset Standard or Strict security policies as a known baseline where they fit, then document narrowly scoped exceptions. Review Microsoft's recommended EOP and Defender for Office 365 settings.

Understand the order and boundary of connection, anti-malware, anti-spam, anti-phishing, impersonation, Safe Attachments, Safe Links, quarantine, tenant allow/block, and mail-flow controls. An allow entry can bypass part of the protection chain and should have owner, scope, reason, expiry, monitoring, and revalidation. Advanced delivery is for controlled simulations and supported security operations—not a general allowlist.

Investigate email threats through message trace, Explorer or real-time detections where licensed, campaign and entity evidence, URL/file detonation, user submissions, and incident correlation. Remediation may include soft/hard delete, quarantine, block, account/session action, device investigation, and hunting for similar messages. Test the authorized path and the prohibited path after policy changes.

Attack Simulation Training should use approved payloads, audiences, privacy controls, safe landing pages, training assignments, and success measures. It is a behavior-improvement exercise, not a covert employee test. Start with the attack-simulation guidance. Restricted entities protect the service after suspicious outbound behavior; investigate and remediate the cause before following the blocked-user recovery process.

Related item: SPF, DKIM, and DMARC establish domain-level sending and authentication signals. They strengthen anti-phishing decisions but do not inspect a safe-looking message body, attachment, OAuth grant, or compromised legitimate sender.

Connect endpoint and cloud-app evidence to XDR¶

Defender for Endpoint onboarding establishes sensor and service connectivity; it does not automatically apply every prevention policy or guarantee that all devices are healthy. Choose an onboarding method, define supported operating systems, configure endpoint settings and integrations, pilot device groups, validate sensor health, and confirm tamper protection and EDR evidence. Use the current Defender for Endpoint onboarding guidance.

Vulnerability Management inventories supported software, weaknesses, recommendations, exposure, and remediation status. Prioritize using exploit availability, exposure, asset value, active alerts, compensating controls, and operational impact. A recommendation closed in the portal is not enough; prove the target version/configuration and watch for reappearance. Review Defender Vulnerability Management.

Defender for Cloud Apps connects supported services and ingests activity for investigation and policy. The Microsoft 365 connector enables supported visibility; verify included applications, audit prerequisites, data delay, and role permissions in the connection guidance. Policies can detect activity, anomalies, risky OAuth apps, files, and sessions according to type and licensing. Tune against known business behavior without broad exclusions.

Cloud Discovery analyzes supported network logs to identify sanctioned and unsanctioned cloud use and apply risk context. It does not prove that every discovered app contains company data or that blocking an app is safe. Validate owner, users, data, authentication, contract, integrations, and replacement path using discovered-app guidance.

Related item: Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps, and Entra signals become more useful when entity identifiers and timestamps correlate. Integration amplifies evidence; it does not erase each product's licensing, onboarding, retention, or sensor dependencies.

Worked example 4: an email policy is not a merged settings collection¶

A recipient is covered by Strict preset protection and a custom anti-spam policy at priority 0. For that policy type, Strict wins; the custom settings do not merge into it. If Strict and Standard both apply, Strict has precedence. For custom policies of the same type, lower numeric priority wins among matching policies. Email protection precedence is separate from the fixed order of malware/phishing/spam verdict processing. Correlate the effective policy, message headers, trace and Explorer evidence before editing a rule. This differs from satisfying all applicable Conditional Access policies.

A discovered app's unsanctioned tag is governance state. Blocking requires an enabled enforcement path, such as the documented Defender for Endpoint integration and device/network prerequisites, or a supported appliance/block-script integration. Prove the block on the intended devices; a connector or discovery record alone does not block access. Keep connector health, activity freshness, target scope and enforcement evidence separate.

The September Defender feed describes an ISOC preview for eligible E5/E7 customers without an active Sentinel workspace. This is a scoped portal experience, not proof that every tenant has every XDR/Threat Intelligence feature or that Sentinel requires E5. Preserve license, onboarding, RBAC and data-source checks for the exact investigation.

4. Manage compliance with Microsoft Purview¶

Separate detection, labeling, protection, retention, and investigation¶

A sensitive information type detects content patterns through elements such as keywords, keyword lists, regular expressions, supporting evidence, proximity, confidence, and instance counts. Test custom types against representative positive, boundary, and negative samples. A match is classification evidence, not automatically a sensitivity label, retention decision, or DLP action.

Sensitivity labels classify and can apply protection or container settings according to supported scope. Label policy publishes labels and defaults to users or groups. Auto-labeling applies labels when conditions match. Plan label order, scope, encryption, content marking, group/site settings, user justification, downgrade behavior, coauthoring, and application support. Review the sensitivity-label documentation because capabilities differ across files, email, meetings, groups, sites, and applications.

Retention policies apply broad retention or deletion settings by location; retention labels classify individual items and can support records behavior, event-based retention, disposition review, and other item-level actions where licensed. Retention is not backup, and deletion is not immediate in every service. Use the retention overview to model preservation, deletion precedence, adaptive/static scope, record restrictions, and workload support.

Content Explorer shows classified content according to role and access controls; Activity Explorer shows detected and label-related events; reports show aggregate adoption and policy results. These tools contain sensitive metadata and sometimes content access, so use least privilege and audit their use. Review Content Explorer before granting access.

Related item: eDiscovery, Audit, Communication Compliance, Insider Risk Management, and records management may consume the same data and labels. They are adjacent governance capabilities, not interchangeable with the MS-102 information-protection and DLP objectives.

The blueprint still names Content Explorer. Current Data Explorer guidance distinguishes access to the portal tab, List viewer, and Content viewer. These role groups are not cumulative; content viewing can override underlying item permissions, and viewing sensitive item names also requires Content viewer. Assign only the evidence access needed and test administrative-unit scope. A report or label inventory is not permission to read every document.

Design DLP from data path to response¶

DLP evaluates sensitive information and contextual conditions in supported locations, then can audit, warn, justify, restrict, or block according to configuration. Define the data to protect, business workflow, locations, users/groups, conditions, exclusions, action, user notification, policy tip, incident report, alert severity, override, and evidence retention. Begin in simulation where supported, inspect false positives and false negatives, then stage enforcement. Microsoft's DLP overview documents the policy model.

Microsoft 365 DLP can cover supported Exchange, SharePoint, OneDrive, Teams, Power BI, and Microsoft 365 Copilot locations. Coverage and available conditions/actions differ by location. A policy that works for email cannot be assumed to behave identically for a Teams message, Fabric/Power BI artifact, or grounded Copilot interaction. VERIFY CURRENT licensing, workload support, and evaluation behavior before deployment.

Endpoint DLP extends supported controls to activities on onboarded and properly configured devices, such as copying, printing, browser upload, application access, or removable media. It depends on device onboarding, supported platform/version, settings, indicators, browser/domain/service configuration, and policy distribution. Review Endpoint DLP and test the exact operation, application, destination, and device state.

Respond to a DLP alert by validating the rule, matched information, user, device, workload, destination, action, override, business context, and related events. Decide whether to close as expected behavior, tune the rule, educate the user, revoke access, contain a device/account, preserve evidence, or escalate. Do not globally weaken the policy to resolve one false positive; create the narrowest justified exception with owner and expiry.

Related item: A sensitivity label can travel with and protect content, while DLP evaluates an attempted action. Using the label as a DLP condition connects classification to enforcement, but each policy still has its own scope, client, and licensing dependencies.

Worked example 5: measure the errors that a DLP simulation misses¶

A synthetic test set has 60 correctly flagged sensitive items, 15 benign items flagged, five sensitive items missed, and 120 correctly ignored benign items. Precision is 60 / 75 = 80%; recall is 60 / 65 ≈ 92.3%. Looking only at alerts hides the five misses. Review representative nonmatches as well as matches, record the expected policy action and actual result, and retest after tuning. These are learning calculations, not product efficacy claims.

For Teams DLP, separate messages from files stored in SharePoint/OneDrive and match scope to chat versus channel. An individual-user scope covers chats but not channel messages according to the current scope table. For external-access cross-tenant chats, the initiating/hosting tenant's policy applies to its own users' messages; it does not cover the other tenant's users. The other tenant's home policy does not automatically travel into that chat. Test channel behavior separately. Teams uses message flags, not the user-notification email behavior of Exchange/SharePoint/OneDrive. Test both tenants and both storage/message paths with synthetic content.

For Copilot, define whether the requirement concerns grounding sources, prompt text, or uploads before selecting conditions and locations. The Purview feed's preview for external-email grounding and newer network/connected-app previews have specific prerequisites; they do not establish universal AI traffic inspection. Keep a failed or unevaluated scan distinct from a clean result, and a policy tip distinct from the enforced action.

Integrated scenarios¶

Scenario 1: Regulated acquisition tenant¶

A company acquires a smaller business and must onboard 600 workers, preserve the acquired domain, restrict privileged administration, protect regulated documents, and maintain service continuity.

Inventory domains, authoritative directories, duplicate attributes, licenses, groups, workloads, records obligations, and recovery requirements.
Prove the domain and plan DNS without changing production mail flow prematurely. Pilot users and synchronization scope after IdFix remediation.
Use group-based licensing with exception handling; design Microsoft 365 groups, shared mailboxes, external users, and data ownership deliberately.
Delegate tasks through narrow roles, administrative units where supported, PIM, and emergency access. Record cross-workload privilege paths.
Stage Conditional Access and authentication registration. Test normal, high-risk, recovery, guest, and emergency access.
Publish sensitivity/retention labels and simulate DLP before enforcement. Verify workload differences and legal requirements.
Configure Service Health notifications, usage evidence, Backup scope, Defender integrations, and an incident route.

The common failure is changing DNS or synchronization broadly before identity collisions, role ownership, retention, and rollback are understood.

Scenario 2: Hybrid identity compromise¶

An administrator receives a risky-sign-in alert while Connect Sync exports unexpected changes and an endpoint shows suspicious activity.

Preserve sign-in, audit, sync, endpoint, role, and incident evidence with identifiers and time range.
Determine whether the source is on-premises AD DS, synchronization rules/credentials, cloud administration, or a compromised endpoint.
Contain sessions, accounts, devices, roles, and synchronization only as required; retain tested emergency access.
Investigate Defender XDR incident entities and hunt for related users, devices, apps, and mail activity.
Remediate the authoritative object, credential, device, sync rule, and persistence path. Do not merely repair the cloud symptom.
Validate synchronization, authentication, Conditional Access, PIM, endpoint health, and restored business access.

The common failure is resetting the user's password while an overprivileged sync or application identity remains able to recreate the compromise.

Scenario 3: Sensitive-data exfiltration through collaboration and a cloud app¶

Users report suspicious sharing links, a newly authorized SaaS application, and DLP alerts involving endpoint uploads.

Correlate Purview DLP events, sharing/audit evidence, Defender for Cloud Apps activity/OAuth findings, endpoint timeline, identity sign-ins, and XDR incidents.
Validate the sensitive-information match, label, item permissions, application grant, destination, user intent, and device state.
Contain the narrowest unsafe paths: session/account, OAuth grant, file sharing, endpoint activity, app access, or malicious mail.
Preserve evidence, revoke or remediate, search for related data and entities, and validate authorized collaboration still works.
Tune policies only from documented false-positive/negative evidence. Add owner, expiry, and review to exceptions.

The common failure is blocking one cloud app while the same data remains overshared through another authorized path.

Hands-on labs¶

Use synthetic identities and data in an authorized test tenant. Record unavailable licenses as constraints and tabletop the same configuration, tests, evidence, and rollback rather than inventing results.

Lab 1: Tenant, domain, health, network, update, and recovery baseline¶

Create a tenant operations workbook containing domain/DNS state, organization settings, Service Health notification routes, message-center ownership, network insight and local path evidence, Microsoft 365 Apps update policy, usage/privacy settings, Backup scope, recovery objectives, and a restore test plan. Make one safe configuration change and prove approval, effective state, monitoring, and rollback.

Lab 2: User, group, shared mailbox, and license lifecycle¶

Create a cloud user, guest, contact, Microsoft 365 group, security group, and shared mailbox. Assign a group-based license, create one safe assignment error, resolve it, and verify workload provisioning. Use Graph PowerShell to inventory objects without changing them. Exercise mover, disabled-user, guest-expiry, mailbox-conversion, data-owner, and deletion/recovery decisions.

Lab 3: Least-privilege administration¶

Build a task-to-role matrix across Microsoft 365, Entra, Defender XDR, and Purview. Configure a scoped administrative-unit assignment and a PIM-eligible lab role if licensing permits. Test activation, approval or justification, expiry, authorized action, denied action, audit event, and emergency recovery. Document unsupported scoping and indirect privilege paths.

Lab 4: Service and backup evidence drill¶

Choose one supported workload. Capture service-health state, client and network health, usage evidence, protection scope, retention/version behavior, and backup configuration. Perform or tabletop an item-level restore and a larger recovery request. State what native retention, Backup, and legal preservation each do and do not recover.

Lab 5: Synchronization pipeline¶

In a lab or tabletop environment, compare Connect Sync and Cloud Sync against a written topology. Run IdFix on sample data, define scope and source anchor, and trace a create, rename, disable, and deletion through import, join, synchronization, export, cloud object, and workload provisioning. Introduce a safe duplicate-attribute or scope error, capture evidence, remediate at the authoritative source, and retest.

Lab 6: Authentication, risk, and Conditional Access¶

Register two authentication methods for test users, configure SSPR and Password Protection evidence, and stage Conditional Access in report-only mode. Test ordinary access, high-risk sign-in, privileged authentication strength, unmanaged device, excluded emergency account, and recovery. Record sign-in-log policy results and prove a rollback path before enforcement.

Lab 7: Defender XDR control chain¶

Create a control-and-evidence map for Exposure Management/Secure Score, one Office 365 threat policy, an attack-simulation tabletop, endpoint onboarding/health/vulnerability response, Defender for Cloud Apps connection/policy, Cloud Discovery, and XDR incident investigation. Use safe simulations or existing lab alerts. Trace source signal to alert, incident, query, containment, remediation, validation, and closure.

Lab 8: Purview classification, retention, and DLP¶

Create synthetic documents that provide positive, boundary, and negative matches for a sensitive information type. Design a sensitivity label, retention policy or label, and DLP policy in simulation. Include one supported collaboration location and an Endpoint DLP tabletop or test. Inspect explorer/report evidence, user notification/override, alert details, false-positive handling, enforcement rollout, exception expiry, and rollback.

Lab 9: trace the identity dependency chain¶

With synthetic identities or a disposable licensed tenant, inventory direct/nested membership, license assignment state, workload provisioning, Conditional Access results and privileged roles. Model source-to-destination license migration and one assignment error. Inventory a memberOf rule and design its supported replacement; prove both membership and downstream access after the change. Tabletop sync upgrade, app-certificate rotation and an unavailable Health alert as three separate failures.

Evidence: immutable object IDs, source authority, timestamps, effective policy, success/error state, negative tests and rollback owner. Cleanup: remove disposable objects and assignments; retain protected baseline/emergency access. No tenant or directory change was executed in this review.

Lab 10: restore safely and validate policy coverage¶

Build a synthetic recovery matrix for workload, age, full/granular operation, available point, target URL/folder, conflicts, permissions, retention and RPO/RTO. Compare a two-day file request with a 20-day whole-site request; explicitly flag second-year cadence as unverified. Model a paused custom policy alongside Full Workload Backup and a shorter-window move. In a disposable environment, only if available, test an approved harmless restore and compare resulting permissions and current edits. Observe the documented limit on test restores per protection unit.

Add a DLP truth table covering both tenants in a chat, channel messages, files and a nonmatch sample. Evidence: selected point, scope, timing, expected/actual action and false-positive/false-negative counts. Cleanup: remove disposable restored content and test policies under the retention plan. No restore, pay-as-you-go operation, DLP deployment or paid feature was executed here.

Original knowledge checks¶

These are original study questions, not recalled or reconstructed exam items. Answer in your own words, then verify against the cited official documentation and lab evidence.

Why does proving a custom domain not complete Microsoft 365 service configuration?
Which evidence distinguishes a Microsoft service incident from a tenant network or identity problem?
Why are usage reports not a direct measure of business value or employee performance?
How do retention, version history, recycle bins, legal preservation, and Microsoft 365 Backup solve different recovery needs?
When should you choose a Microsoft 365 group, security group, distribution group, contact, or shared mailbox?
What must be verified after a license assignment succeeds?
Why should bulk administration be idempotent and record partial failures?
How do Microsoft 365, Entra, Defender XDR, and Purview roles differ?
What can an administrative unit scope, and what does it not partition?
Why does PIM not make an overprivileged role safe?
Which requirements favor Connect Sync, and which favor Cloud Sync?
What does IdFix validate before synchronization?
How do you trace a synchronization failure from source object to workload result?
Why can a healthy synchronization agent coexist with individual object errors?
How do authentication-method policy, SSPR, Password Protection, and Temporary Access Pass differ?
Which evidence separates failed authentication from failed workload authorization?
Why is authentication strength more precise than a generic MFA requirement?
How should Identity Protection risk affect investigation and Conditional Access without being treated as proof of compromise?
What must be tested before enabling a tenant-wide Conditional Access policy?
Why should emergency-access accounts be cloud-only, monitored, and excluded deliberately?
How do an exposure recommendation, Secure Score improvement action, alert, and incident differ?
What makes an advanced-hunting result reliable enough to drive response?
Why is an email allow entry a time-bound risk decision rather than a convenient permanent fix?
How do EOP, Safe Attachments, Safe Links, and mail-flow rules protect different parts of a message path?
What must happen before a restricted sender is unblocked?
Why does endpoint onboarding not prove prevention settings and sensor health are complete?
Which factors should prioritize a vulnerability recommendation?
What does connecting Microsoft 365 to Defender for Cloud Apps add, and what prerequisites remain?
Why is a discovered cloud application not automatically unsafe or safe?
How do a sensitive information type, sensitivity label, retention label, and DLP rule differ?
When should you use a broad retention policy rather than an item-level retention label?
What access risks exist in Content Explorer and Activity Explorer?
Why must DLP behavior be tested separately for Exchange, SharePoint, OneDrive, Teams, Power BI, Copilot, and endpoints?
Which dependencies make an Endpoint DLP rule effective on a device?
How should a DLP false positive be resolved without creating an unbounded exception?
What evidence proves a cross-domain Microsoft 365 incident is contained, recovered, and unlikely to recur?

Answer key¶

DNS verification establishes ownership; workload records, routing and migration remain separate.
Correlate tenant Service Health with client DNS, proxy, connectivity, sign-in and workload evidence.
They count activity; context, privacy controls and business outcomes are separate.
Retention/holds preserve or delete for governance; versions and recycle bins address narrower recovery; Backup has explicit scope, points and restore operations.
Choose from collaboration membership, permission assignment, distribution, address-only contact or delegated mailbox requirements.
Verify service plans, assignment errors and actual workload provisioning/access.
Retries must not duplicate changes; per-object errors preserve evidence and allow scoped recovery.
They authorize different administrative planes and operations; a title in one portal is not universal access.
It scopes supported directory administration; it does not partition every workload or confer a role.
Activation limits time, not the breadth of the activated permission.
Compare topology, object types, source authority, writeback, custom rules, availability and migration support.
Directory attributes and common synchronization readiness problems; it does not validate the entire hybrid design.
Follow source, filter, import, join/rule, export, cloud object and workload using identifiers and errors.
Agent/service health and per-object export/provisioning success are different signals.
Methods policy enables methods; TAP bootstraps registration; SSPR recovers access; Password Protection rejects weak passwords.
Inspect sign-in authentication/CA details and separately inspect workload roles, license and resource permissions.
It restricts acceptable authentication combinations, including phishing-resistant methods.
Correlate risk with user/device/session evidence, then use scoped investigation and remediation.
Test targeting, report-only results, supported clients, allowed/denied paths, registration, emergency access and rollback.
They preserve recovery independent of hybrid failures; deliberate exclusions and monitoring prevent a hidden unmanaged bypass.
Exposure describes attack opportunities, score tracks recommendations, alerts flag signals, and incidents correlate related evidence.
Correct time range, stable IDs, source coverage/freshness, joins, duplicates and independent corroboration.
An allow can bypass protection; document false-positive evidence, scope, expiry and review.
Mail hygiene, detonation, URL protection and transport processing address different stages and threats.
Investigate compromise/spam cause, remediate credentials/session/device issues and verify safe sending before unblocking.
Sensor onboarding is separate from active prevention policy, health, reachability and reporting.
Exposure, exploitability, affected critical assets, observed threats, remediation impact and verification.
Workload activity and governance visibility; licensing, permissions, consent, connector health and effective response still matter.
Discovery proves observed use; risk assessment, business purpose and enforcement evidence determine treatment.
SIT detects patterns; sensitivity labels classify/protect; retention labels govern item lifecycle; DLP governs actions.
Use broad location-based retention for common requirements and item-level labels for specific lifecycle rules.
They expose sensitive metadata/content; separate portal, list and content rights and audit access.
Location, scope, supported conditions/actions, licensing, clients, tenant host and evaluation differ.
Supported onboarded devices, required permissions/settings, policy delivery, browser/app/destination and current health.
Validate the match, tune narrowly with owner/expiry, and retest both allowed and blocked cases.
Correlated containment, removed persistence, restored access/data, healthy telemetry and a verified recurrence-prevention change.

Additional reasoning checks¶

Does meeting the September 30 minimum mean a Connect server is on the latest supported release? No; check current release/support history separately, including the October 23 end for 2.5.79.0.
Does a healthy sync service prove certificate rotation works? No; inspect configured owner, scheduler, expiry and rotation evidence.
Can 50 direct users plus 20 nested-only users yield 70 successful group licenses? No. With three direct-user errors and no other assignments, this example yields 47.
Does ten-minute full-site RPO guarantee a ten-minute file restore point? No; granular points have a different schedule.
Does pausing a custom backup policy make Full Workload Backup take over? No; a paused custom policy retains precedence.
Can custom anti-spam priority 0 override a matching Strict preset? No; preset precedence is evaluated first for that type.
Are 75 DLP alerts with 60 true positives enough to calculate recall? No; the five missed sensitive items are also needed. Precision is 80%, recall about 92.3% in this example.
Does the replacement training course establish a replacement expert certification? No; follow the credential and exam lifecycle sources separately.

Final readiness checklist¶

Places to learn¶

October 28 learning route and evidence task¶

The official MS-102 course still publishes five instructor-led days. The Pluralsight path still lists five 2025 courses totaling 7 hours 44 minutes (header rounded to 8 hours). These are content-consumption figures; they do not include tenant preparation, negative tests or source review. Choose one route and use the April 2026 objective map to identify gaps. Existing blocked book/Udemy details remain historical; class availability and retirement timing require their own current checks.

Original resource-gap audit (about 45–60 minutes, editorial estimate): Choose one task from tenant operations, identity, Defender and Purview. Map each to a specific lesson, current product reference, lab evidence and unresolved limitation. Prioritize a missing high-impact task rather than replaying a familiar whole course.

Answer checkpoint: Completing every listed video does not establish readiness if you cannot produce the task’s permitted/denied result and recovery evidence. A dated public syllabus establishes advertised coverage, not current lesson accuracy.

This is a curated starting point, not a complete list. Do not try to consume every item. Pick the format and depth that work for you, use the current official blueprint as the coverage checklist, and reserve substantial time for tenant practice, negative tests, troubleshooting, and review. Because MS-102 retires November 30, 2026, verify that any planned course and exam date leave enough recovery time for rescheduling.

Blog readings with practical tasks¶

Reading	Learning task	Limits
Microsoft 365 Backup granular restore now generally available, Microsoft author `diksha050`, April 29, 2026	Spend an estimated 20–30 minutes comparing one damaged file with a compromised site: choose operation, point, destination and permission checks.	Main article reviewed. Its future in-place wording is historical; current restore instructions document that option. It does not promise the same recovery-point cadence for full and granular restore.
What's new in Microsoft Entra: September 2026, Yina Arenas, September 1, 2026	Spend an estimated 20–30 minutes drawing `memberOf` dependencies from membership through licensing, delegated scope and CA. Plan migration and negative tests before November 3.	Main article reviewed; the linked product documentation confirms the retirement. Cloud-to-AD provisioning and MCP firewall are labelled preview in the article and remain adjacent context, not assumed blueprint additions or universal tenant availability.

Public catalogs and module outlines were checked; paid lessons/questions and tenant demonstrations were not consumed. O'Reilly book/video and Udemy retrievals were blocked, so their historical dates and runtimes below are unverified current metadata. Partner and video-channel shells do not establish a current course schedule or content coverage.

The nine official paths linked from the MS-102 course list 39 modules. Their earlier per-path times below are historical metadata; the current retrieval did not expose runtimes. The paths are configure your tenant (3h31), manage your tenant (3h33), implement identity synchronization (2h38), manage identity and access (4h28), manage Defender XDR security services (2h59), implement Defender XDR threat protection (3h05), explore data governance (2h03), implement compliance (4h11), and manage compliance (2h17). Historical listed times total 28h45; current duration is unverified. Budget separately for labs, notes, prerequisite remediation and spaced review.

Resource	Access	Estimated time
Official MS-102 study guide and Administrator Expert credential page	Public	1–2 hours initially; 15 minutes on each recheck
Nine official Microsoft Learn paths linked from the MS-102T00 course syllabus	Public	Historical 28h45; allow an estimated 45–65 hours with exercises and notes
MS-102T00 instructor-led course	Paid/partner delivery	5 days listed
Microsoft MS-102 Practice Assessment	Public	45–75 minutes per attempt plus source review
O'Reilly MS-102 certification course with Aaron Guilmette	Paid	Historical 4h23, January 2025; page blocked. Reconcile the April 2026 changes and retirement baseline
O'Reilly/Microsoft Press Exam Ref MS-102 by Orin Thomas	Paid	Historical 7h37 / 305 pages, November 2023; page blocked and current edition/content unverified. Check April objectives
Udemy MS-102 course with simulations by John Christopher	Paid	Historical 15h05, August 2026 update; page blocked. Current runtime, lessons and objective coverage unverified
MeasureUp MS-102 practice test	Paid	Public listing: 123 questions (36/30/36/21 by domain), last update November 2025. Paid content unreviewed; about 5–9 hours is a planning estimate. Vendor language claiming the exam alone earns the expert credential omits the associate prerequisite
Pluralsight MS-102 path	Paid	Five public course listings total 7h44 (path rounds to eight hours), dated June–December 2025. April 2026 coverage and paid practice content unverified

| Microsoft Mechanics | Public | 2–8 hours selectively for current Microsoft 365, Entra, Defender, Purview, and admin demonstrations; not an objective-mapped MS-102 course | | Microsoft Reactor | Public | 2–8 hours selectively; use current Microsoft 365 security, identity, compliance, and Copilot sessions only where they close a mapped gap | | Partner Skilling Hub | Partner-restricted | Schedule dependent; partner sign-in is required to confirm a current MS-102 offering and exact session duration |

No exact current Whizlabs MS-102 product page was established; none is inferred from its broader catalog. Older MS-102 courses can still teach durable administration, identity, Defender, and Purview foundations, but they must be reconciled against the April 28, 2026 blueprint and the November 30 retirement.