Practice Test #2

Yes. Device1 is registered in contoso.com based on the device inventory table in the prompt. In Azure AD, “Registered” indicates the device has a device object in Entra ID associated to a user (common for BYOD scenarios) and can be used in Conditional Access device-based conditions. This is distinct from “Azure AD joined” (corporate-owned, joined directly to Entra ID) and “Hybrid Azure AD joined” (joined to on-prem AD and registered with Entra ID). The question’s first three sub-questions are simply validating the device state shown in the table; they are not derived from the Terms of Use settings. Therefore, the correct selection is Yes for Device1.

No. Device2 is not registered in contoso.com per the table. If a Windows 10 device is Azure AD joined or Hybrid Azure AD joined, it is typically not described as “Registered” in the device list; it would show as “Azure AD joined” or “Hybrid Azure AD joined.” Conversely, if it is unmanaged and only used to sign in via a browser without device registration, it would not appear as registered either. Since the table indicates Device2 is not in the “Registered” state, the correct answer is No. This matters later only if Conditional Access policies require a compliant or hybrid-joined device; however, Terms of Use itself can still be presented regardless of registration, as long as the user can authenticate and the CA policy applies.

Yes. Device3 (iOS) is registered in contoso.com according to the table. iOS devices commonly become Azure AD registered when a user adds a work account to an app like Microsoft Authenticator, enrolls via Intune Company Portal, or otherwise establishes a workplace join/registration. This creates a device object in Entra ID tied to the user, enabling device identity signals for Conditional Access. The platform (iOS) does not prevent registration; it simply changes how registration occurs compared to Windows 10. Since the question explicitly states the device list and asks whether Device3 is registered, the correct selection is Yes.

Yes. On November 20, 2020, User1 can accept Terms1 on Device1. Because “Require users to consent on every device” is enabled, accepting Terms1 on Device3 on November 15 does not satisfy the requirement for Device1. When User1 signs in from Device1 and hits the Conditional Access policy that enforces Terms1, Azure AD will prompt for Terms1 acceptance for that device. Nothing in the settings prevents acceptance before the expiration start date. Expiration is configured to start on December 10, 2020, so on November 20 the consent process works normally and the user can accept. The “Require users to expand the terms of use” setting only affects the UX (they must expand before accepting), not whether acceptance is possible.

Yes. User1 can accept Terms1 on Device2 on December 11, 2020 because consent is required on every device, and the prior acceptance on Device3 does not satisfy the requirement for Device2. When User1 accesses a resource from Device2 and the Conditional Access policy applies, Azure AD can prompt for Terms1 and allow acceptance. The expiration setting does not block acceptance; it only determines when an existing consent must be renewed. The acceptance on Device3 is irrelevant for Device2 because consent is tracked separately per device.

No. On December 7, 2020, User1 cannot (does not need to) accept Terms1 again on Device3 because the existing consent on Device3 (accepted November 15, 2020) is still valid at that time. The expiration start date is December 10, 2020, meaning consents are not considered expired before that date. Since December 7 is prior to December 10, the consent record for Device3 remains valid and Azure AD would not prompt for re-acceptance during normal sign-in flows. Important nuance for exam context: users can only accept when prompted by a policy evaluation (there isn’t typically a self-service “re-accept now” action). Because the consent is still valid on December 7, the prompt would not appear, so the practical answer is No.

Correct selection is Pass because the number of licenses used can be determined from the group configuration. When Microsoft 365 E5 is assigned to Group1, Azure AD group-based licensing assigns the license only to direct user members of Group1. Group1’s direct members are User1 and User3, plus Group2 and Group4 (which are groups). Nested group membership is not evaluated for group-based licensing, so User2 (in Group2) and User4 (in Group4) do not receive licenses via Group1. Group3 contains a device (Device1), but devices do not consume Microsoft 365 user licenses, and Group3 isn’t even nested under Group1. Group5 is unrelated. Therefore, only User1 and User3 get licensed, so 2 licenses are used. The “Fail” option would be incorrect because this is a standard, testable rule: no nested groups for group-based licensing.

Correct: Privileged role administrator. This Microsoft Entra ID (Azure AD) directory role is specifically intended to manage role assignments for Entra ID roles. It allows a delegated admin to assign and remove built-in directory roles without needing full Global Administrator privileges, aligning with least privilege. Why others are wrong: - Global administrator can manage role assignments, but it is overly privileged and typically not the best delegation choice when a more scoped role exists. - Security administrator focuses on security features (e.g., security policies, alerts) and is not the standard role for managing Entra ID role assignments. - User access administrator is an Azure RBAC role for managing access to Azure resources (ARM), not for managing Entra ID directory role assignments.

