Study MD-102 as an endpoint administrator, not a memorizer of settings
The Microsoft MD-102 exam concerns managing and securing endpoints with Microsoft Intune and related Microsoft 365 services. The central skill is understanding what a deployment or policy will do to real users, how to detect when it fails, and how to recover without interrupting an entire fleet. Preparation should therefore simulate the decisions of an endpoint administrator rather than collect screenshots of every console blade. Start with a small managed-device estate, a realistic business requirement and evidence for each change.
Microsoft’s English MD-102 skills outline is scheduled to change on October 27, 2026. Candidates should match their preparation to the objectives in effect on their sitting date, taking account of any localized schedule. The Microsoft MD-102 skill set extends beyond enrollment into application management, device security, Windows servicing and operational troubleshooting.
Begin with a device and ownership model
Imagine a company with 150 Windows laptops, a mix of employee-owned phones, a remote helpdesk, and an organization that permits access to customer records only from devices meeting defined requirements. The question is not simply how to enroll a device. You must decide which devices the organization may manage, which applications and data are in scope, and how users regain access when enrollment or a compliance evaluation fails.
Record each enrollment cohort separately: corporate Windows, personally owned mobile, new devices, and devices being transferred from older management. Document whether the onboarding flow uses Windows Autopilot, a platform-native enrollment path, or an existing co-management approach. Then map who owns the device, who receives configuration, what security baseline applies, and what offboarding removes. Do not assume that a personal device permits the same management actions as a corporate asset.
An enrollment lab should follow one device from first login through an app install, a compliance check, a policy refresh and a deliberate failure. Capture tenant configuration identifiers and relevant device and user scope, but use fictitious identities in the public case notes. Make the experiment repeatable from a clean state and distinguish an intentionally delayed sync from a broken configuration. Predictable Intune enrollment depends on making assignments, prerequisites, check-in timing and failure recovery observable across supported platforms.
Treat policy assignment as a decision with consequences
Intune device configuration, endpoint security and application deployment policies can overlap. A success message from one policy does not guarantee the device’s effective state if another policy conflicts or a prerequisite is absent. Design a simple assignment matrix with the target groups, exclusion groups, required platform and supported operating-system version. Add a test account and device representing a conflicting assignment before deploying to a broad production group.
For example, a company wants removable-storage restrictions on devices handling regulated data. Before deploying, clarify whether the restriction applies to all storage, selected file types, or specific device users, and what business exception process is available. Test a controlled device, record the effective policy and user experience, and define rollback. A policy that exists in the portal but cannot be verified on the endpoint is not complete configuration management.
Scope matters as much as payload. A device-targeted policy and a user-targeted policy may behave differently as employees move across shared computers. Document how assignment membership is calculated, when device check-in occurs and what the operator can see when an update is pending. Avoid generic advice such as ‘apply a security baseline to everyone’ without testing compatibility and exceptions.
Connect compliance, identity and Conditional Access carefully
Compliance is an evaluation of device state against defined rules. Microsoft Entra Conditional Access can use that result as one input to access decisions, but compliance and access policy are separate control planes. A device may be compliant but a user still denied because another condition is unmet; an unmanaged device may access some applications if the organization’s policies expressly allow it. Write an access matrix showing one permitted and one denied scenario for each device cohort.
Use a test user to evaluate how multifactor authentication, authentication strength, risk, location and device compliance conditions interact. Exclude and protect emergency-access accounts according to established tenant recovery practices; do not blindly disable all alternate access routes during a policy pilot. Compare the outcome shown in Entra sign-in logs with the compliance result in Intune rather than assuming an Intune status explains every access decision.
When a device reports ‘not compliant,’ isolate the exact failing rule, data freshness and sync status. Did an update fail? Is a setting unsupported on that platform? Is the device record stale or duplicated? A diagnostic should identify the cause before recommending ‘delete and re-enroll,’ because destructive enrollment repair may affect user data and certificates. The interaction between compliance and Conditional Access becomes testable when the same identity signs in from one compliant and one noncompliant device, with other conditions held constant.
Deploy applications with a verification contract
Application assignment tests whether a package is actually usable, not just present in a management console. A Windows app may need prerequisites, a specific install context, detection rules, supported architectures, user data migration and a rollback or uninstall plan. Design a package test for a fictitious expense application with two versions and an older dependency. Specify a detection rule that reflects the real application version rather than a directory that might exist after an incomplete install.
Deploy first to an isolated test group. Track download, installation result, detection, first launch, user permissions and telemetry after reboot. Simulate an interrupted download, a missing prerequisite and a system with an already installed old version. Note which event produces a retry, which requires a new assignment and which requires package rework. The test is not complete until the app launches with the intended user’s privileges and its business function works.
If an application fails only for a subset of endpoints, compare OS version, enrollment channel, scope and install context before blaming network bandwidth. An operator needs to know what evidence separates a packaging fault from a device or assignment fault. Capturing those differences is more valuable preparation than memorizing the order of clicks for one portal release.
Manage Windows updates as a controlled fleet change
A Windows update rollout should balance security timelines against business availability. Consider a small pilot ring, a larger early ring and a later broad ring. Define what qualifies a device for each ring, when quality and feature updates are expected, how reboots are communicated and what signals stop progression. A ring policy alone cannot guarantee every update will succeed; devices may be offline, out of disk space or incompatible with a particular driver.
Measure update compliance and failure reasons after each stage. Record how many devices checked in, how many installed, how many require a reboot and how many remain unsupported. Do not use a denominator that silently excludes inactive devices, because doing so can make a failed rollout appear successful. Include a deliberately unpatched test device and a blocked driver scenario to verify alerting and remediation.
A pause, expedited update, feature update target and rollback mechanism serve different purposes. Their available controls depend on Windows and Intune versions and supported deployment methods. Check the current vendor documents and license requirements before claiming a specific toggle applies to every enrolled device. Windows update deployment is therefore a measurement problem as much as a policy-setting task: approval, installation, reboot and health all need distinct evidence.
Diagnose an endpoint incident without erasing useful evidence
Suppose a laptop no longer satisfies compliance and a required application will not open. A rushed administrator might wipe the device, delete the enrollment record or manually exempt the user. Each action can hide evidence and create a new business risk. Start by confirming the affected identity and device ID, actual user symptom, last check-in, latest policy evaluation, current update state and relevant installation logs. Note whether the device remains accessible for further diagnostics.
Form two competing hypotheses: a compliance evaluation blocked access, or the application installation failed independently. Test each using a permitted identity and a known-good device. Change one variable at a time. Document the result, required exception and reversible remediation. A broad exception should have an owner and expiry; it should not become permanent merely because it restored one user’s access.
For a multi-user incident, compare the common factor across devices before taking per-device actions. A badly scoped assignment or identity policy may explain a wave of failures better than simultaneous hardware faults. The correct technical response often begins with stopping further rollout while preserving known-good cohorts.
Build evidence for the actual MD-102 responsibilities
A useful final exercise brings these decisions together. Enroll a device, deploy a required app, enforce a compliance policy, protect access to a sample business application and roll out an operating-system update through a test ring. Introduce one deliberate failure in each phase and explain the difference between portal state and effective endpoint behavior. For every decision record the scope, expected state, observed state, rollback and user impact.
Map the results to the dated official MD-102 study guide; mark any objective you cannot demonstrate as an explicit study gap. Use legitimate sandbox tenants and test devices, not uncontrolled changes to a work tenant. Repeat the lab after removing preexisting assignments so it does not rely on hidden state. The core preparation outcome is not confidence or a collection of question-bank scores: it is the ability to predict, observe and safely correct endpoint-management behavior across a real fleet.