Mastering Identity and compliance for Microsoft MD-102 Endpoint Administrator: What Candidates Need to Understand

 

Identity and compliance are often taught as separate MD-102 topics, but endpoint administration makes more sense when you treat them as one control chain. Identity establishes who or what is asking for access, Intune management supplies device state, compliance evaluates that state against policy, and Microsoft Entra Conditional Access decides whether the resulting signals are sufficient for a protected resource. The exam can test any individual layer, but the harder questions usually ask you to identify which layer should make the decision.

Microsoft’s current MD-102 blueprint explicitly includes Intune roles, scope tags, scoped administration, multi-admin approval, device compliance policies across supported platforms, and Conditional Access policies that require a compliant device. That means preparation cannot stop at memorizing where a setting appears in the portal. Candidates need to understand authority boundaries, signal flow, evaluation timing, exception design, and how to troubleshoot a result without changing the wrong control.

If you first need a broader picture of what the endpoint role now covers, ExamSnap’s overview of the evolving MD-102 exam is useful context. This article goes deeper into the identity-and-compliance decisions that tend to separate a memorized answer from an operationally sound one.

Start with a four-layer control model

Identity and compliance questions become easier when you separate four layers. The first layer is identity: the user, device object, group membership, authentication context, and Microsoft Entra registration or join state. The second layer is administrative authority: which administrator is permitted to view or change which Intune resources. The third layer is posture: what Intune knows about the managed endpoint and whether its configuration satisfies a compliance policy. The fourth layer is access enforcement: what Conditional Access does with identity, device, risk, platform, location, and application signals at sign-in.

These layers interact, but they are not interchangeable. A user can authenticate successfully while the device is noncompliant. A device can be compliant while the user lacks permission to a resource. An Intune administrator can have permission to create a compliance policy but still be unable to see another region’s policy because of scope tags. A Conditional Access rule can block access even though Intune reports the device as healthy because the sign-in does not present the expected device identity.

For exam scenarios, ask two questions before choosing a feature: what is the decision being made, and which service owns that decision? If the question is who may modify a configuration profile, think RBAC. If it is which regional objects an administrator can see, think scope tags. If it is whether a device satisfies security requirements, think compliance. If it is whether the sign-in receives access after those requirements are evaluated, think Conditional Access.

Separate Microsoft Entra device identity from Intune management

A Microsoft Entra device object and an Intune managed-device record describe related but different things. The Entra object participates in identity and access decisions. The Intune record represents management state, configuration, inventory, compliance, actions, and reporting. Enrollment commonly links the two, but troubleshooting requires you to confirm both instead of assuming one proves the other.

This distinction matters when a user can sign in to Windows and the device appears in Entra but compliance remains unknown or unavailable. The identity path may have succeeded while Intune enrollment, check-in, or compliance evaluation failed. Conversely, a device can be managed in Intune but a browser or application session might not present the device identity that Conditional Access needs. The symptom appears to be ‘compliance is wrong,’ but the real failure can be upstream identity presentation.

The same reasoning applies to personally owned mobile devices. Registration can establish a device identity, while Intune enrollment or app protection establishes a management boundary. The correct design depends on the platform, ownership model, and access requirement; the existence of an identity object alone does not tell you which management model is appropriate.

Treat Intune RBAC as a least-privilege design problem

Role-based access control answers what an administrator can do. Built-in Intune roles provide predefined permission sets, while custom roles allow more precise combinations of permissions. A strong design starts with the smallest set of actions the administrator needs and then limits the population and objects to which those actions apply. Assigning a broad Microsoft Entra administrative role just because it is convenient can bypass the finer Intune delegation model and undermines the purpose of scoped administration.

An Intune role assignment brings several ideas together. The member or admin group identifies who receives the role. Scope groups identify which users and devices those administrators can manage with the granted permissions. Scope tags limit visibility to tagged Intune objects. Candidates often collapse scope groups and scope tags into one concept, but they solve different problems: scope groups constrain the managed population; scope tags constrain the visible administrative objects.

Imagine a regional support team that should manage laptops for the London office and see only London’s configuration profiles. The role permissions define the actions, such as read or update. A London users/devices group can define the population. A London scope tag can be attached to relevant policies, apps, and devices so those objects are visible in that delegated context. Correct answers usually combine these dimensions rather than expecting one setting to perform all three jobs.

