Practice Test #3

Fail. Setting Reviewers to Member (self) makes each IT administrator review their own access (self-attestation). That does not ensure that the manager of each department receives and performs the access review for their department’s users. The requirement is explicitly manager-based routing by department. The reason all requests currently go to Megan Bowen is that she is configured as the fallback reviewer. Fallback reviewers receive review tasks when Entra ID cannot determine a valid manager for the reviewed users (for example, the Manager attribute is not set for those users). To meet the goal, keep Reviewers as Manager and ensure each admin account has the correct manager populated in Entra ID (and optionally scope reviews by department groups). Self-review is a different governance control and does not satisfy the manager-per-department requirement.

Correct answer: C (Register for self-service password reset (SSPR)). If the goal is to address the probability that identities were compromised (user risk), the typical automated remediation is to force a password change. In Microsoft Entra ID, a user risk policy can require “password change” when user risk is detected. For users to complete that password change without helpdesk/admin intervention, they must be registered for SSPR (including authentication methods required by SSPR). This is the practical prerequisite that enables the policy outcome. Why not B: MFA registration helps mitigate risky sign-ins and strengthens authentication, but it does not by itself enable the “require password change” remediation flow for compromised identities. Why not A: App consent is unrelated to Identity Protection risk remediation and does not address compromised identity probability.

Correct answer: B (A user risk policy). A user risk policy in Identity Protection targets the likelihood that a user account is compromised (user risk). It can automatically remediate by requiring a secure password change (and/or blocking access) when the user risk level meets a configured threshold (low/medium/high). This directly matches the requirement about the probability that user identities were compromised. Why not A: A sign-in risk policy evaluates individual sign-in attempts (session/authentication events). It’s used when you want to respond to risky sign-ins (for example, require MFA or block sign-in), not when the account itself is suspected compromised. Why not C: Azure AD Password Protection focuses on banning weak passwords and enforcing password complexity (including custom banned password lists). It improves password hygiene but does not implement risk-based detection/remediation for compromised identities.

No. Assigning Azure AD (Entra ID) licenses to a Users group is not required to make an enterprise application appear in the My Apps portal. My Apps visibility is controlled by the enterprise application’s assignment (Users and groups) and the application property “Visible to users,” especially when “User assignment required” is set to Yes. Group-based licensing is used to grant product capabilities (for example, Entra ID P1/P2 features such as Conditional Access, Identity Protection, PIM, etc.). While licensing can be necessary to use certain security features, it does not by itself publish an app tile in My Apps. If users can already see App1 and App2, licensing is clearly not the differentiator for basic My Apps access. The correct fix is to ensure HRUsers is assigned to App3 (or that App3 has an equivalent assignment), not to change licensing.

No. Configuring device settings to allow only a specific group (Members) to join devices affects Azure AD device registration/join (who can Azure AD join devices), not whether an enterprise application appears in the My Apps portal. My Apps is an application access experience. The issue described is that users do not see App3, which is almost always due to missing assignment to App3 (given “User assignment required: Yes”) or App3 not being visible to users. Device join restrictions are tenant-wide device governance controls and would be an incorrect-scope change for an app tile visibility problem. From an exam perspective, avoid “broad tenant setting” changes when the symptom is isolated to one enterprise application. The least-privilege, correct-scope remediation is to adjust App3’s enterprise application assignments/visibility.

No. Assigning the Cloud device administrator role to the Users group is unrelated to My Apps portal visibility for App3. The Cloud device administrator role provides permissions to manage device objects in Entra ID (for example, enabling/disabling devices, managing BitLocker keys in some contexts depending on integration), not to manage enterprise application assignments or user portal tiles. To make App3 appear when “User assignment required” is enabled, the users (or a group they are in, such as HRUsers) must be assigned to App3 under Enterprise applications > App3 > Users and groups. Alternatively, if the app is intended for all users, you could disable “User assignment required,” but that changes access control posture and is typically not recommended unless appropriate. Therefore, adding a device admin role would not address the root cause and would violate least privilege by granting unnecessary administrative rights.

Select A (Pass) because the correct approach is determinable from the access review settings shown. The exhibit provides the critical parameters: start date (01/15/2021), frequency (Monthly), duration (14 days), end date (02/15/2021), scope (Group1 members), and reviewers (Members/self). From these, you can infer who is eligible to respond (only User1 and User2 because they are members) and the time windows when responses are allowed (during the active review period). Option B (Fail) would only apply if key information were missing (for example, if the reviewer type or duration were not shown). Here, the configuration is sufficient to answer all sub-questions using standard Access Reviews behavior tested in SC-300.

User1 is a member of Group1 and the access review is configured with Reviewers = “Members (self)”. That means User1 is explicitly a reviewer for their own access and can respond to the prompt “Do you still need access to Group1?”. The table in the question states that “Users answer the Review1 question as shown…”. For User1, the recorded response is “Yes”. Therefore, the correct selection for User1’s answer is Yes. Why not No: Nothing in the scenario indicates User1 selected No, nor is there any automatic decisioning described (such as “auto-apply results” or “if no response remove access”). This sub-question is simply asking you to reflect the user’s provided response from the table.

User2 is also a member of Group1 and, with “Members (self)” configured as reviewers, User2 can respond for themselves. The question states that users answered as shown in a table; User2’s recorded response is “No”. Therefore, for “User2: Do you still need access to Group1?”, the correct selection is No. Why not Yes: The access review does not infer “Yes” by default; the user’s explicit response is what is being tested here. Also, nothing in the provided settings indicates an auto-approval rule. In access reviews, each reviewer’s decision is captured per user per review instance, and the exam commonly checks that you can map the scenario’s stated responses to the correct options.

No. The first review instance starts on 01/15/2021 and has a duration of 14 days, so it is active approximately through 01/29/2021. February 5, 2021 is outside that active window. Could there be a second instance? With a monthly frequency, the next instance would start on 02/15/2021 (one month after 01/15). February 5 is still before 02/15, so there is no active review instance on 02/05. Additionally, access review responses are tied to an active instance; users can only answer while the instance is open. Since 02/05 is between instances (after the first ended and before the next would begin), User1 cannot answer the Review1 question again on that date.

Yes. The access review starts on January 15, 2021 and remains open for 14 days, so January 25 falls within the active review window. Because the reviewers are configured as "Members (self)", User2 is allowed to review their own access during that open period. While the review is active, the reviewer can revisit and change their response, so User2 can answer the Review1 question again on January 25. No would be incorrect because the review has not yet closed, and User2 is an eligible reviewer.

No. User3 is the owner of Group1, but not a member (members are only User1 and User2). The access review is configured with Reviewers = “Members (self)”, which means only the users being reviewed (the group members) are reviewers. Group ownership does not grant the ability to participate in the access review unless the reviewer type includes owners (for example, “Group owners”) or User3 is also in the reviewed population (a member of Group1). Since neither is true, User3 is not a reviewer and cannot answer the Review1 question on 01/22/2021 (or any date) under this configuration. This is a common exam trap: confusing group owners’ management rights with access review reviewer assignment. Access reviews strictly follow the configured reviewer selection.