Microsoft MD-102: Thinking Through Scenarios

MD-102 scenarios become much easier when you stop treating Intune as one large settings catalog and start following the endpoint lifecycle. A device must be identified, enrolled, configured, secured, supplied with applications, evaluated for compliance, updated, monitored, and eventually retired or reset. Most scenario questions are asking which stage of that lifecycle owns the problem.

The current MD-102 exam is in a near-term transition. Microsoft’s current study guide lists skills measured as of July 24, 2026, while an English-language update is scheduled for October 27, 2026. Candidates testing after that date should compare the updated objectives with their notes before final review rather than assuming every item remains unchanged.

A useful scenario method is simple: identify the desired endpoint state, determine which service or policy owns that state, check the prerequisites, and then choose the smallest safe action that moves the device toward the intended configuration.

Enrollment scenarios usually fail before policy ever applies

If a device cannot enroll, first ask whether the user and device meet enrollment prerequisites. Licensing, platform support, enrollment restrictions, Microsoft Entra join state, device ownership, management scope, and network access can all block enrollment before any configuration profile is relevant.

The Endpoint Administrator Associate certification validates this deployment lifecycle. A scenario that says “the profile is not applying” may actually describe a device that never completed enrollment successfully.

Practice separating corporate devices, personally owned devices, shared devices, kiosks, and Cloud PCs. The correct enrollment method depends on ownership and user experience as much as on the operating system.

Autopilot scenarios are dependency chains

Windows Autopilot involves device registration, deployment profiles, group assignment, enrollment, the Enrollment Status Page, required applications, device naming, and sometimes pre-provisioning. A failure late in the process can come from an earlier assignment problem.

Draw the sequence. Is the hardware identity registered? Is the correct profile assigned? Are required applications available and detectable? Is the user licensed? Is the device able to contact Microsoft services? Which item is blocking the Enrollment Status Page?

The existing MD-102 endpoint administration material is useful when paired with this evidence chain rather than read as a feature list.

Configuration scenarios should begin with policy ownership

A setting might be delivered through Settings Catalog, configuration profiles, security baselines, endpoint-security policies, update policies, scripts, or application configuration. If two policies control the same setting, conflict becomes a policy-design problem rather than a client problem.

Before editing anything, identify which policy is intended to own the setting. Then inspect assignment, applicability, device status, and conflict reporting. A local manual change may disappear at the next sync because the management plane continues to enforce another value.

The strongest answer preserves central intent and eliminates conflicting management paths rather than creating one-off exceptions.

Compliance scenarios are about state evaluation, not configuration alone

A device can have the correct configuration and still report noncompliant if the state is stale, the policy expects a different value, or an evaluation dependency failed. Conversely, a device can be enrolled and managed while still failing compliance.

When Conditional Access requires a compliant device, the endpoint and identity layers meet. The SC-300 exam goes deeper into access policy, but MD-102 candidates should understand why a device status in Intune can change the user’s ability to reach Microsoft 365 resources.

Scenario practice should separate “make the device compliant” from “allow the user access.” Those are related outcomes owned by different services.

Application deployment scenarios depend on detection and context

Win32 application deployment commonly fails because of packaging, install context, detection rules, dependencies, supersedence, requirement rules, or installer return codes. The portal can report failure even when the application installed, or report success when an overly broad detection rule matched the wrong state.

Write the detection logic before deploying. Ask exactly what evidence proves the required version is installed. Then test uninstall and upgrade behavior.

App protection policies add another scenario type: protect corporate data inside supported applications without taking full device-management control of a personal endpoint. That is a data-protection decision, not a normal Win32 deployment decision.

Endpoint security scenarios should match the risk to the control

Microsoft Defender for Endpoint, antivirus, firewall, disk encryption, attack-surface-reduction rules, account protection, security baselines, and endpoint privilege controls each reduce different risks. The question usually contains clues about which security outcome matters.

If the risk is stolen-device data, encryption is central. If it is malicious execution, Defender and attack-surface controls matter. If it is excessive local privilege, account or privilege-management controls are more relevant than another malware setting.

