MD-102: The Endpoint Administrator’s Decision Map

A company can enroll a thousand laptops in Microsoft Intune and still have an endpoint-management problem. Devices arrive on time, but users cannot access an important application; compliance reports disagree with sign-in behavior; a security update succeeds on test machines and disrupts a production fleet. The trouble is rarely a missing button in the admin center. It is usually an ownership, sequencing, or policy decision that the team did not make explicitly. The Microsoft MD-102 exam examines these decisions through Windows and cross-platform endpoint management, with Intune and identity controls at the center. Preparing well means understanding the chain from acquiring a device to retiring it securely, not memorizing a collection of console screens.

Microsoft’s July 24, 2026, skills outline describes five areas: preparing infrastructure for devices (20–25%), managing and maintaining devices (25–30%), protecting devices (15–20%), managing and securing applications (15–20%), and optimizing operations with automation, monitoring, and reporting (10–15%). These are exam domains, not five isolated IT departments. A new Windows deployment, for example, may require decisions about device identity, application delivery, encryption, compliance evaluation, and support telemetry before a user signs in. The most useful way to study is to trace those dependencies and explain what would change if an assumption failed.

Begin with ownership, identity, and the device’s purpose

The first question for endpoint management is not which enrollment profile to select. It is whether the organization owns the device, whether the user owns it, and which management actions the organization has a legitimate need to perform. Corporate Windows laptops, employee-owned iPhones, shared warehouse Android devices, and kiosk systems need different enrollment experiences and control boundaries. Applying a full-device management model to every personal device may create privacy and adoption problems; treating a payment-processing kiosk like a casual personal phone may leave critical controls unenforced. Document who may use each device, what data it accesses, who repairs it, and how the organization will revoke access.

Device identity and user identity are related but not interchangeable. Microsoft Entra registration, Entra join, and hybrid join represent different trust and management arrangements. A device can be known to an identity tenant without inheriting the same administrative capabilities as a corporate-managed endpoint. Similarly, authenticating a user does not establish that the laptop is healthy, encrypted, or running approved software. The distinction becomes clear when Microsoft Entra Conditional Access combines user conditions with device compliance or app-protection requirements. Design the device’s intended state before deciding which technical signal will represent it.

Choose an enrollment route before touching deployment settings

Enrollment is a process with prerequisites, not a single enrollment toggle. Windows automatic enrollment depends on tenant and identity settings; Windows Autopilot depends on device registration, deployment profiles or device preparation policies, appropriate licenses, network reachability, and assignment. Mobile platforms introduce their own enrollment ecosystems. Apple Business Manager can support corporate Apple enrollment, while Android Enterprise offers different patterns for work profiles, fully managed devices, and dedicated devices. Administrators should know where manufacturer enrollment systems end and Intune’s management responsibilities begin.

For a laptop dispatched directly from a reseller, user-driven Windows Autopilot may be appropriate because the employee can complete an identity-driven out-of-box experience. A shared meeting-room computer has different sign-in and lifecycle requirements; a device shipped through a staging facility may benefit from pre-provisioning. These are operational choices involving logistics, ownership, and what is allowed to happen before the user arrives. Understanding Apple Automated Device Enrollment is useful when comparing how a platform’s device-assignment system supports corporate ownership without assuming its workflow matches Windows Autopilot. Expect scenario questions to distinguish the intended endpoint experience from the underlying service names.

Make policy assignment predictable

A central tenant can hold hundreds of configuration, compliance, app, and security policies. Without a targeting strategy, admins cannot explain why two similar devices behave differently. Dynamic groups, assigned groups, assignment filters, enrollment-time groups, and scope tags solve different problems. Dynamic membership expresses a rule about directory objects. Assignment filters refine applicability using device properties. Scope tags limit administrative visibility and control in delegated settings; they do not replace target assignments. Before creating another policy, identify which cohort needs it, how conflicts will be detected, and what happens when a device moves between cohorts.

Consider a newly hired sales employee who needs a managed Windows laptop, a personal iPhone with protected Outlook data, and access to a sensitive CRM. The Windows device might receive full MDM configuration and compliance rules. The personal phone may use app-protection policies without full-device management where the scenario permits. Application access is then evaluated against the appropriate identity and device or application signals. A simple spreadsheet of control owners, targeted groups, exceptions, and rollback steps is often more valuable than a forest of policies named after departments. The Microsoft SC-300 identity scope is a useful contrast: MD-102 applies identity decisions to the lifecycle of physical and virtual endpoints rather than treating identity governance as the entire job.

Know what ‘compliant’ does and does not mean