Understand scope tags without overestimating them

Scope tags are a visibility and delegation mechanism, not a device configuration feature. Adding a scope tag does not deploy a policy, change compliance, or alter a user’s license. It changes which tagged objects an appropriately scoped administrator can see and work with. The exam can exploit this by describing an administrator who has the right role but cannot find an object; the missing piece may be a matching scope tag rather than another permission.

Microsoft also distinguishes scope-tag behavior from Microsoft Entra roles. Intune RBAC and its tags do not restrict a highly privileged Entra role in the same way. In a real environment, that is a governance reason to avoid assigning broad tenant roles to operators who only need delegated endpoint duties. In an exam scenario, it is a clue: if a user holds a tenant-wide administrative role, changing an Intune scope tag may not create the isolation the question requires.

There is an additional 2026 nuance for candidates who work with complex delegation. Microsoft introduced an opt-in scoped-permissions behavior that changes how permissions from multiple role assignments are combined across scope tags. The classic behavior can merge permissions more broadly than administrators expect; the newer scoped-permissions model keeps permissions tied more precisely to their scope-tag context. The exam is more likely to test the underlying principle than the preview toggle: understand the effective permission result when several assignments overlap.

Use multi-admin approval for high-impact change control

Multi Admin Approval adds separation of duties to sensitive Intune changes. Instead of allowing one authorized administrator to make a protected change immediately, an access policy can require a second administrator to approve the request. The requestor cannot approve their own request, even if they belong to an approver group. This is not a replacement for RBAC; the requestor still needs permission for the underlying action.

Current Intune capabilities can protect categories such as apps, compliance policies, settings-catalog configuration policies, destructive device actions, role-based access control changes, Windows scripts, and selected tenant configuration changes. The practical value is risk reduction: a compromised or mistaken privileged account should not be able to make certain high-impact changes alone.

The workflow matters. The requestor submits the protected change with justification. A separate qualified approver reviews and approves or rejects it. For an approved request, the original requestor completes the change so Intune can apply it. If the scenario says an administrator has the correct RBAC permission but a protected change remains pending, granting a stronger role is not the fix; the missing step is in the approval workflow.

Automation is not automatically exempt. Microsoft applies Multi Admin Approval to protected Microsoft Graph application-authenticated calls as well as interactive delegated actions, unless a permitted enterprise-application exclusion has been deliberately configured for that access policy. That is important operationally because governance should not disappear when an organization moves from portal clicks to scripts or service principals.

Build compliance policies around measurable posture

A compliance policy evaluates whether a managed device meets stated requirements. The available settings differ by platform, but common categories include operating-system requirements, password or device-lock conditions, encryption, security health, threat level, and other platform-specific posture signals. The result is a compliance state that Intune can report to Microsoft Entra and use in access decisions.

Compliance is deliberately separate from configuration. A configuration profile can attempt to set a control, while a compliance policy evaluates whether the endpoint meets a requirement. Sometimes the two align: you deploy a required security setting and also check that the device satisfies the corresponding posture. But one does not automatically replace the other. A device may fail to apply a configuration and become noncompliant; it may also become noncompliant because of a state that no configuration profile should silently remediate.

This separation produces useful troubleshooting information. If the device is correctly configured but compliance is stale, investigate check-in, evaluation timing, or policy applicability. If the compliance rule evaluates a condition that configuration never targeted, the failure is expected. If Conditional Access blocks the device even after remediation, verify that the refreshed compliance result reached Microsoft Entra before changing the access policy.

Know the tenant-wide compliance settings that change interpretation

Intune has tenant-level compliance settings that influence how device state is interpreted. One especially important setting controls devices that have no compliance policy assigned. Treating such devices as compliant creates a very different security posture from treating them as noncompliant. In environments that use compliance as a Conditional Access gate, administrators should understand this setting because ‘no policy’ and ‘passed policy’ are not conceptually the same thing.

Another setting is the compliance status validity period. A device must report successfully within the configured period or can become noncompliant because its posture information is too old. This prevents a once-compliant endpoint from retaining a trusted state indefinitely while it stops communicating with management. In a scenario where a device was compliant, then disappeared for an extended period, the correct explanation may be status freshness rather than a newly failed configuration.