The broader Microsoft certifications separate endpoint, identity, cloud security, and Microsoft 365 roles, but MD-102 scenarios often sit exactly where those signals overlap.

Update scenarios are deployment and recovery problems

Windows update management involves rings, feature updates, quality updates, deadlines, restart behavior, pilot groups, reporting, and rollback. The correct answer often depends on whether the organization is testing a change or recovering from one.

A strong design starts with a small validation ring, expands to a pilot population, and reaches broad deployment only after compatibility is known. If a driver or update breaks a critical application, the technician should know which policy to pause and how affected devices are identified.

Do not treat “update faster” as universally correct. Endpoint management balances security urgency with fleet stability.

Remote action scenarios require ownership awareness

Retire, wipe, restart, sync, remote lock, Fresh Start, and similar actions have different consequences. A personal device that should lose only company data should not necessarily receive the same treatment as a corporate device being reassigned.

The AZ-104 exam manages cloud infrastructure rather than user endpoints, which helps clarify a common boundary: MD-102 actions should be chosen based on the endpoint’s ownership, management state, and recovery goal.

Always ask what data must remain after the action and who owns the device. That usually eliminates the most destructive distractors.

The best MD-102 scenario answer restores the intended lifecycle state

For final practice, take one endpoint and describe the expected state at each stage: registered, enrolled, configured, compliant, protected, supplied with applications, updated, monitored, and recoverable. Then create a failure at one stage and identify the evidence that proves it.

If you test on or after October 27, review the updated Microsoft blueprint before your last practice session. The UI and exact objectives can change, but lifecycle reasoning remains a reliable way to organize endpoint administration.

MD-102 scenarios stop feeling random when every symptom belongs to an endpoint lifecycle stage and every answer is judged by whether it restores that state safely at scale.

Co-management can complicate scenarios where Configuration Manager and Intune both participate in endpoint administration. The question is not simply whether the device is “managed.” Identify which workload has moved to Intune, which settings still come from Configuration Manager, and whether the device is correctly enrolled for co-management. A policy failure can occur because the administrator changed the right setting in the wrong management authority.

Certificate, VPN, and Wi-Fi profile scenarios also deserve practice because they combine identity, device configuration, and network prerequisites. If a managed certificate is missing, the device may fail Wi-Fi or VPN authentication even though the network itself is healthy. Trace profile assignment, certificate delivery, trusted root state, user or device identity, and the final network connection in that order.

Health reporting should be treated as evidence rather than decoration. Endpoint analytics, update reports, app-install status, device compliance, security recommendations, and check-in state can reveal whether a problem is isolated or systemic. If twenty devices in one hardware model show the same failure after an update, the next action differs from a single-user support ticket.

Licensing belongs in the prerequisite layer too. Intune Suite capabilities, Windows 365, Defender integration, and some endpoint features can depend on the tenant and user licenses available. You do not need to memorize every bundle, but a scenario in which a control is missing despite correct configuration should make entitlement one of the checks before assuming the portal is broken.

For timed practice, state the lifecycle stage before reading the answers: enrollment, deployment, configuration, application, compliance, security, update, automation, or recovery. Then reject options that operate at a different stage. This simple classification prevents a familiar product name from distracting you away from the actual endpoint-management problem.

Windows 365 and Cloud PC scenarios deserve a place in the same lifecycle model. A user may have the correct Intune policies but still be unable to provision or access a Cloud PC because licensing, provisioning policy, network configuration, or identity assignment is wrong. Treat the Cloud PC as another managed endpoint with cloud-hosted compute, not as a completely separate product.

For final review, keep one evidence checklist: Entra device state, Intune enrollment, primary user or ownership, policy assignment, compliance, application status, Defender health, update status, and last check-in. Working through those signals in order is faster than browsing every Intune blade when a scenario contains several plausible causes.

One last useful scenario is device reassignment. Decide which user association, application data, certificates, and management records should remain when a corporate endpoint moves to another employee. The right action should prepare the device for the next owner without leaving the previous user’s data or breaking enrollment.

• Category: All Certifications Certifications