MD-102: Making Endpoint Compliance Policies Work

An employee’s laptop reports that encryption is enabled. Intune marks it noncompliant anyway, and the user is unable to open a business application after a Conditional Access policy takes effect. Another laptop has the same configuration profile but retains access. This is not necessarily an Intune bug. It is a reminder that configuration, compliance evaluation, device identity, and access enforcement are separate systems with different evidence and timing. The MD-102 exam tests the ability to work across those systems without confusing a desired state with an observed result.

The current Microsoft endpoint blueprint includes platform-specific configuration profiles, settings catalogs, enrollment-time grouping, dynamic groups, assignment filters, custom administrative roles, compliance policies, and Entra Conditional Access requirements. Those features need a coherent operating model. It should answer which devices are covered, what each one must satisfy, how that state is measured, who can change the rule, and how a blocked employee can be restored safely. A policy that looks correct in a screenshot but cannot be explained or supported is not a finished security control.

Separate configuration from compliance at the outset

Configuration profiles deliver settings such as password requirements, firewall behavior, certificates, restrictions, and platform features. Compliance policies evaluate whether an endpoint meets particular conditions, which may include operating-system requirements, encryption, passwords, or reported risk, depending on platform and feature support. The same device can receive a configuration and still fail the corresponding compliance check because the setting did not apply, a precondition is missing, the device has not reported, or the compliance rule measures a different property. This distinction matters whenever a rollout depends on a compliance signal for business access.

Think about a corporate Windows laptop whose disk encryption policy is assigned correctly but whose encryption setup was interrupted. Assignment success shows that Intune sent the intended policy; it is not proof that BitLocker completed or that the recovery-key state meets requirements. Conversely, a device might meet the compliance condition even though a particular configuration profile shows an error, because the observed condition was achieved through another mechanism. Before changing an access rule, inspect the status of the actual device property being evaluated. In a lab, deliberately create one configuration failure and one evaluation delay, and compare the messages and next steps each produces.

Target cohorts with groups and filters that mean something

Policy targeting requires discipline because an organization’s group names often conceal different assumptions. A dynamic Entra group might collect corporate Windows endpoints based on defined directory properties. An assignment filter can refine applicability for a policy using supported managed-device attributes. An enrollment-time grouping mechanism can organize early provisioning. Scope tags control what administrators can see and manage within a delegated Intune environment, complementing the wider principle of role-based access control. These concepts are not interchangeable, and using the wrong one can leave a device out of scope or apply a restrictive policy to a personal endpoint.

A clean design starts with enduring distinctions: operating system, ownership, management mode, business risk, and location or population where those materially affect a setting. Temporary distinctions, such as the first fifty pilot devices, should not become permanent foundations of the policy graph. If a company wants different BitLocker and update policies for the finance department, use reliable group membership and document how devices enter and leave that group. Test both positive and negative assignment cases. A device unintentionally receiving two conflicting restrictions can be harder to diagnose than a device receiving no profile at all because each policy may look correct independently.

Understand how compliance becomes an access decision

Microsoft Entra Conditional Access can use compliance information when deciding whether a sign-in to a cloud resource should be allowed. That is a deliberate relationship between identity and endpoint posture. An Intune compliance report by itself does not deny a user’s session; the access rule must reference the appropriate requirement and applicable conditions. The policy might also include exclusions, supported client-app conditions, sign-in risk, or an app-protection requirement. It is essential to understand whether the user is accessing from a managed device, an unmanaged device using a protected application, or a client that cannot supply the expected signal.

A practical example is an accountant using a corporate Windows laptop and an employee-owned tablet. Requiring a compliant managed device for every access path could deny the tablet even when the company intended to allow a limited protected-app experience. A different policy might be needed for that scenario, with access and data movement confined to approved applications. Study Entra Conditional Access decisions as conditions plus controls, not a universal device-security switch. The MD-102 task is to make endpoint state trustworthy and troubleshoot the client consequences; SC-300 addresses identity administration more broadly.

Build a rollout that cannot surprise the entire workforce

A new compliance requirement should move through review, pilot, and staged enforcement, particularly if it will feed access policies. Start by identifying the devices that currently fail the proposed condition and why. There may be older hardware without required capabilities, exceptional workloads, devices that report infrequently, and personally owned platforms that cannot satisfy the same settings as corporate laptops. Treat those as design inputs, not failures to be hidden by broad exclusions. Publish remediation steps and align the change window with support capacity before blocking production access.