These controls illustrate a broader exam lesson: device compliance is a time-sensitive evaluation, not a permanent badge. Always ask when the device last checked in, which policies were assigned, whether evaluation has completed, and whether the access attempt occurred after the updated result propagated.

Actions for noncompliance are workflow controls, not Conditional Access

Every compliance policy includes an action that marks a failing device noncompliant. Additional actions can notify users, introduce grace periods, or perform other supported responses depending on platform and policy. The schedule of an action controls when that response occurs after noncompliance is detected.

Do not confuse these actions with Microsoft Entra access enforcement. Intune decides and reports compliance; Conditional Access can consume that signal and grant or block resource access. You can therefore design a grace period in one layer and an access requirement in another, but you must understand how those settings interact. A poorly aligned design can block a user immediately even though an administrator believed a notification grace period existed.

Exam questions often reveal the correct layer through verbs. ‘Notify’ or ‘mark noncompliant’ points toward Intune compliance actions. ‘Require compliant device to access Exchange or Microsoft 365’ points toward Conditional Access. ‘Remediate the setting’ points toward configuration or endpoint security policy. Choosing the correct verb-to-control mapping prevents many distractor errors.

Conditional Access is the enforcement engine

Microsoft Entra Conditional Access evaluates signals at access time. It can use user identity, resource, device platform, location, risk, client context, and device compliance, then apply grant or block controls. When an organization selects the grant control that requires the device to be marked compliant, Microsoft Entra uses the compliance result supplied by Intune as part of the access decision.

This architecture means a compliance policy alone does not protect a cloud resource. Without an access policy consuming the signal, Intune can report that a device is noncompliant without automatically denying every sign-in. The reverse is also important: a Conditional Access policy that requires compliance depends on Intune having an applicable compliance policy and a usable device signal. Designing only one half of the chain creates gaps.

A safe rollout normally uses exclusions for emergency-access accounts and validation in report-only mode before broad enforcement. This is not merely administrative caution; it reflects the blast radius of identity controls. If a scenario asks how to introduce a new all-user compliance requirement without risking tenant lockout, the strongest answer includes staged validation and protected recovery paths rather than turning the policy on globally in one step.

Read Conditional Access scenarios as signal-and-control combinations

A Conditional Access policy has scope and conditions before it has a grant control. Scope identifies users or workloads and target resources. Conditions refine when the policy applies, such as platform or location. The grant controls state what must be true for access. When troubleshooting, confirm the policy actually applied before deciding that compliance itself is wrong.

For example, a compliant Windows device can still be blocked if another required control fails. A policy might require both a compliant device and multifactor authentication, or it may block a particular risk condition. The word ‘compliant’ in the sign-in details is therefore not enough to conclude the policy should grant access. Evaluate every applicable policy and every grant requirement.

Similarly, an apparently noncompliant browser session may reflect missing device identity rather than a failing device posture. Some browser and platform combinations require a mechanism that lets Entra associate the session with the registered device. When that signal is absent, troubleshooting should start with sign-in and device-identity evidence, not by weakening the compliance policy.

Scenario 1: The regional Intune admin can manage too much

A company delegates endpoint administration to North America and Europe teams. A Europe operator should update European configuration profiles and manage only European users and devices. The operator receives a custom role with the correct configuration permissions, but after another role assignment is added, the operator can see or modify more resources than expected.

Start by separating permission from scope. Review every role assignment, its admin members, scope groups, and scope tags. Multiple assignments can combine permissions in ways that broaden effective rights, especially under the traditional merged-permission behavior. The solution is not to remove all useful permissions; it is to redesign assignments so each duty has the intended population and visibility, and to understand whether the tenant uses the newer scoped-permissions behavior.

The exam lesson is that effective authorization is the sum of assignments, not the label on one role. When a scenario says an admin ‘already has a least-privilege custom role’ but still has excessive access, inspect overlapping assignments and scopes before editing the custom role itself.

Scenario 2: A critical compliance change waits for another admin

An endpoint administrator with permission to edit compliance policies changes the minimum operating-system requirement. The portal records the request, but the policy does not immediately update. The administrator tries again and considers requesting a higher privilege role.

