MS-102 Practice Questions

Device type restrictions are used in Microsoft Intune to define which devices can enroll based on specific attributes, including platform, OS version, manufacturer, and crucially, ownership type (personal or corporate). To prevent users from enrolling personal devices, an administrator would configure a device type restriction policy to block devices identified as "personally owned."

Device limit restrictions are used to set the maximum number of devices a user can enroll in Intune. This is a straightforward setting where the administrator can specify a number between 1 and 15. Setting this value to 10 directly fulfills the second requirement. Conditional access policies control access after enrollment, and device categories are for grouping and organizing devices, not restricting enrollment.

Microsoft. (2024). Create a device platform restriction in Microsoft Intune. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/mem/intune/enrollment/enrollment-restrictions-set#create-a-device-platform-restriction.

Reference Point: In the "Create the restriction" section, Step 7 ("Platform settings") details how to configure rules for platforms, including the option to "Block" personally owned devices.

Microsoft. (2024). Set device limit restrictions. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/mem/intune/enrollment/enrollment-restrictions-set#set-device-limit-restrictions.

Reference Point: The document explicitly states, "As an Intune administrator, you can create a device limit restriction to limit the number of devices that a user can enroll." It details the process of setting the "Device limit" value.

To meet the principle of least privilege:

1. View BitLocker recovery keys: The Helpdesk Administrator role is the least privileged built-in role listed that grants permission to read BitLocker recovery keys. This role is designed for support staff who need to help users regain access, without granting them broader device management permissions (like deleting devices, which the Cloud Device Administrator can do).
2. Configure usage location: The License Administrator role allows a user to assign, remove, and update license assignments. A user's usageLocation property is a prerequisite for assigning a license. Therefore, this role includes the necessary permissions to set or update this specific user attribute.

Microsoft Entra ID Documentation (learn.microsoft.com). "Microsoft Entra built-in roles."

Role: Helpdesk Administrator. Section: "Role description."

This official documentation explicitly states that users with the Helpdesk Administrator role can "read BitLocker recovery keys." This is a more limited and thus less privileged role for this task than Cloud Device Administrator or Global Administrator.

Role: License Administrator. Section: "Role description."

This documentation details that the License Administrator can "assign, remove, and update license assignments on users." The "usage location" is a core user property that must be set to assign licenses, and this role is granted the specific permissions to modify it as part of its function.

User1 can add Exchange email as a location to Policy1: No. User1 is in the Compliance Data Administrator role group. According to official Microsoft documentation, this role group does not include the Retention Management role, which is required to create, delete, or modify retention policies. This role is part of the Compliance Administrator role group, which User1 does not have.

User2 can remove SharePoint sites from Policy1: No. While User2 is a Global Administrator and normally could modify the policy, the command Set-RetentionCompliancePolicy Policy1 -RestrictiveRetention $true has been applied. This "restrictive retention" mode explicitly prevents anyone, including Global Administrators, from removing locations (like SharePoint sites) from the policy, disabling the policy, or deleting it.

User2 can add the word Acquisition to Policy1: Yes. User2 is a Global Administrator and has the necessary permissions to edit policies. The RestrictiveRetention setting only prevents removing locations, disabling, or deleting the policy. It does not prevent modifying other policy settings, such as the conditions (e.g., adding or removing keywords like "Acquisition") or adding new locations.

Microsoft. (n.d.). Permissions in the Microsoft Purview compliance portal. Microsoft Learn. Retrieved October 20, 2025, from https://learn.microsoft.com/en-us/purview/permissions

Details: This document outlines the roles within default role groups. The Compliance Data Administrator role group does not contain the Retention Management role, which is necessary to modify retention policies.

Microsoft. (n.d.). Set-RetentionCompliancePolicy. Microsoft Learn. Retrieved October 20, 2025, from https://learn.microsoft.com/en-us/powershell/module/exchange/set-retentioncompliancepolicy

Details: The documentation for the -RestrictiveRetention parameter states: "When you set this parameter to $true, no one can remove locations from the policy, disable the policy, or delete the policy. However, adding locations is still allowed." This confirms that removing locations is blocked (Statement 2), but modifying other aspects like keywords is not (Statement 3).

The "Contributor" role is a standard Azure role-based access control (RBAC) role. When assigned to a specific resource or resource group (in this case, for Azure AD Connect Health), it grants the user full permissions to manage that resource. "Managing" includes the ability to view all data (like sync errors) as well as configure all settings.

