Deploy and manage a Microsoft 365 tenant →hardMultiple Choice

MS-102 Deploy and manage a Microsoft 365 tenant Practice Question

Exhibit

Refer to the exhibit.

```json
{
  "conditions": {
    "applications": {
      "includeApplications": ["Office365"]
    },
    "users": {
      "includeUsers": ["All"]
    },
    "locations": {
      "includeLocations": ["All"]
    }
  },
  "grantControls": {
    "builtInControls": ["mfa", "compliantDevice"]
  },
  "sessionControls": {
    "applicationEnforcedRestrictions": null,
    "cloudAppSecurity": {
      "cloudAppSecurityType": "monitorOnly"
    }
  }
}
```

You are reviewing a Conditional Access policy in Microsoft Entra ID. The exhibit shows the policy configuration. You need to allow users to access Office 365 applications from personal devices that are not enrolled in Microsoft Intune. However, the policy currently blocks access because it requires a compliant device. Users are prompted for MFA but then blocked due to device compliance. What should you modify in the policy?

⚠ Common exam trap

Candidates often confuse session controls (like app enforcement or sign-in frequency) with grant controls (like device compliance), leading them to incorrectly modify session settings instead of removing the device compliance requirement.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Remove "compliantDevice" from the builtInControls grant control list.

The policy currently uses the 'Require compliant device' grant control, which blocks access from devices not enrolled in Intune or not meeting compliance policies. Removing 'compliantDevice' from the builtInControls list allows access from personal, non-enrolled devices while still enforcing MFA. This directly resolves the scenario where users pass MFA but are blocked by device compliance.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Add a session control for sign-in frequency.
Why it's wrong here
Sign-in frequency sets how often users must reauthenticate; it adds a session requirement rather than relaxing the compliant-device grant, so the block persists. It is the right control for enforcing periodic reauthentication on sensitive apps or admin portals.
✓
Remove "compliantDevice" from the builtInControls grant control list.
Why this is correct
Removing compliantDevice from the grant controls leaves MFA as the only requirement, so personal unenrolled devices satisfy the policy. The block stems solely from the device compliance grant, not from the MFA prompt, so deleting that control restores access without altering assignment scope.
✗
Remove the cloudAppSecurity session control.
Why it's wrong here
Cloud app security session controls govern in-session actions like download blocking, not device compliance; removing one leaves the compliant-device grant untouched, so users remain blocked. It is the correct control when you want to restrict downloads or monitor sessions on unmanaged devices.
✗
Change cloudAppSecurityType to "blockDownloads".
Why it's wrong here
BlockDownloads is a session control applied after access is granted; it cannot override the compliant-device grant that is denying access. It is the correct choice when you want unmanaged devices to view but not download Office 365 content, paired with a permissive grant.

Visual reference

Go deeper

MS-102 Deploy and manage a Microsoft 365 tenant Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question