MD-102 should be studied in lifecycle order rather than by portal menu. Start with Entra device identity and Intune enrollment, then compliance and access, Windows deployment, cross-platform configuration, Intune Suite, endpoint security, updates, application management, and finally automation/analytics. This sequence builds dependencies before the policies that rely on them.
Use the live July 24, 2026 MD-102 objectives for exams taken before Microsoft’s announced October 27 update.
Phase one: master Entra device identity
Review registration, Entra join, groups, dynamic membership, Intune/Windows 365 roles, scope tags and local-group/LAPS concepts. Build a simple table showing which identities belong to users, devices, groups and administrators.
Identity clarity makes later assignment and access questions much easier.
Phase two: practice enrollment across platforms
Compare Windows automatic enrollment, macOS/iOS through Apple Business Manager, Android enterprise modes, Knox Mobile Enrollment and Zero Touch. Add enrollment restrictions and ownership decisions.
For each platform, know what makes a device corporate, personal, fully managed, dedicated or work-profile based.
Phase three: connect compliance and Conditional Access
Create or model one compliance policy and one Conditional Access policy that requires compliant devices. Then test a noncompliant condition and reason through user impact.
A Conditional Access review is valuable because the access decision is separate from the compliance calculation.
Phase four: build Windows deployment fluency
Study Autopilot profiles, device preparation, user-driven/pre-provisioning/self-deploying modes, naming, Enrollment Status Page, Windows 11 upgrades, Windows 365 provisioning and Windows Backup/Restore.
Use Autopilot as the center of the Windows deployment lab.
Phase five: learn configuration profiles by platform
Practice Settings Catalog, ADMX import, Group Policy analytics, Android/iOS/macOS profiles, specialty devices, filters and enrollment-time grouping.
Focus on targeting and conflict as much as on the setting itself.
Phase six: add Intune Suite operations
Study Endpoint Privilege Management, Remote Help, Enterprise App Catalog, Cloud PKI, Microsoft Tunnel for MAM and Advanced Analytics. Associate each capability with one practical support or security use case.
This prevents premium capabilities from becoming disconnected product names.
Phase seven: build endpoint security
Configure or review antivirus, firewall, BitLocker, ASR, security baselines, Defender EDR integration and App Control for Business. Onboard a test endpoint where possible and investigate harmless security events.
A Defender for Endpoint lab makes the protection domain more concrete.
Phase eight: practice update management as controlled rollout
Compare update rings, feature updates, quality updates, Autopatch, Hotpatch, Apple updates, Android FOTA and Delivery Optimization. Define pilot, broad deployment and rollback/issue handling.
Updates should be studied as service reliability plus security, not only as patch configuration.
Phase nine: deploy and protect applications
Practice Win32, LOB, Store and Microsoft 365 Apps deployment, then app protection and app configuration for managed and BYOD devices. Include installation failure troubleshooting.
The application lifecycle should make clear when data protection can exist without full device enrollment.
Finish with automation, reporting and fleet health
Use Graph/PowerShell for one safe management task, create a proactive remediation example, read Endpoint Analytics, review service health, and create a report or alert for drift or enrollment failure.
Keep one Windows test device and one conceptual mobile device throughout the study plan. Reusing the same identities, groups and assignments makes it easier to see how enrollment, configuration, compliance, security, apps and reporting build on each other rather than behaving like isolated labs.
During identity study, include one dynamic device-group rule and one scoped-admin scenario. Verify which devices enter the group and which administrator can manage them. This makes targeting and RBAC visible before you begin assigning profiles.
During enrollment study, build a matrix for corporate/personal ownership across Windows, Apple and Android. Record enrollment mechanism, user interaction, reset/wipe implications and expected management depth. That matrix becomes useful for many scenario questions.
During compliance study, test an intentionally noncompliant condition and observe both the Intune status and Conditional Access effect. This prevents a common misunderstanding: changing access policy is not the same as changing compliance evaluation.
During Autopilot study, add one failing required app to understand Enrollment Status Page behavior. Identify whether the deployment blocks and what reporting shows. This is more memorable than reading about ESP without seeing a dependency fail.
During configuration study, use one Windows Settings Catalog profile and one imported ADMX or Group Policy analytics scenario. Compare cloud-native settings with migrated legacy policy thinking. The role increasingly involves moving older management patterns into Intune.
During Intune Suite study, pick two capabilities you can lab and design the rest on paper. Focus on use case, identity/permissions, assignment, monitoring and failure behavior rather than chasing licenses for every feature.
During security study, keep preventive and detective controls separate. ASR, firewall, App Control and BitLocker reduce attack opportunity; Defender EDR and incident investigation provide evidence after suspicious behavior occurs. Both are needed for a mature endpoint program.
During update study, model a pilot ring, broad ring and exception group. Add deadlines/restarts and an issue response plan. Controlled rollout is easier to reason about when deployment groups correspond to business risk.
During application study, package or deploy one Win32 app with detection requirements and one Store/managed-app example. Create an intentional install failure and use Intune reporting to isolate the cause.
During automation study, start read-only with Microsoft Graph or PowerShell. Query devices or compliance before attempting write operations. Then add one safe remediation after you understand authentication and scope.
In the final week, solve mixed tickets: new device not enrolling, compliant device blocked, app missing, ASR conflict, update not installing, startup slow. Begin each scenario by identifying the lifecycle layer instead of searching the portal randomly.
Before exam day, verify the Microsoft study-guide date. On October 4 the July 24 skills are live, while October 27 is future English scope. Keep both sets separate so upcoming wording does not displace what your booked exam currently measures.
Add one Windows 365 session even if you cannot provision a Cloud PC. Build the provisioning chain on paper: license/user, provisioning policy, image, network connection, enrollment, configuration, apps, security and monitoring. This keeps the cloud-PC objective from becoming a memorized product name.
Add one certificate-management session covering Cloud PKI and certificate-based access. Trace issuance, trust, renewal and endpoint use. A certificate failure often presents as a network or authentication incident, so this cross-domain understanding is valuable.
Add one specialty-device review for Teams Rooms, HoloLens or Zebra so the platform breadth is not forgotten. Focus on assignment and policy concepts rather than device-specific trivia.
Use weekly mixed-review sessions that combine one deployment, one security, one app and one analytics question. The role is integrated, and the exam can describe a symptom without naming the domain that owns it.
Keep a change log of your lab. Note the profile/app/security/update change, target group, expected result and evidence. This creates a small operational record and improves troubleshooting when a later lab behaves unexpectedly.
At the end, rebuild the five weighted domains from memory and attach one real lab task to each. If a domain has no concrete example, return to practice rather than adding more passive reading.
Add one RBAC/multi-admin approval exercise during the second half of study. Create a hypothetical sensitive change and decide which administrator can propose it, who can approve it, and which devices are in scope. Governance questions become much easier when role and object scope are explicit.
Add one update-failure exercise with a real or simulated status report. Diagnose policy assignment, device eligibility, safeguard/compatibility, restart state, network/content delivery and free space before changing the ring.
Add one app-protection session focused on unmanaged devices. Compare what the organization can control inside supported apps with what remains personal. This is one of the best ways to understand Microsoft’s modern-management boundary.
Use the last review session to explain one device from purchase through retirement: identity, enrollment, deployment, configuration, security, apps, updates, support, analytics and final selective/full removal. That lifecycle covers almost the whole exam.
Keep your final notes date-stamped July 24, 2026 until the October 27 update becomes live. Microsoft publishes future objectives early, but the tested version still depends on the date you sit the exam.
Add one weekly reporting review. Pick one Intune report and ask what decision it supports: enrollment health, app deployment, compliance, update state, Endpoint Analytics, or security posture. Learning reports by decision is more useful than memorizing report names.
Add one support-escalation scenario where the device is healthy but Microsoft service health is degraded. Decide what evidence proves the issue is tenant-wide and what changes should be avoided until service recovery.
For final practice, mix one personal-device MAM case with one corporate Windows deployment case. The contrast reinforces ownership, management depth, app/data protection and remote-action decisions across the blueprint.
Add one final cross-platform review where the same business requirement—such as encryption, update control, app deployment, or secure access—is implemented differently on Windows, Apple, and Android. This reinforces the administrator’s real skill: translating one governance outcome into platform-appropriate controls rather than expecting identical settings everywhere.
Keep one final page of evidence sources—enrollment status, assignment reports, compliance, app status, update reports, security state, Endpoint Analytics, diagnostics, Graph output, and service health. Scenario practice becomes faster when you know which evidence source can answer each type of question.
Use those evidence sources deliberately in every final mock scenario.
The current Endpoint Administrator role is complete when you can move from deployment to steady-state fleet improvement without treating monitoring as an afterthought.