• User2 has the Contributor role for Azure AD Connect Health, granting permissions for both viewing errors and configuring settings.
• User1 is the sync account, which is a service account used by the synchronization engine itself. It is not intended for interactive login or management tasks in the Azure portal.
• User3 is an Application administrator, an Azure AD role that manages application registrations and enterprise applications, which is not related to configuring the Azure AD Connect Health service.

Microsoft Entra documentation (formerly Azure AD): "Azure built-in roles - Contributor"

Section: Contributor

Details: The documentation defines the "Contributor" role as being able to "Grant[] full access to manage all resources." This management capability explicitly includes both read (viewing) and write (configuration) permissions on the resource to which the role is scoped.

Microsoft Entra documentation: "Monitor your on-premises identity infrastructure and synchronization services in the cloud"

Section: How to: Use Role-Based Access Control in Azure AD Connect Health

Details: This document outlines that access to Connect Health data is controlled by Azure RBAC. It confirms that built-in roles like "Contributor" (which grants management access) and "Reader" (which grants view-only access) are used. Since User2 is a Contributor, this role encompasses all permissions of the Reader role plus configuration rights.

Microsoft Entra documentation: "Application administrator" (Azure AD built-in role)

Section: Role description

Details: The "Application administrator" role permissions are limited to creating and managing "all aspects of enterprise applications, application registrations, and application proxy settings." This role does not include permissions to manage the Azure AD Connect Health infrastructure service.

Modify the password protection policy: This administrative task requires a role with specific permissions to manage tenant-wide security policies.

• User1 (Global Administrator): Has unrestricted access to manage all features, including password protection.
• User2 (Security Administrator): This role is explicitly granted permissions to manage security features, which includes Azure AD Password Protection.
• User4 (Password Administrator): This role is limited to resetting passwords for users; it does not have permissions to configure tenant-wide policies.
• User3 (None): Has no administrative roles.

Create new guest users in Azure AD: This capability is governed by the external collaboration settings.

• The prompt specifies the default configuration is used.
• The default setting in Azure AD for "Guest invite settings" is that all member users can invite guests.
• User1, User2, User3, and User4 are all member users within the tenant (regardless of their admin roles, or lack thereof).
• Therefore, all four users can create guest user accounts. User1 (Global Admin) and User2 (Guest Inviter) also have specific administrative roles that grant this ability, but the default policy extends this capability to User3 and User4 as well.

Microsoft. (n.d.). Azure AD built-in roles. Microsoft Learn.

Security Administrator (Role): The official documentation states this role "Can read security information and reports, and manage configuration in Azure AD... including Identity Protection, Conditional Access, and Password Protection." This confirms User2's permissions.

Global Administrator (Role): "Can manage all aspects of Azure AD." This confirms User1's permissions.

Password Administrator (Role): "Can reset passwords for non-administrators and Password Administrators." This confirms User4 cannot manage the policy.

Guest Inviter (Role): "Users in this role can manage Azure AD B2B guest invitations..." This confirms one of User2's permissions for the second task.

Microsoft. (2024, May 15). Delegate B2B collaboration invitations. Microsoft Learn.

Section: External collaboration settings: The documentation confirms the default settings: "Guest invite settings: Members can invite - Default is Yes." This confirms that all members, including User1, User2, User3, and User4, can invite guests.

This configuration precisely meets the requirements for the following reasons:

1. Target resources: User actions The policy must apply only during the specific event of joining a device. "Register or join devices" is a User action that can be targeted in a Conditional Access policy, making it more precise than targeting general Cloud apps.
2. Conditions: Device platforms The requirement states the policy should apply only when users join their Windows devices. The Device platforms condition is used to scope the policy to include only the Windows operating system.
3. Grant access: Require authentication strength The policy must require FIDO2 security keys. The general Require multi-factor authentication control allows any MFA method (like an authenticator app or SMS). The Require authentication strength control is the specific mechanism used to enforce a particular strong authentication method, such as a built-in phishing-resistant strength or a custom strength defined to only allow FIDO2 keys.

Microsoft Entra ID Documentation (User actions):

Source: Microsoft Learn, "Conditional Access: Target resources - User actions"

