15 real MD-102 sample questions, each with an explanation of why every option is right or wrong. No account, no card. This is the reasoning the MD-102 tests: knowing why the tempting answer is wrong, not just spotting the right one.
The real MD-102 is Typically 40 to 60 questions questions in 100 minutes, pass mark 700 / 1000. For a domain-by-domain breakdown and a study plan, read the MD-102 study guide. The full bank has 298 questions.
lock_openFree sampleManage and Maintain Deviceshard
An organisation is comparing classic Windows Autopilot deployment profiles with Windows Autopilot device preparation policies before it rebuilds its provisioning process. Which statement correctly describes how each approach identifies the device that is about to be provisioned?
- ABoth approaches require the device hardware identity to be imported into the tenant list of Autopilot devices first, and both then deliver their settings to that device during the out-of-box experience.
- BA device preparation policy is assigned to a device group whose membership comes from imported hardware identities, while a classic deployment profile is assigned to the user who signs in during the out-of-box experience.
- CA device preparation policy identifies the device by its domain join configuration, so the device has to be joined to Active Directory before the policy applies and no registration in the tenant is required.
- DA classic deployment profile is delivered to a device that was registered as an Autopilot device in the tenant beforehand, while a device preparation policy is assigned to a user group and depends on Intune adding the provisioned device to a device group that it owns.check_circle Correct
A classic Autopilot profile finds a pre-registered device identity, while a device preparation policy is user assigned and populates its device group during provisioning. The two approaches differ at the point where device and policy meet. A deployment profile is matched to a hardware identity that already exists in the tenant, so registration is a prerequisite and an unregistered machine simply runs a normal out-of-box experience. A device preparation policy is assigned to a user group, so the policy is resolved from the account signing in, and Intune adds the machine to the device security group it owns during provisioning, which removes the registration prerequisite entirely.
Why A is wrong: It is tempting because hardware identity import is the step most administrators associate with Autopilot, and it is genuinely mandatory for a classic deployment profile. It is wrong because a device preparation policy provisions a device that was never imported, which is the main reason the newer approach exists.
Why B is wrong: It is tempting because a device preparation policy does involve a device group, so that group looks like the targeting object. It is wrong because the assignment is made to a user group and the device group is populated by Intune during provisioning, and a classic deployment profile targets registered devices rather than users.
Why C is wrong: It is tempting because hybrid scenarios do rely on a domain join configuration to complete provisioning. It is wrong because device preparation provisions a Microsoft Entra joined device and does not identify it through an on-premises domain join at all.
Why D is correct: Correct. The classic flow matches a device to a profile using the device identity already held in the tenant, so an unregistered device receives nothing. Device preparation inverts that: the signed-in user carries the policy, and Intune places the device into the security group it owns as part of provisioning.
lock_openFree sampleManage and Maintain Deviceshard
A fleet of Windows 10 devices is already managed by Intune update rings, and the team has to move those devices to a named Windows 11 version. Which statement correctly describes the division of work between an update ring and a Windows 11 feature update policy?
- AThe feature update policy names the Windows version the devices are brought to and holds them at it, while the ring cannot choose a version and its feature update deferral or pause can delay the upgrade the policy offers.check_circle Correct
- BThe update ring chooses the Windows version through its servicing channel setting, and the feature update policy exists to widen the deferral period beyond the maximum number of days that a ring will accept.
- CThe feature update policy takes over quality updates as well, so a device that receives one no longer needs to belong to an update ring for its monthly security and reliability updates.
- DAn expedited quality update policy carries the Windows 11 upgrade to the devices sooner than a ring can, and the feature update policy simply records the chosen version for reporting purposes.
A feature update policy selects and holds the Windows version, while an update ring controls timing and can delay the upgrade the policy offers. Version and timing are separate controls. The feature update policy is the object that names the Windows version a device is brought up to, and it keeps the device at that version rather than letting it advance. The update ring expresses when updates are allowed to arrive, so a feature update deferral or an active pause in the ring can hold back the very upgrade the policy is offering, which is a common reason an assigned policy appears to do nothing.
Why A is correct: Correct. Version selection lives in the feature update policy, and the ring contributes timing behaviour that can hold the offer back, which is why a deferral or a pause in the ring has to be checked when an assigned upgrade does not arrive.
Why B is wrong: It is tempting because a ring does carry servicing and deferral settings that shape when updates arrive. It is wrong because a ring expresses timing rather than a target version, and a feature update policy is not a longer deferral.
Why C is wrong: It is tempting because both objects sit together under Windows updates and look interchangeable. It is wrong because a feature update policy governs the feature version alone, and the ring remains the object that controls quality update behaviour.
Why D is wrong: It is tempting because expediting is the fastest update mechanism in Intune and the team wants speed. It is wrong because expedited policies deliver a quality update rather than a feature version, and the feature update policy is an enforcement object, not a reporting label.
lock_openFree sampleManage and Maintain Deviceshard
A Windows 11 feature update policy that names a specific Windows 11 version is assigned to a group of Windows 10 devices. A subset of those devices does not meet the Windows 11 hardware requirements. What happens to that subset, and why?
- AThe upgrade downloads and installs on them, then rolls back at the first restart, so each device returns to Windows 10 and records a failed installation against the assigned policy.
- BThey stay on Windows 10, because Windows Update still evaluates each device against the Windows 11 requirements and a policy that names a version cannot make an ineligible device eligible for it.check_circle Correct
- CIntune marks them as non-compliant as soon as the policy applies, and Windows Update then retries the upgrade on every scan until the installation eventually succeeds on each device.
- DThey upgrade successfully, because a feature update policy delivers the named version through a dedicated Intune content channel and therefore bypasses the eligibility checks that Windows Update makes.
A Windows 11 feature update policy states a target version but cannot override the eligibility evaluation that decides whether a device is offered the upgrade. A feature update policy is an instruction about which version a device should be brought to, delivered through Windows Update for Business. The decision about whether the upgrade is actually offered is still made on the device, against the published Windows 11 hardware requirements. A device that fails that evaluation is never offered the feature update, so it neither installs nor rolls back, and reporting shows it as remaining on its current version until the hardware is replaced or the device is retired.
Why A is wrong: It is tempting because a failed in-place upgrade really does roll back, and administrators have seen that behaviour with driver faults. It is wrong because an ineligible device is not offered the upgrade in the first place, so there is no installation to roll back.
Why B is correct: Correct. The policy expresses the version the organisation wants, but the eligibility evaluation on the device decides whether the upgrade is offered, so unsupported hardware remains on Windows 10 and is reported as not upgraded.
Why C is wrong: It is tempting because compliance reporting and update reporting sit close together in the console. It is wrong because a feature update policy does not set a compliance state, and retrying a scan does not create hardware that the device lacks.
Why D is wrong: It is tempting because Intune does deliver app content itself, so a parallel channel for Windows sounds reasonable. It is wrong because feature update policies work through Windows Update for Business, and the client still applies its own eligibility evaluation.
lock_openFree samplePrepare Infrastructure for Deviceshard
An Intune role assignment is created from the Help Desk Operator built-in role. The assignment lists the group HelpdeskAdmins as its members, a group named PerthDevices as its scope (groups), and the Default scope tag. What does the scope (groups) part of that assignment determine?
- AWhich users and devices the assigned administrators are permitted to apply those permissions to.check_circle Correct
- BWhich administrator accounts receive the permissions that the Help Desk Operator role carries.
- CWhich Intune objects, such as configuration profiles and apps, the assigned administrators can see.
- DWhich remote device actions, such as restart and sync, the assigned administrators are able to run.
An Intune role assignment separates who holds the role, which users and devices it reaches, and which objects the admin can see. An Intune role assignment is made of three independent parts: members, who hold the role; permissions, drawn from the role definition, which decide the actions; and scope (groups), which decides the users and devices those actions may target. Scope tags are a fourth, separate control that governs which Intune objects the administrator can view.
Why A is correct: Correct. The scope (groups) of a role assignment is the population of users and devices the assignment reaches, so the helpdesk can act only on members of PerthDevices.
Why B is wrong: Tempting because members and scope both name Microsoft Entra ID groups, so the two fields look interchangeable. The administrators who receive the permissions are the members of the assignment, which here is HelpdeskAdmins, not the scope.
Why C is wrong: Tempting because visibility really is restricted in Intune role-based access control, but that job belongs to scope tags. An administrator sees an object when a scope tag on the object matches a scope tag on the assignment.
Why D is wrong: Tempting because the helpdesk experience is built from remote actions, but the set of allowed actions comes from the permissions in the role definition. The scope decides the targets of those actions, not the actions themselves.
lock_openFree samplePrepare Infrastructure for Deviceshard
A regional support team must create and edit device compliance policies for the devices in one country, and their view of Intune must exclude the compliance policies owned by other regions. Which approach applies least privilege to that team?
- AGrant the team the Intune Administrator directory role in Microsoft Entra ID, then add the regional scope tag to each team member's user account so their view narrows.
- BCreate a custom Intune role holding only the compliance policy permissions and assign it with the regional scope tag and a scope (groups) of the regional devices.check_circle Correct
- CAssign the built-in Policy and Profile Manager role to the team with a scope (groups) of the regional devices, keeping the Default scope tag on the assignment.
- DAssign the built-in Read Only Operator role to the team with the regional scope tag, then add that same scope tag to each regional compliance policy to allow editing.
Least privilege in Intune needs a custom role for the actions, a scope group for the targets, and a scope tag for the visible objects. Roles decide what an administrator can do and scope tags decide what an administrator can see, so the two requirements need two different controls. A custom Intune role built from the compliance policy permissions satisfies the first, a regional scope tag on both the assignment and the policies satisfies the second, and a Microsoft Entra ID directory role satisfies neither because it is tenant wide.
Why A is wrong: Tempting because the directory role certainly lets them edit compliance policies. It is wrong twice over: the directory role carries unrestricted access to every Intune object, and scope tags are applied to Intune objects and role assignments, not to user accounts.
Why B is correct: Correct. The custom role limits the actions to compliance policy work, the scope (groups) limits the devices reached, and the scope tag limits the policies the team can see.
Why C is wrong: Tempting because the scope (groups) does confine the devices the team manages. The Default scope tag still exposes every policy that carries the Default tag, including the policies of other regions, so the visibility requirement fails.
Why D is wrong: Tempting because tagging the policies does make them visible to this team. A scope tag never grants a permission, so a read only role stays read only and the team cannot create or edit anything.
lock_openFree samplePrepare Infrastructure for Deviceshard
The tenant wide Windows Hello for Business setting that is evaluated when a Windows device enrols is currently disabled. A pilot group of Microsoft Entra joined devices must now use Windows Hello for Business with a six digit minimum PIN, while every device outside the pilot continues without it. Which approach meets both requirements?
- ASet the tenant wide Windows Hello for Business setting to enabled with a six digit PIN, then assign a device configuration profile to the other devices to switch it back off.
- BCreate a device compliance policy that requires a six digit Windows Hello for Business PIN, assign it to the pilot group, and leave the tenant wide setting disabled.
- CCreate an account protection policy under endpoint security that enables Windows Hello for Business, configure the six digit minimum PIN in it, and assign it to the pilot group.check_circle Correct
- DCreate an enrolment restriction that permits Windows Hello for Business for the pilot group, then re-enrol the pilot devices so the restriction is evaluated for them.
The tenant wide Windows Hello for Business setting applies at enrolment for all Windows devices; an account protection policy targets a group. Windows Hello for Business has two configuration surfaces in Intune. The tenant wide setting is evaluated during Windows enrolment and cannot be targeted at a group, so it is the wrong instrument for a pilot. An account protection policy under endpoint security is an assignable policy, which lets one group receive the feature and its PIN rules while the rest of the estate is untouched.
Why A is wrong: Tempting because it does produce a working pilot, but it inverts the requirement: the tenant wide setting applies at enrolment for every Windows device, so this turns the feature on broadly and relies on a second policy to undo it.
Why B is wrong: Tempting because compliance policies do carry password and PIN settings. A compliance policy reports whether a device meets a condition; it cannot provision a Windows Hello for Business credential or configure the PIN rules.
Why C is correct: Correct. An endpoint security account protection policy configures Windows Hello for Business through an assignable policy, so it can enable the feature and set the PIN rules for the pilot group alone.
Why D is wrong: Tempting because the tenant wide setting is itself evaluated at enrolment, which makes an enrolment control feel like the right family. Enrolment restrictions govern which platforms and device types may enrol, and carry no Windows Hello for Business settings.
lock_openFree sampleProtect Deviceshard
A Windows 11 device is enrolled in Microsoft Intune and is already onboarded to Microsoft Defender for Endpoint. A third-party antivirus product is then installed on it and registers itself with Windows as the active antivirus solution. Which statement correctly describes the resulting state of Microsoft Defender Antivirus on that device?
- AIt moves into passive mode, so real-time protection is handed to the third-party product while the built-in engine keeps receiving security intelligence updates, can still run on-demand scans, and reports what it sees to Defender for Endpoint.check_circle Correct
- BIt is switched off entirely by the third-party installation and stops scanning, so nothing Microsoft Defender Antivirus does can be observed until the third-party product is uninstalled from the device.
- CIt remains the active antivirus solution alongside the third-party product, so two real-time engines inspect the same file operations and the device is protected by both engines at once.
- DIt is uninstalled from the device by Windows as soon as another antivirus product registers, and it can be brought back solely by rebuilding the device or by repairing the operating system image.
Recognise that a third-party antivirus places Microsoft Defender Antivirus into passive mode on a Windows client onboarded to Microsoft Defender for Endpoint, not into a disabled state. The mode Microsoft Defender Antivirus falls into when another product registers as the active antivirus depends on whether the device is onboarded to Microsoft Defender for Endpoint. Onboarding keeps the built-in engine loaded in passive mode, so it continues to update, remains available for on-demand scanning and keeps feeding signal to the service, while the third-party product owns real-time protection. Without onboarding the built-in engine would instead be disabled, which is why the onboarding state, and not the presence of the third-party product alone, decides the answer.
Why A is correct: Correct. On a Windows client that is onboarded to Microsoft Defender for Endpoint, installing a third-party antivirus places Microsoft Defender Antivirus in passive mode rather than disabling it, which preserves updates, on-demand scanning and reporting while the third-party product owns real-time protection.
Why B is wrong: This is tempting because it describes what happens on a Windows client that has not been onboarded to Microsoft Defender for Endpoint, where the built-in engine does step aside completely. It is wrong here because onboarding changes that outcome, leaving the engine running in a reduced role rather than switched off.
Why C is wrong: This is tempting because layered protection sounds safer and administrators often assume both engines simply coexist. It is wrong because Windows recognises a single registered real-time antivirus solution, and running two real-time engines against the same file operations is not the supported design.
Why D is wrong: This is tempting because third-party security products often insist that competing agents be removed before installation. It is wrong because Microsoft Defender Antivirus is a built-in platform component that is not uninstalled when another product registers; its mode changes instead.
lock_openFree sampleProtect Deviceshard
An antivirus policy created in Microsoft Intune must let Microsoft Defender Antivirus hold an unknown executable at the moment a user first runs it and reach a verdict on it, so that a file no security intelligence update has yet described can be blocked before it executes. This behaviour is known as block at first sight. Which statement describes what it depends on?
- AIt depends on the device being onboarded to Microsoft Defender for Endpoint, because the verdict on an unknown file is produced by the endpoint detection and response sensor rather than by the antivirus engine on the device.
- BIt depends on cloud-delivered protection being turned on together with automatic sample submission, because the file or its metadata is passed to the cloud service for a verdict while the client holds access to it.check_circle Correct
- CIt depends on security intelligence updates being scheduled frequently enough, because the antivirus engine can act on a file at run time once a definition describing that file has been downloaded to the device.
- DIt depends on attack surface reduction rules being set to block, because an unknown executable is judged by the rule that blocks executable files that fail to meet a prevalence, age or trusted list criterion.
Understand that block at first sight is a cloud protection capability requiring cloud-delivered protection and sample submission, not a signature, sensor or attack surface reduction feature. Block at first sight works by breaking the dependency on a locally held definition. When the engine meets an executable it cannot classify, it holds access to the file and asks the cloud protection service for a verdict, submitting metadata and, where the service asks for it, the sample. That exchange is possible when cloud-delivered protection is enabled and sample submission permits the file to be sent, which is why those two antivirus policy settings are the dependency rather than update frequency or onboarding state.
Why A is wrong: This is tempting because endpoint detection and response is the part of the platform most associated with judging unfamiliar behaviour. It is wrong because block at first sight is an antivirus capability driven by the cloud protection service, and it does not require the device to be onboarded.
Why B is correct: Correct. Block at first sight is a cloud protection feature: the client suspends access to a suspicious unknown file, sends metadata and where necessary the sample itself for analysis, and acts on the verdict returned, so both cloud-delivered protection and sample submission have to be configured.
Why C is wrong: This is tempting because it describes the signature-based model that antivirus products were built on. It is wrong because it is exactly the limitation block at first sight exists to remove: a verdict is obtained live from the cloud service for a file no local definition covers.
Why D is wrong: This is tempting because that attack surface reduction rule is real and does reason about prevalence and age. It is wrong because that rule is a separate control with its own configuration, and block at first sight operates whether or not any attack surface reduction rule is enabled.
lock_openFree sampleProtect Deviceshard
Before Microsoft Intune can deliver Microsoft Defender for Endpoint onboarding to enrolled Windows devices, the service-to-service connection between Intune and Defender for Endpoint has to be turned on in the tenant. Which statement describes what turning that connection on achieves?
- AIt onboards each enrolled Windows device to Defender for Endpoint as soon as the device checks in, because the connection removes the need to assign any policy to the devices that are to be onboarded.
- BIt packages and installs the Defender for Endpoint sensor on enrolled devices as an application, because supported Windows builds do not contain the sensor and it has to be delivered before onboarding can proceed.
- CIt lets Intune obtain the tenant onboarding configuration from Defender for Endpoint so that a policy can carry it to devices, and it lets the device risk level that Defender for Endpoint calculates be read by Intune compliance policies.check_circle Correct
- DIt grants Defender for Endpoint permission to enrol devices into Intune, so a device that Defender for Endpoint discovers but Intune has no record of is enrolled automatically and becomes a managed device.
Know that the Intune to Defender for Endpoint connection supplies the onboarding configuration and the device risk signal, and does not itself onboard or enrol devices. The service-to-service connection establishes mutual trust so that the two services can exchange configuration and state. Once it is on, Intune can retrieve the tenant onboarding configuration and place it inside a policy for assignment, and it can read the risk level Defender for Endpoint holds for a device so a compliance policy can classify that risk. Neither half of that is an action against a device, which is why devices are onboarded by an assigned policy and not by the connection itself.
Why A is wrong: This is tempting because the connection is a prerequisite for onboarding and is easily read as the act of onboarding itself. It is wrong because the connection establishes trust and data exchange between the two services, and a policy still has to be created and assigned to carry onboarding to devices.
Why B is wrong: This is tempting because other platforms genuinely do need an agent installed. It is wrong for supported Windows client builds, where the sensor is part of the operating system, so nothing is installed and the connection deals with configuration and signal rather than software delivery.
Why C is correct: Correct. The connection is what makes the tenant onboarding configuration available to Intune policy and what allows the risk level held in Defender for Endpoint to be evaluated as a compliance signal, which are the two things the integration exists to provide.
Why D is wrong: This is tempting because Defender for Endpoint can carry Intune endpoint security policy to devices that Intune does not manage, which sounds similar. It is wrong because that capability configures unenrolled devices rather than enrolling them, and no connector setting creates Intune enrolment for a discovered device.
lock_openFree sampleManage and Secure Applicationsmedium
An administrator prepares a desktop application that ships as a setup executable with several supporting files, ready for deployment to Windows 11 devices with Microsoft Intune, and runs the Microsoft Win32 Content Prep Tool against the source folder. What does that tool produce, and what does it leave the administrator to define?
- AIt converts the source installer into an MSIX package so that the Windows servicing stack installs and removes the application, leaving the administrator to choose an assignment group and nothing further about the install itself.
- BIt inspects the source installer and writes the detection rules automatically from the product code that it finds, leaving the administrator to supply an install command but no rule that proves the application is present on the device.
- CIt uploads the packaged payload straight into the tenant and creates the application record there, leaving the administrator to assign groups without ever attaching a package file to an app in the Microsoft Intune admin center.
- DIt wraps the installer and its supporting files into an encrypted .intunewin package that the Intune Management Extension decrypts on the device, leaving the administrator to declare the install command, the uninstall command and the detection rules in Intune.check_circle Correct
The Win32 Content Prep Tool only builds an encrypted .intunewin package; install behaviour and detection are authored on the app record in Intune. The content prep tool takes a source folder and a named setup file and emits a single encrypted .intunewin container. The Intune Management Extension downloads that container to the device, decrypts it, extracts it to a temporary location and runs whatever install command the app record carries. Because the package is opaque, Intune learns nothing about the application from it, so the install command, the uninstall command, the requirement rules and the detection rules all have to be stated separately when the app is created.
Why A is wrong: Tempting because MSIX is a genuine modern packaging format for Windows applications and Intune can deploy MSIX line-of-business packages. Conversion to MSIX is the job of the MSIX Packaging Tool; the content prep tool changes the container, not the installer technology inside it.
Why B is wrong: Tempting because detection based on an MSI product code is a real option on a Win32 app, so it feels as though the packaging step could fill it in. The tool performs no inspection of that kind, and an app saved with no detection rule cannot report an installed state.
Why C is wrong: Tempting because the tool is run with tenant deployment in mind and the output file is useless anywhere else. The tool is an offline packager with no connection to the tenant, and the .intunewin file it writes has to be uploaded by hand when the app is added.
Why D is correct: Correct. The tool only builds and encrypts the content package. Everything that describes how the payload behaves, meaning the command line that installs it, the command line that removes it and the rule that proves it is present, is authored on the app record in Intune.
lock_openFree sampleManage and Secure Applicationsmedium
A Win32 app in Microsoft Intune can carry both requirement rules and detection rules. Which statement describes the difference between the two correctly?
- ARequirement rules are evaluated before the content is downloaded and decide whether the device is eligible for the application at all, while detection rules decide whether it is already present and are checked again once the install command has finished.check_circle Correct
- BRequirement rules decide whether the application is already installed, while detection rules decide whether the device meets the minimum operating system and processor architecture the package supports and are evaluated once when the assignment is created.
- CBoth rule sets are evaluated after the install command has finished, and a failure of either one is reported to Intune as a failed installation, so a device that cannot support the payload downloads and runs it before the mismatch is discovered.
- DRequirement rules apply to the user who receives the assignment and detection rules apply to the device, so an available assignment is filtered by requirements while a required assignment is filtered by detection rules instead.
Requirement rules gate whether a device is eligible for a Win32 app; detection rules establish whether the app is already installed. The two rule sets answer different questions at different points in the delivery sequence. The Intune Management Extension first tests the requirement rules, covering items such as architecture, minimum operating system, free disk space or a custom script result, and a device that fails them is recorded as not applicable and never downloads the content. Detection rules are then used to ask whether the application is already installed, which prevents a needless reinstall, and are run again after the install command returns so that Intune can decide whether the installation genuinely succeeded.
Why A is correct: Correct. Requirements gate eligibility and run first, so unsuitable devices never pull the package, and detection answers the separate question of whether the application is on the device, which is also how the install result is judged.
Why B is wrong: Tempting because both rule types are authored on the same app and use similar building blocks such as files, registry values and scripts. The two roles are the wrong way round here, and neither rule type is evaluated once at assignment time; the client re-evaluates them on its own cycle.
Why C is wrong: Tempting because a failed detection really does surface as a failed installation in the app report. Requirements are checked first, precisely so that an ineligible device never downloads the content, and such a device is reported as not applicable rather than failed.
Why D is wrong: Tempting because assignment intent and rule evaluation both shape what a user ends up with. Both rule types are evaluated on the device by the Intune Management Extension for either intent, and neither is bound to the user side of the assignment.
lock_openFree sampleManage and Secure Applicationsmedium
An organisation buys iPad applications in volume through Apple Business Manager and deploys them with Microsoft Intune using device licensing rather than user licensing. Which statement about device-assigned volume purchased licences is correct?
- AThe user is sent an invitation that has to be accepted in the Company Portal before the first install, and the licence then follows that person onto every enrolled device they sign in to with the same account.
- BThe licence is consumed by the device itself, so the application installs without the user signing in with an Apple Account, and the licence returns to the pool when the application is removed from that device.check_circle Correct
- CDevice licensing is available for titles that cost nothing to buy, while a paid title has to be assigned to a user account that already holds a licence for it before any install can begin on the hardware.
- DDevice licensing removes the need to upload a token from Apple Business Manager and keep it synchronised with the tenant, because the licence state is read directly from the store each time an install starts on the device.
A device-assigned volume purchased licence belongs to the hardware, installs without an Apple Account, and is reclaimed when the app is removed. Volume purchased applications reach Intune through a token uploaded from Apple Business Manager, and each purchased title can be assigned by user or by device. Device assignment attaches the entitlement to the enrolled hardware, so the install proceeds without an Apple Account being present and without an invitation being accepted, which is what makes shared and kiosk iPads workable. When the application is removed from that device, the entitlement goes back to the available pool for reuse elsewhere.
Why A is wrong: Tempting because this is an accurate description of the other licensing model, user licensing, which many tenants used first. Device licensing exists precisely to remove the invitation step and the dependency on a personal account.
Why B is correct: Correct. Device licensing binds the entitlement to the hardware, which is what allows a shared or user-less iPad to receive the title silently, and reclaiming the licence on removal is what keeps the purchased pool usable.
Why C is wrong: Tempting because free applications are the easiest case to reason about and are commonly deployed this way. Price has no bearing on the licensing model, and paid titles bought in volume are routinely assigned to devices.
Why D is wrong: Tempting because the device appears to deal with the store on its own once the title is assigned. The token is what proves the tenant owns the purchases, and without a valid synchronised token neither licensing model can assign a volume purchased title.
lock_openFree sampleOptimize Endpoint Operations by Using Automation, Monitoring, and Reportingmedium
Windows 11 devices enrolled in Microsoft Intune run an in-house agent that records its build number in a registry value. No built-in Intune compliance setting reads that value, and the security team requires that a device carrying a build below the approved minimum is reported as non-compliant and that the person using it is shown an explanation in the Company Portal. Select TWO items you must author and add to Intune to extend compliance in that way.
- AA PowerShell discovery script, uploaded to the compliance scripts area of Intune, that reads the registry value on the device and writes the result it finds to its output.check_circle Correct
- BAn Endpoint Analytics remediation script pair, made up of a detection script and a remediation script, assigned to the same group of Windows devices that runs the in-house agent.
- CA JSON file of detection rules, attached to the custom compliance setting of a Windows compliance policy, that states the comparison to make and the message to show the user.check_circle Correct
- DA Win32 app detection rule that reads the same registry value, added to the Intune app that installs the in-house agent on each of the Windows devices in scope.
- EA device configuration profile that writes the approved minimum build number into the registry of each Windows device before the compliance policy is next evaluated.
Extending Intune device compliance to a value no built-in setting reads takes both a PowerShell discovery script and a JSON detection rules file. A custom compliance setting is deliberately split in two. The uploaded PowerShell discovery script executes on the enrolled device through the Intune management extension and reports the values it reads, while the JSON detection rules file attached to the Windows compliance policy declares how each reported value is compared and what the user is told when the comparison fails. Neither half produces a compliance verdict on its own.
Why A is correct: A custom compliance setting has no way to read an arbitrary registry value on its own, so the discovery script is the component that runs on the device and reports the value back for evaluation.
Why B is wrong: Remediations do run a detection script on the device and are a reasonable place to look, but their results are reported as remediation output and do not contribute to the compliance state a compliance policy publishes.
Why C is correct: The JSON file is what turns a value the script reported into a compliant or non-compliant verdict, and it carries the remediation strings that the Company Portal presents to the user.
Why D is wrong: A Win32 detection rule can certainly read a registry value, but it decides whether Intune considers that app installed, so it reports an app installation state rather than a device compliance state.
Why E is wrong: This is the common confusion between configuring a device and evaluating it, and writing the approved value onto the device would destroy the evidence the compliance check is supposed to read.
lock_openFree sampleOptimize Endpoint Operations by Using Automation, Monitoring, and Reportingmedium
A scheduled task on a server runs a Microsoft Graph script every night to read the enrolled Windows devices in a tenant and write an inventory file. Nobody is signed in to the server while the task runs, and no interactive sign-in prompt may appear at any point. Which statement correctly describes the permission type the app registration behind that script has to use?
- AApplication permissions, because a token issued through the client credentials flow carries the rights granted to the application itself and requires no signed-in user at any stage.check_circle Correct
- BDelegated permissions, because the script obtains a token on behalf of the account that owns the scheduled task and inherits the Intune rights held by that account.
- CDelegated permissions for which an administrator has granted tenant wide consent, because that consent removes the requirement for a user to be present when the script runs.
- DApplication permissions, which still need a user to complete one interactive sign-in first so that a refresh token can be stored on the server for every later run.
An unattended Microsoft Graph script needs application permissions and the client credentials flow, because delegated permissions require a signed-in user. Microsoft Graph distinguishes delegated access, where the token represents an application acting for a signed-in user, from application access, where the token represents the application on its own. A job with nobody at the keyboard cannot produce a user context, so it authenticates with its own credential through the client credentials flow and is granted application permissions on the app registration.
Why A is correct: Correct: application permissions are the app-only model, and the client credentials flow exchanges the application's own credential for a token, which is what an unattended job needs.
Why B is wrong: Tempting because a scheduled task does run under an account, but a delegated permission grants access only while the application acts for a user who has signed in, and no sign-in happens here.
Why C is wrong: Tempting because tenant wide consent does remove the individual consent prompt, but it only pre-approves the permission; a delegated call still needs a signed-in user in the token request.
Why D is wrong: Tempting because refresh tokens are how many scripts avoid repeated prompts, but that pattern belongs to delegated access; an app-only token is requested fresh from the application credential.
lock_openFree sampleOptimize Endpoint Operations by Using Automation, Monitoring, and Reportingmedium
You are writing the PowerShell discovery script for a custom compliance setting that will be evaluated on Windows 11 devices enrolled in Microsoft Intune. The script reads two values from the device, and the Windows compliance policy has to compare both of them against approved values. Select TWO requirements that the output of that script must meet.
- AIt must finish with exit code 0 when the device meets the approved values and with a non-zero exit code when the device fails to meet one of them.
- BIt must write a single JSON hash table of key and value pairs to its output, holding one entry for each of the values that the compliance policy compares.check_circle Correct
- CIt must write one line of plain text for each value that it reads, ordered so that the lines match the order the settings appear in the detection rules file.
- DEach key that it emits must match, exactly, a setting name that is declared in the JSON detection rules file attached to the Windows compliance policy.check_circle Correct
- EIt must correct any value that it finds below the approved level before writing its output, so that the device is reported as compliant at the next evaluation.
A compliance discovery script reports values as one JSON object whose keys match the setting names declared in the detection rules file. Intune reads the output stream of the discovery script and parses it as a single JSON object of key and value pairs. Each key is then looked up by name against the setting names declared in the JSON detection rules file so that the matching rule can compare the reported value. Output that is not valid JSON, or a key with no matching setting name, leaves the custom compliance setting without a value to evaluate.
Why A is wrong: Exit codes are how an Endpoint Analytics detection script signals its result, so the habit transfers easily, but a compliance discovery script is judged on the values it reports rather than on the code it exits with.
Why B is correct: Intune parses the output of the discovery script as one JSON object, so both readings have to leave the device as key and value pairs inside that single structure for the policy to evaluate them.
Why C is wrong: Ordered plain text feels like a natural way to hand back two readings, but Intune matches reported values by name rather than by position and cannot parse output that is not valid JSON.
Why D is correct: The rules file addresses each reported value by its setting name, so a key that does not match a declared setting name leaves that rule with nothing to compare and the check does not evaluate.
Why E is wrong: Fixing the device sounds efficient and is what a remediation script is for, but a discovery script that changes the value it measures would report a faulty device as compliant and hide the fault.
Examworthy is not affiliated with or endorsed by Microsoft. All questions are original, blueprint-aligned practice material. We never reproduce live exam items. MD-102 and related marks belong to their respective owners.