If Multi Admin Approval protects compliance policies, the behavior is expected. The administrator has authority to request the change, but a separate approver must authorize it. After approval, the original requestor completes the change. A stronger role does not bypass the workflow; even highly privileged administrative accounts remain subject to a protected resource’s approval requirement.

This scenario tests governance rather than technical inability. Look for evidence such as a pending request, business justification, an approver group, or a protected resource category. Those clues distinguish MAA from ordinary RBAC denial.

Scenario 3: The device is configured correctly but still shows noncompliant

A Windows laptop receives the expected security profile and the local settings appear correct. Intune still reports the device as noncompliant, and Conditional Access blocks Microsoft 365. Reinstalling the profile is tempting because the symptom sounds like configuration failure.

Instead, inspect the compliance rule that is failing, the device’s last check-in, policy assignment, status validity, and per-setting evidence. The compliance policy might be evaluating a different property than the configuration profile, or the device may not have reported a fresh state since remediation. If the setting now passes locally, synchronize the device and allow evaluation to update before concluding that Conditional Access is broken.

This is where the enrollment-and-configuration foundation matters. If you need to review how management state, assignment, and configuration delivery fit together before compliance is evaluated, the device enrollment and configuration deep dive provides that upstream model.

Scenario 4: New devices are blocked even though no compliance rule fails

An organization creates a Conditional Access policy requiring compliant devices for a sensitive application. Existing managed devices work, but newly enrolled endpoints are denied before administrators see a clear failed compliance setting. The immediate impulse is to lower the security requirements.

Check whether the new devices actually have an applicable compliance policy and whether the tenant treats devices with no assigned compliance policy as noncompliant. Also confirm that enrollment and initial check-in have completed. A correctly designed policy can intentionally deny access during the interval before a device has established a trusted posture.

The safer response is to repair assignment or onboarding sequencing rather than change the access requirement. If the business needs a staged rollout, use deliberate pilot groups or report-only validation instead of making ‘unknown’ equivalent to trusted across the tenant.

Scenario 5: A compliant device is blocked in one browser but not another

A managed laptop reports compliant in Intune. A user accesses a cloud resource successfully through the expected managed browser, but another browser session is blocked by a Conditional Access policy requiring a compliant device. Nothing changed in the Intune policy.

The key is that access enforcement evaluates the sign-in session, not just the inventory record. Determine whether the failing client presented a device identity that Microsoft Entra could associate with the compliant record. Inspect sign-in logs and Conditional Access details to see which condition or grant control failed.

This is a classic boundary problem: Intune can know the endpoint is compliant while the access request fails to carry the evidence needed to use that status. The correct fix preserves the compliance requirement and restores the supported identity signal rather than excluding the application broadly.

Troubleshoot identity and compliance in a fixed sequence

Start with identity and scope. Confirm the user, device object, registration or join state, group membership, license, and target resource. Next check policy applicability: which compliance and Conditional Access policies should apply to this user, device, platform, and resource? Then verify device management health and the freshness of Intune check-in.

After that, inspect the exact compliance result rather than the summary icon. Identify the failing setting, error state, grace period, or stale status. Then inspect Microsoft Entra sign-in evidence to determine which Conditional Access policies applied and which grant control failed. Finally, examine administrative governance such as RBAC, scope tags, or Multi Admin Approval only when the symptom concerns the ability to change the policy rather than the endpoint’s evaluation.

This sequence avoids destructive troubleshooting. Wiping or reenrolling a healthy device does not fix an admin scope error. Changing a compliance threshold does not fix a browser that fails to present device identity. Granting Global Administrator does not satisfy a second-person approval requirement. The strongest operational answer changes the layer that actually failed.

Design a lab that makes invisible boundaries visible

A useful lab needs at least two users, two administrative personas, and several device states. Give one administrator broad endpoint permissions and a second a scoped custom role. Create separate scope groups and a scope tag, then observe which users, devices, and policies each administrator can see. This makes the difference between permissions, population, and object visibility concrete.

Create a simple compliance policy and deliberately cause one device to fail a requirement. Observe the device-level setting status, the noncompliant result, and the timing of refresh. Then create or use a Conditional Access test policy in report-only mode that requires a compliant device. Compare sign-in results from compliant, noncompliant, and not-yet-evaluated states.