Reference: The documentation states, "User actions are tasks that can be performed by a user... Currently, the only supported action is Register or join devices to Microsoft Entra ID." This directly supports selecting User actions to target the specific event in the question.

Microsoft Entra ID Documentation (Authentication strength):

Source: Microsoft Learn, "Conditional Access: Grant - Require authentication strength"

Reference: The documentation specifies, "This [control] allows administrators to select a specific built-in or custom authentication strength to access a resource." It further clarifies that built-in strengths include "Phishing-resistant MFA," which encompasses FIDO2. This control is the correct method to force a specific method like FIDO2, rather than just any MFA.

Microsoft Entra ID Documentation (Device platforms):

Source: Microsoft Learn, "Conditional Access: Conditions - Device platforms"

Reference: This document confirms, "Conditional Access can be used to target specific device platforms... The Device platforms condition allows you to target policies to specific operating systems," such as Windows. This supports using this condition to scope the policy as required.

The evaluation is based on two key factors: the policy's scope and the rule's conditions.

1. Policy Scope: The prompt explicitly states, "You apply DLP1 to Site1." A Data Loss Prevention (DLP) policy only applies to the locations specified in its configuration.

• Document2 is stored on Site2, which is outside the policy's scope. Therefore, DLP1 cannot apply to Document2, regardless of its content.

1. Rule Conditions: The (missing) exhibit for this advanced DLP rule, DLP1, defines a rule where two conditions are in the same group, meaning they are joined by a logical AND operator. The conditions are:

• Condition A: Content contains Sensitive Info Type "Credit card number" with an instance count of 1 to 9.
• AND
• Condition B: Content contains Sensitive Info Type "SWIFT code" with an instance count of 1 or more.

Based on this logic:

• Document1: (On Site1) It contains 3 credit card numbers (which is between 1-9) AND 3 SWIFT codes (which is 1 or more). Since both conditions are met, the policy applies.
• Document3: (On Site1) It contains 15 credit card numbers (which fails the "1-9" condition) AND 0 SWIFT codes (which fails the "1 or more" condition). Since the conditions are not met, the policy does not apply.

Microsoft Purview Documentation. (2025). "Learn about data loss prevention." Microsoft Learn.

Reference: This document confirms that DLP policies are applied to specific locations, such as "SharePoint sites" and "OneDrive accounts." A policy's scope is limited to the locations (like Site1) that are explicitly included in its configuration.

URL: https://learn.microsoft.com/en-us/purview/dlp-learn-about-dlp

Section: "Policy configuration overview" > "location" table.

Microsoft Purview Documentation. (2025). "Design a data loss prevention policy." Microsoft Learn.

Reference: This document details the construction of advanced DLP rules. It explains the use of "boolean logic (AND, OR, NOT) and nested groups" to combine multiple conditions. For a policy to trigger, all conditions within a group (linked by a default 'AND') must be true.

URL: https://learn.microsoft.com/en-us/purview/dlp-policy-design

Section: "Complex rule design."

Microsoft Purview Documentation. (2025). "Create and deploy a data loss prevention policy." Microsoft Learn.

Reference: This document explains the components of a DLP rule, including "Choose the conditions that must be matched," which involves defining sensitive information types (like "Credit card number") and their corresponding "instance count."

URL: https://learn.microsoft.com/en-us/purview/dlp-create-deploy-policy

Section: "Policy deployment steps" > "Choose the conditions..."

The exhibit shows that both Group1 and Group2 are targeted for Microsoft Authenticator settings, and their Authentication mode is set to Passwordless.

1. User1 (Group1): As a member of Group1, User1 is configured for Passwordless authentication. This sign-in method involves entering a username and then approving a notification in the Authenticator app by matching a number displayed on the sign-in screen. Therefore, User1 can sign in using number matching.
2. User2 (Group2): As a member of Group2, User2 is also configured for Passwordless authentication. This policy replaces the password prompt. When User2 enters their username, they will receive a number-matching prompt on their Authenticator app, bypassing the password entry step entirely. Therefore, User2 cannot sign in using a username and password.
3. User3 (Group1 & Group2): User3 is a member of both groups and is subject to the same Passwordless authentication mode. Like User1, User3 will sign in using their username followed by a number-matching prompt in the Authenticator app.

The Conditional Access policy requiring MFA is compatible with this, as passwordless phone sign-in is considered a phishing-resistant MFA method.