Intune compliance rules measure configured conditions such as supported operating system versions, encryption, or device risk thresholds. A compliance result is an input to access decisions; it is not a universal security verdict. An attacker can still exploit a compliant device, and a legitimate device can become noncompliant because its reporting channel or evaluation state is delayed. Likewise, a configuration profile records the desired device setting, while a compliance rule evaluates whether requirements are met. Conflating those two functions creates surprising access-denial incidents and poor troubleshooting.

A good MD-102 scenario starts with the observed symptom and asks which layer could plausibly cause it. When a user is blocked, first establish whether the sign-in rule requires a compliant device, an approved app, an app-protection policy, or some combination. Then check enrollment status, configuration arrival, last check-in, compliance reasons, and identity sign-in details rather than repeatedly changing policies. If the organization relies on conditional access to require managed posture, deliberately test a device with out-of-date operating system settings and a device that has not checked in. Explain why the expected outcomes may differ, and write the remediation path before enforcing the policy on a broad group.

Treat application delivery as a separate engineering problem

Successful device enrollment does not guarantee successful application deployment. Win32 packages need detection logic, installation commands, prerequisites, and assignment context that match the target. Microsoft Store applications, line-of-business packages, Microsoft 365 Apps, and mobile applications offer different deployment paths. The failure that matters might be an invalid detection rule, a required dependency, an installation context mismatch, a missed licensing prerequisite, or a device that cannot reach content. Learn to read status and logs rather than treating every failed install as the same failure.

Protection follows the information, not just the executable. On personal devices, Intune app protection can control supported organizational data inside managed apps without claiming ownership over all device functions. On managed devices, app configuration and device-wide restrictions may operate together. Distinguish an application configuration policy, which supplies settings, from a protection policy, which constrains data movement and other supported behaviors. It is possible to deploy an application successfully and still have its user blocked by a conditional-access requirement or protection-policy mismatch. Test those situations independently to avoid attributing every symptom to packaging.

Build security and update policy around risk

The endpoint administrator does not replace an incident-response or security architecture team, but the role makes security policy tangible on devices. BitLocker recovery-key administration, firewall policy, antivirus settings, attack-surface reduction, Windows LAPS, application control, and Microsoft Defender for Endpoint integration turn abstract requirements into maintainable controls. A security baseline can accelerate standardization, but it still requires assignment planning, exceptions, evidence collection, and rollback decisions. Baseline adoption without validation can disrupt an older business application as readily as it improves posture.

Update management should differentiate update rings from feature-update targets, quality updates, Windows Autopatch, and supported mobile operating-system update policies. A sensible rollout protects a pilot group before widening exposure. If a feature update unexpectedly breaks a VPN client, the response depends on deployment targeting, safeguard conditions, remediation options, and business impact—not on whether the administrator can locate the update setting. For the broader tenant-level perspective, Microsoft MS-102 deals with Microsoft 365 administration across workloads; MD-102 goes deeper into what users’ devices actually receive and report.

Measure health and make automation explainable

The 2026 MD-102 objectives explicitly include automation and monitoring. PowerShell and Microsoft Graph can perform repeatable management tasks, while Endpoint Analytics, Intune reporting, proactive remediations, device queries, and service-health information help explain operational outcomes. Automation is useful when it reduces a measured recurring problem. It is dangerous when a script is allowed to act across the fleet without a pilot, logging, a rollback plan, and clear execution privileges. Even a harmless-looking fix for a missing setting can override a business exception if its scope is not controlled.

A practical dashboard should answer a small number of business questions. How many endpoints are unable to report? Which cohort is repeatedly failing feature updates? How long does enrollment take for new starters? Which application causes the most support tickets? Which devices lost encryption or endpoint-protection coverage? Monitor trends by platform and policy group, not only aggregate fleet averages. A small population of critical shared devices can disappear inside an otherwise impressive compliance percentage. Technical monitoring becomes useful when the administrator can translate a deviation into a safe action and verify that the action worked.

Practice decisions across the complete lifecycle

Build one fictional enterprise with three populations: new corporate Windows laptops, personally owned mobile devices, and shared reception devices. Describe their join or registration state, enrollment path, initial configuration, application rules, access conditions, update schedule, support diagnostics, and retirement process. Now inject faults: an unregistered laptop, a conflicting group assignment, a stale compliance status, an app-detection mistake, and a lost device. At each fault, identify the first source of evidence and the safest correction. This exercise exposes misunderstandings that reading feature descriptions in isolation rarely reveals.

Avoid treating the current skills percentages as a promise about particular questions. Microsoft’s exam objectives and products change, and the guide includes an announced later-October update that must be rechecked for publication or a later test date. The durable foundation is a precise model of the lifecycle and clear reasoning about identity, management, application protection, and device health. If you can explain the correct control, its prerequisite, its monitoring signal, and its failure behavior for a realistic endpoint scenario, you are studying the work MD-102 is built to assess.