If your lab tenant supports it, study Multi Admin Approval with two administrator accounts and a protected resource that is safe to test. Watch the request, approval, and completion states. The goal is not memorizing portal labels; it is learning the state machine so an exam question that describes ‘authorized but waiting for approval’ is immediately distinguishable from ‘not authorized.’

Convert wrong answers into architecture lessons

Identity-and-compliance distractors often use a real Microsoft feature at the wrong layer. A question about who can see an Intune policy offers a compliance answer. A question about blocking resource access offers an enrollment restriction. A question about approving an admin change offers a Conditional Access role. Reject these by naming the decision owner before considering individual settings.

For every missed scenario, write a short chain: identity signal, management state, compliance evaluation, access enforcement, administrative authority. Mark the exact link where your reasoning failed. This produces a more useful study plan than simply recording ‘missed compliance question’ because it tells you whether the weakness is RBAC, device state, policy evaluation, or access control.

When you want to test this reasoning under exam conditions, MD-102 practice questions are useful only if you review why each option belongs to the correct or incorrect control layer. Treat the questions as decision drills, not as a substitute for understanding the architecture.

Recognize operational patterns that the exam can compress into one sentence

Some of the hardest scenarios are difficult because the prompt compresses a long administrative history into a small symptom. A device might be described as newly noncompliant after a policy migration, an administrator might suddenly see additional objects after joining a second group, or a previously successful automation might begin generating approval requests. Do not treat those changes as random. Ask what control boundary changed immediately before the symptom. A new role assignment changes effective authorization; a new scope tag changes visibility; an access policy changes the administrative workflow; a new compliance assignment changes the posture evaluation; and a new Conditional Access policy changes what happens at sign-in. That change-oriented reading often eliminates several technically plausible answers before you need to remember a portal path.

Also distinguish intended denial from malfunction. Security systems are designed to deny access under some conditions. If an unmanaged or unevaluated endpoint is blocked from a sensitive application, the first question is whether that is the desired policy outcome, not how to bypass it. If an administrator must wait for a second approver, that delay can be the governance control working correctly. If a regional operator cannot see a policy tagged for another region, the invisibility can be the delegation design working correctly. MD-102 questions frequently reward administrators who preserve the control objective while repairing the workflow around it.

Finally, prefer evidence that names the failed layer. Intune per-setting compliance status is stronger evidence than a user’s statement that the laptop ‘looks secure.’ Microsoft Entra sign-in and Conditional Access details are stronger evidence than assuming a cloud application is down. Effective role assignments and scope information are stronger evidence than the friendly name of one custom role. Approval-request state is stronger evidence than repeatedly resubmitting a protected change. A disciplined endpoint administrator moves from symptom to authoritative evidence, identifies the owning service, and changes the smallest control necessary to restore the intended state.

Final readiness checklist for identity and compliance

You should be able to explain the difference between Intune RBAC permissions, scope groups, and scope tags; explain how overlapping role assignments affect effective administration; and describe why a Microsoft Entra administrative role is not identical to a scoped Intune role. You should also understand the purpose of Multi Admin Approval, why the requestor cannot self-approve, and why automation can still be subject to approval controls.

For compliance, you should be able to distinguish configuration from evaluation, explain what happens when a device has no compliance policy, reason about status freshness, and describe how actions for noncompliance differ from access enforcement. You should be comfortable tracing a failing device from local posture through Intune reporting into Microsoft Entra.

For Conditional Access, you should be able to identify policy scope, conditions, and grant controls; explain why ‘device is compliant’ does not guarantee every sign-in succeeds; and recognize when a missing device identity signal makes a healthy endpoint appear unusable to an access policy. You should also know why report-only rollout and emergency-access exclusions are governance safeguards rather than optional niceties.

Most importantly, be able to preserve boundaries. Identity proves who or what is present. RBAC governs administrators. Scope constrains delegated administration. Intune compliance evaluates endpoint posture. Conditional Access enforces resource access. Multi Admin Approval governs sensitive changes. Once those responsibilities are clear, MD-102 identity-and-compliance scenarios become a chain of observable decisions rather than a collection of similar-looking portal settings.