Microsoft Entra documentation (formerly Azure AD): "How to configure passwordless sign-in with the Microsoft Authenticator app"

Section: "Enable passwordless phone sign-in"

Reference: This document details the setup shown in the exhibit. It states, "After you enable the policy... users who are in the targeted group see a 'Sign in with your phone' option... But this option doesn't remove the password. To remove the password, you need to change the Authentication mode to 'Passwordless'." The exhibit shows this exact "Passwordless" configuration for both groups, confirming the password prompt is removed.

Microsoft Entra documentation (formerly Azure AD): "Authentication methods in Microsoft Entra ID - Microsoft Authenticator app"

Section: "Passwordless sign-in"

Reference: "Instead of seeing a prompt for a password after entering a username, the user sees a message to tap a number in their Microsoft Authenticator app. ...This method is a convenient passwordless primary authentication option..." This confirms that number matching is the mechanism for this passwordless flow.

To meet the requirements, two separate configurations in the Defender for Cloud Apps settings are necessary:

1. Files: This settings page contains the "Enable file monitoring" option. This must be enabled to allow Defender for Cloud Apps to scan files within your connected SaaS applications. This directly fulfills the requirement to "inspect files in connected... SaaS apps."
2. Microsoft Information Protection: This settings page is required to integrate Defender for Cloud Apps with Microsoft Purview Information Protection. Enabling this integration allows the service to scan for, identify, and read the sensitivity labels on protected files. This fulfills the requirement to "inspect protected files."

Microsoft. (2024). Protect files with Microsoft Defender for Cloud Apps. Microsoft Learn. Retrieved October 21, 2025.

Section: "How to configure file protection"

Quote: "To work with file policies... make sure you have Enable file monitoring selected in Settings > Information Protection > Files."

Microsoft. (2024). Integrate Microsoft Purview Information Protection with Defender for Cloud Apps. Microsoft Learn. Retrieved October 21, 2025.

Section: "How to integrate Microsoft Purview Information Protection"

Quote: "To enable Defender for Cloud Apps to scan files and apply Microsoft Purview Information Protection sensitivity labels... In the Microsoft Defender Portal, select Settings. Then choose Cloud Apps. Under Information Protection, choose Microsoft Information Protection."

Al-Saeed, M. A. J. S., et al. (2021). "A review of cloud access security broker (CASB)." 2021 International Conference on Information Technology (ICIT), Amman, Jordan, pp. 642-647.

DOI: https://doi.org/10.1109/ICIT52682.2021.9491763

Section: III.A, "Data Security"

Relevance: This academic paper discusses the core functions of a CASB (like Defender for Cloud Apps), which include "discovering and monitoring sensitive data" and enforcing data loss prevention (DLP) policies, academically grounding the requirement to inspect files in cloud apps for protection labels.

The solution is determined by the specific permissions assigned to each Microsoft Entra built-in role.

1. Create guest user accounts: This action requires the microsoft.directory/users/invite permission.

• The User Administrator role (assigned to User2) explicitly includes this permission, allowing them to invite guest users.
• The other roles listed—Privileged Role Administrator (User1), Security Administrator (User3), and Billing Administrator (User4)—do not include this permission. The "default external collaboration settings" simply confirm the feature is not tenant-wide disabled.

1. Add User3 to Admin1: This action requires the microsoft.directory/groups/members/update permission to manage the membership of a standard security group.

• The User Administrator role (assigned to User2) grants permissions to "manage all aspects of users and groups," which includes this specific permission.
• The Privileged Role Administrator (User1) manages role assignments and role-assignable groups, not standard security groups. The Security and Billing administrator roles lack group management permissions.

Therefore, User2 is the only user with the necessary permissions for both tasks.

Microsoft. (n.d.). Microsoft Entra built-in roles. Microsoft Learn. Retrieved October 24, 2025, from https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference

Section: "User Administrator": Confirms this role (User2) has the permissions microsoft.directory/users/invite (to invite guests) and microsoft.directory/groups/members/update (to manage group members).

Section: "Privileged Role Administrator": Confirms this role (User1) permissions are focused on role assignments and Privileged Identity Management, and it lacks the permissions listed above.

Section: "Security Administrator": Confirms this role (User3) lacks user and group management permissions.

Section: "Billing Administrator": Confirms this role (User4) lacks user and group management permissions.