Correct: User access administrator. This is an Azure RBAC built-in role that can manage access to Azure resources by creating and managing role assignments at subscription/resource group/resource scope. It includes permissions to write role assignments (Microsoft.Authorization/roleAssignments/*), which is exactly what you need to delegate RBAC administration. Why others are wrong: - Global administrator and Privileged role administrator are Microsoft Entra ID directory roles; they do not automatically grant Azure RBAC permissions to manage role assignments in subscriptions. - Security administrator is also a directory role focused on security administration and does not provide the required Azure RBAC permissions to manage role assignments. In practice, you often combine Entra ID governance (directory roles) with Azure RBAC (resource roles), but you must assign the correct role in the correct plane.

Yes. You can create an access review for a group, including a security group with Assigned membership. Group access reviews are one of the primary access review scenarios in Microsoft Entra ID Identity Governance: reviewers validate whether each user should remain a member of the group. The group’s membership type (Assigned vs Dynamic) does not prevent creating an access review. Why “No” is wrong: Access reviews are not limited to dynamic groups or privileged groups. Assigned membership groups are commonly used to grant access to apps, SharePoint sites, and Azure resources, and therefore are a standard target for periodic review. In practice, reviewing group membership is often the first governance control implemented because group membership frequently drives downstream access.

Yes. You can create an access review for an enterprise application (service principal) to review user and group assignments to that application. This is a core Identity Governance capability: ensuring that only appropriate users retain access to applications, especially high-impact SaaS apps integrated with SSO. Why “No” is wrong: Enterprise applications are explicitly supported in access reviews as “Applications” (review assigned users/groups). This is distinct from reviewing app registrations (which are developer objects). The access review targets the enterprise application’s assignments (who can sign in / has app roles), not the app registration configuration.

Yes. Contributor is an Azure subscription role (an Azure RBAC built-in role). Access reviews can be created for Azure resource roles (Azure RBAC roles) to periodically validate role assignments at scopes such as subscription, resource group, or resource. This is commonly used to ensure powerful roles like Contributor remain tightly controlled. Why “No” is wrong: While Azure RBAC is not the same as Microsoft Entra directory roles, Identity Governance supports access reviews for Azure resource roles (often integrated with PIM). The exam expects you to recognize that Azure RBAC assignments are reviewable, not just group/app access.

Yes. Role1 as an Azure Active Directory (Microsoft Entra ID) role (directory role) can have its assignments reviewed using access reviews. This is especially important for privileged roles (e.g., Global Administrator, User Administrator), but access reviews can apply to role assignments generally depending on configuration and licensing. Why “No” is wrong: Access reviews are a key control for governing directory role assignments, often used alongside Privileged Identity Management (PIM) to ensure that only the right administrators retain role assignments over time. This supports least privilege and reduces standing administrative access.

The exhibits shown do not provide the object table that would prove User1 is a member of Group1. Because the statement asks whether that membership is true, and the visible configuration screens only show that Group1 is the selected filtering group, the statement cannot be validated from the provided evidence. Therefore the current 'Yes' is unsupported. The filtering configuration affects synchronization scope, but it does not by itself establish group membership facts for User1.

The visible exhibits do not show the object table or User2's memberships. The Azure AD Connect filtering screens only show that OU1 and OU2 are selected and that Group1 is used for group-based filtering; they do not prove that User2 belongs to no groups. Because the statement is about an AD fact rather than sync behavior, answering 'Yes' requires evidence that is not present in the provided material. Therefore the current answer is not justified by the exhibits.

The provided screenshots do not include the object table that would show Group1 membership. While the filter is configured to use Group1, that does not establish which objects are members of Group1. Since the statement combines two membership claims, both would need to be explicitly shown to answer 'Yes'. Without that evidence, the current answer is unsupported.

The filtering exhibit identifies Group1 as the selected synchronization group, but it does not list Group1's members. Therefore, there is no direct evidence in the provided material that Group2 is a member of Group1. The note about nested groups being ignored explains behavior if such nesting exists, but it does not prove that it exists in this scenario. As a result, 'Yes' is not supported by the visible exhibits.

The screenshots show the Azure AD Connect configuration needed to evaluate synchronization scope: only OU1 and OU2 are selected, and Group1 is the selected group for group-based filtering. They also show the important rule that nested groups are not supported for expanding membership. However, determining the truth of membership statements about User1, User2, and Group2 still requires the object table referenced in the scenario. The images are sufficient to understand the filtering logic, but not to infer unseen membership facts by themselves.

User1 syncs to Azure AD only if two conditions are both true: User1 must be located in a selected OU, and User1 must be a direct member of Group1. The screenshots confirm the filtering rules but do not show User1's OU location or actual group membership. Therefore, the explanation should not state those facts as proven by the exhibits alone. OU filtering defines the candidate scope, and group-based filtering then limits synchronization to direct members of Group1.

User2 would not sync to Azure AD if User2 is not a direct member of Group1, even if User2 is in OU1 or OU2. The screenshots establish that group-based filtering is enabled for Group1 and that nested groups are ignored for membership expansion. However, they do not independently prove User2's group memberships. The correct reasoning is that synchronization depends on direct membership in Group1 plus OU scope, not merely OU placement.

Group2 syncs only if the Group2 object itself is within a selected OU and is a direct member of Group1. The note that nested groups are ignored means Azure AD Connect does not expand membership through Group2 to include objects inside it; it does not by itself prove whether Group2 is a member of Group1. The screenshots show the filtering configuration, but not Group2's actual membership or OU location. Therefore, the explanation should describe the rule rather than assert unseen facts.