Monitoring without enforcement can help reveal the likely impact of a future condition, but it does not replace end-to-end testing. Confirm that a compliant device can sign in, that a deliberately noncompliant device is handled as designed, that the remediation process works, and that a valid emergency access mechanism remains outside inappropriate device-policy dependencies. Avoid granting permanent exemptions because one enrollment failed. Put an owner, reason, and review date against every exception. A secure policy includes an explicit path for recovery that preserves accountability while minimizing avoidable business disruption.

Treat platform behavior as a design constraint

Windows, macOS, iOS/iPadOS, and Android offer different management capabilities, enrollment types, and reporting properties. A policy setting available on a fully managed corporate Android device may not be available in the same way to an employee-owned work profile. An iPhone enrolled through Apple Business Manager can have a different supervision and management relationship from a personal device carrying a managed productivity app. A macOS configuration may rely on profiles and permissions that do not map one-to-one to Windows policy concepts. Trying to produce a visually identical policy set across every platform can create gaps or invalid expectations.

Build a matrix of required outcomes instead: organizational information must remain protected, risky or obsolete software must be addressed, encryption is required for specified device classes, and sensitive applications are available only under approved conditions. Then map each outcome to the platform controls that actually exist, recording where coverage differs. The distinction between corporate Apple enrollment and less intrusive personal enrollment is discussed in the Apple Automated Device Enrollment context. This is not an argument for weaker personal-device security; it is a way to achieve defensible controls without claiming capabilities an enrollment mode does not offer.

Use baselines and custom settings deliberately

Settings catalog profiles, security baselines, templates, imported ADMX policy settings, and custom configuration mechanisms give administrators several ways to express requirements. Their convenience should not conceal who owns the effective setting. A baseline may configure many options at once; an additional security profile may configure one of those options differently. A legacy Group Policy may also influence a hybrid Windows deployment. The result is not necessarily a deterministic last-writer-wins choice, so an administrator must inspect conflicts and the supported precedence for the particular setting rather than relying on a universal rule.

For mature environments, design a review process for baseline revisions. Record changed settings, business exceptions, affected applications, and validation results before rolling the new baseline out. A critical application that requires an older browser component might demand a documented isolation or remediation decision rather than silently disabling a fleet-wide hardening rule. Equally, a stale imported template may contain settings that no longer make sense for current Windows clients. Good MD-102 preparation includes reading a scenario’s management history: a failure after migration from Group Policy to Intune has a different root-cause set from a newly provisioned cloud-native endpoint.

Investigate with the correct evidence, in the correct order

A blocked user often sees only an error message, but administrators can gather several classes of evidence. Sign-in records help identify the access rule and control result. Intune device records show ownership, enrollment, check-in, assigned policy and compliance status. Device-side diagnostics can clarify whether the configuration reached the machine or failed locally. Application logs can reveal whether a managed client can supply the required data-protection signal. Each source answers a different question, so avoid drawing a conclusion from a single colored status label.

A repeatable workflow begins with the exact user, device, resource, and time. Identify the access decision that failed; confirm whether the correct device identity was presented; compare the relevant compliance evaluation against the intended condition; inspect profile and enrollment state; then address the narrowest confirmed cause. For a Windows machine, operating-system telemetry can be useful, but Windows performance counters through PowerShell answer health and performance questions, not identity-policy decisions. Knowing when a tool is irrelevant saves time during an access outage.

Evaluate policy as an operational service

Successful endpoint policy is measurable over time. Track how many active devices report on schedule, which compliance conditions cause repeated failures, how many exclusions remain open, the duration of remediation, and whether the security team can correlate device posture with actual risk. Segment the results by ownership and operating system. A 98% compliance score may hide an entire high-risk kiosk fleet if its devices are not represented in the reporting population. Conversely, temporary noncompliance during staging is not automatically evidence of careless device administration.

Use one controlled end-to-end exercise to verify the design: enroll a Windows device into the intended cohort; assign a configuration; deliberately violate a measurable condition; inspect Intune’s evaluation; observe the Conditional Access result; remediate; and confirm access restores. Document the first event that changes at each stage. That walkthrough teaches more than memorizing which menu hosts a particular policy. The most transferable MD-102 skill is recognizing the difference between intended configuration, measured state, and enforced access—and proving that those layers agree when a real employee needs to work.