Explanation:
This question is about matching security incidents to the correct Azure Active Directory policy that can detect and/or remediate them. The key is distinguishing between User Risk and Sign-in Risk.
User Risk is about the user's account itself being compromised or in a risky state.
Sign-in Risk is about a specific authentication attempt being suspicious, regardless of which user it is.
Let's break down each policy type and its application:

1. A user risk policy
What it does: This policy is part of Azure AD Identity Protection. It evaluates the overall risk level of a user account based on indicators that the user's credentials have been compromised. The primary source for user risk is the detection of leaked credentials.

Correct Application: Leaked credentials
Why: When user credentials are found on the dark web or in a breach, the account itself is considered "at risk." A User Risk Policy can trigger an action, such as requiring a password change or blocking access until the password is reset, to remediate this compromised state.
2. A sign-in risk policy
What it does: This policy is also part of Azure AD Identity Protection. It evaluates the risk of a specific sign-in event based on the characteristics of that sign-in attempt.
Correct Applications:
A sign-in from a suspicious browser: This is a classic sign-in risk detection. Identity Protection uses heuristics to identify browser signatures associated with malicious activity.
Resources accessed from an anonymous IP address: This is another common sign-in risk detection. Sign-ins from IP addresses known to be used by anonymizing services (like Tor) are flagged as risky. A Sign-in Risk Policy can require MFA, block access, or take other actions for such sign-in attempts.

Why the Other Policy is Incorrect
An authentication method policy: This refers to policies that configure authentication methods, like which MFA methods are allowed (e.g., Microsoft Authenticator, SMS, FIDO2 keys). It does not directly respond to the specific risk incidents listed.
A Conditional Access policy:
This is a broader category. While both User Risk and Sign-in Risk policies are a type of Conditional Access policy, the question is asking for the specific policy type designed to handle these predefined risk detections from Identity Protection. A general Conditional Access policy could be used for other conditions like location, device platform, or application sensitivity, but for these specific "risk" incidents, the dedicated risk policies are the correct answer.

References
Microsoft Learn: What is Identity Protection? - User risk
Microsoft Learn: What is Identity Protection? - Sign-in risk
Microsoft Learn: How To: Configure and enable risk policies

Explanation:
The scenario describes a company that is already using Azure AD Connect to synchronize their on-premises Active Directory with Azure AD. They are adding a new domain, litware.com, to their on-premises environment and need to extend this synchronization to include the users and objects from this new domain.

Here's a breakdown of why this is the correct answer and why the others are not:
B. Azure AD Connect to include the litware.com domain:
This is the standard and correct procedure. After adding the litware.com domain to your on-premises Active Directory forest, you must reconfigure Azure AD Connect. You would run the installation wizard again and add the new domain to the list of domains that are selected for synchronization. Azure AD Connect will then begin synchronizing users, groups, and other objects from the litware.com domain to the Azure AD tenant.
A. Azure AD Connect cloud sync between the Azure AD tenant and litware.com:
Azure AD Connect Cloud Sync is a separate, lighter-weight agent designed for simpler scenarios, such as synchronizing a disjointed forest or integrating with an HR-driven provisioning source. It is not the right tool for adding a new domain to an existing, on-premises AD forest that is already being synchronized by the full Azure AD Connect client. Using two different synchronization tools for the same tenant and on-premises infrastructure is unsupported and would lead to conflicts.
C. staging mode in Azure AD Connect for the litware.com domain:
Staging mode is a feature of Azure AD Connect used for disaster recovery or to verify configuration changes before they are fully applied. When a server is in staging mode, it synchronizes data but does not export anything to Azure AD. It is not the mechanism used to add a new domain. You would add the domain through the standard configuration process, and you could use a server in staging mode to verify that the new domain's objects are synchronizing correctly before switching it to active, but the core action is still "including the domain" in the sync configuration.

Summary:
When you add a new domain to an on-premises Active Directory forest that is already being synchronized, the standard process is to reconfigure your existing Azure AD Connect installation and add the new domain to the synchronization scope.

Reference:
Microsoft Learn: Azure AD Connect: Add a new forest to an existing deployment

Explanation:
The question states:
“You need to resolve the issue of IT-Group1. What should you do first?”
This typically refers to a management or modification issue with an Azure AD group (e.g., unable to update membership, change properties, or modify rules). In Azure AD (Microsoft Entra ID), only group owners or Global/Group administrators can make changes to a group’s settings or membership.
If the group does not have an owner, no user (other than a privileged admin) can manage it directly — causing management issues.
Therefore, the first step to resolving the issue is to add an owner to the group, so it can be administered and managed properly.

Option Analysis:
A. Recreate the IT-Group1 group ❌
Not necessary and would cause disruption. The issue can be fixed by simply adding an owner; recreating is excessive.
B. Change Membership type of IT-Group1 to Dynamic Device ❌
Irrelevant unless the group is meant to manage devices. The issue described is about management, not membership logic.
C. Add an owner to IT_Group1 ✅
Correct. Groups without owners often lead to issues with administration, policy assignment, or membership updates. Adding an owner resolves these issues.
D. Change Membership type of IT-Group1 to Dynamic User ❌
Also unrelated — membership type determines how members are populated (manual or dynamic), not whether the group can be managed.

Reference:
Microsoft Learn: Manage group owners in Microsoft Entra ID
Microsoft Learn: Create and manage groups in Microsoft Entra ID

Explanation:
The issue relates to the policies governing how external users (guests) are invited to collaborate within the Azure AD tenant. The central place to manage these behaviors is the External collaboration settings.

Here’s a breakdown of why this is the correct answer and why the others are not:
B. Modify the External collaboration settings:
This is the direct and correct solution. Within the Azure AD portal, the External collaboration settings (found under External Identities > External collaboration settings) allow an administrator to control:
Who can invite guest users (admins and members, members only, specific users, or no one).
Whether guests have the same permissions as members (limited or full).
Enabling or disabling email one-time passcode for unauthenticated guests.
Configuring collaboration restrictions (allowing or denying invitations to specific domains).
Any issue related to the process of inviting guest users is resolved here.
A. Configure the Continuous access evaluation settings:
This is a security feature that enables critical events (like a user being disabled or their password being changed) to be evaluated in real-time, revoking access to resources immediately. It is unrelated to the configuration of how guest user invitations are sent and managed.
C. Configure the Access reviews settings:
Access reviews are a governance tool used to periodically review and certify user access to applications, groups, and roles. While you can create an access review specifically for guest users, this is a reactive measure to manage existing guests, not to resolve an issue with the initial invitation process itself.
D. Configure a Conditional Access policy:
Conditional Access policies are for enforcing access controls after a user has successfully authenticated (e.g., requiring MFA, blocking access from certain locations). They do not control the administrative settings for who can send invitations or how those invitations are handled.

Summary
To resolve an issue with guest user invitations, you must modify the core configuration that governs external collaboration. This includes determining who can invite guests and what domains are allowed, which is all managed within the External collaboration settings.

Reference:
Microsoft Learn: Configure External Collaboration Settings

Explanation:
The core objective of this question is to transition from a model of permanent administrative access to a just-in-time (JIT) model, which is the fundamental purpose of Azure AD Privileged Identity Management (PIM). The two actions that form the complete solution for this transition are making users eligible for the role and then enforcing a time limit on its active use.

Why C and D are Correct:

C. Set all assignments to Eligible:
This is the foundational step. Instead of assigning the User Administrator role with permanent, "always-on" access (an Active assignment), you configure the role so that users are Eligible. This means they do not have the permissions of the role by default. When they need to perform a task requiring those permissions, they must go through a process to "activate" the role. This drastically reduces the organization's attack surface by minimizing the number of standing administrators. This action directly implements the principle of least privilege.

D. Modify the Expire eligible assignments after setting:
This action is the critical control that complements eligibility. Without a time limit, a user could activate the role and leave it active indefinitely, effectively creating a new permanent administrator. By modifying the "Expire eligible assignments after" setting, you define a maximum duration for which an activated role remains active (e.g., 2, 4, or 8 hours). After this time, the activation expires automatically, and the user's permissions are revoked, forcing them to reactivate if needed. This enforces time-bound access and limits the window of exposure if a credential is compromised.

Together, these two actions create a secure workflow:
a user is Eligible (C) for the role and can activate it for a pre-defined, limited time (D), after which it deactivates automatically.

Why the Other Options Are Not Correct:

A. Select Require justification on activation:
While this is a recommended additional security control, it is not part of the core solution to implement just-in-time access. It enforces accountability by requiring users to type a reason for activation, but it does not, by itself, change the assignment type from permanent to temporary or create the eligibility model. It is an enhancement, not a foundational step.

B. Set all assignments to Active:
This is the opposite of what is required for a security-focused technical requirement. "Active" assignments are permanent, standing privileges. Using this setting would increase the attack surface and violate the principle of least privilege. The entire goal of PIM is to move away from this model.

E. Select Require ticket information on activation:
Similar to option A, this is an optional, enhanced control. It mandates linking the activation to a specific ticket or request number from an IT service management (ITSM) tool. While excellent for audit trails and change control, it is not one of the two primary actions needed to establish the JIT model itself. It is often used in more mature, highly regulated environments but is secondary to setting eligibility and expiration.

References:
Microsoft Learn:
What is Azure AD Privileged Identity Management? - This document explains the core concepts of Eligible vs. Active assignments.
Microsoft Learn:
Configure Azure AD role settings in PIM - This guide details how to change role settings, including making assignments eligible (the assignment duration) and setting a maximum activation period (the activation duration).

Explanation:
The key phrase in the question is "planned changes for application access." This indicates a strategic initiative to manage how users gain access to resources like applications, groups, and sites in a controlled manner. In the Microsoft Identity and Access ecosystem, the dedicated service for this precise purpose is Entitlement Management, whose core component is Access Packages.
An Access Package is a bundle of all resources—including applications—that a user needs to access for a project, task, or role. It allows you to implement a governance model where:

Access is grouped logically:
You bundle applications, Teams, SharePoint sites, etc., into a single, requestable "package."
Access is lifecycled:
You define precisely who can request the package (e.g., employees, external users from specific partners), who must approve the request, and how long the access is valid before it must be reviewed or expires.
Access is auditable:
You have a clear record of who has access to what, why they have it, and its current status.
Configuring Access Packages directly fulfills the requirement to implement a planned, managed change for how users access applications and the organizational data within them.

Why the Other Options Are Not Correct
A. Authentication methods:
This refers to configuring how users sign in (e.g., Password, Windows Hello for Business, FIDO2 keys, the Microsoft Authenticator app). While crucial for security, it does not control which applications a user is permitted to access or the business process for granting that access. It verifies identity but does not manage resource entitlements.
B. The User consent settings:
This controls whether end-users are allowed to grant applications permission to access company data on their behalf. While this relates to application access, it is a tenant-wide setting focused on permissions and API access, not a tool for proactively packaging and governing access to specific applications as part of a planned change. It's about preventing unauthorized consent, not orchestrating approved access.
D. An application proxy:
This is a feature of Azure AD Application Proxy used to provide secure remote access to on-premises web applications. It is a solution for publishing internal apps to the internet. It does not provide any governance, lifecycle management, or request workflows for granting users access to those or any other applications. It is an access enabler for specific app types, not an access governance tool.

Reference:
Microsoft Learn:
What is entitlement management? - This document explicitly outlines how access packages are used to manage access to applications and other resources.

Explanation:
This question pertains to implementing access reviews for an access package (Package1) in Microsoft Entra ID Governance, specifically within the Entitlement Management feature, as part of the SC-300 exam objectives. Access reviews in Microsoft Entra ID allow organizations to periodically review user access to resources to ensure compliance and security. The question asks which users can create and manage access reviews for Package1.

Access reviews in Entitlement Management can be created and managed by specific roles in Microsoft Entra ID. The key roles with permissions to create and manage access reviews for access packages are:
Global Administrator: Has full control over all Microsoft Entra ID resources, including creating and managing access reviews.
Identity Governance Administrator: Has specific permissions to manage Entitlement Management, including creating and managing access packages and their associated access reviews.
User Administrator (in some cases): Can manage certain aspects of user access but typically does not have full permissions to create or manage access reviews for access packages unless explicitly assigned.
Without specific details about the roles of User3, User4, and User5, we can infer the correct answer based on typical SC-300 question patterns and the context of Entitlement Management. The answer E. User3 and User5 suggests that these two users hold roles (e.g., Global Administrator or Identity Governance Administrator) that grant them the necessary permissions to create and manage access reviews for Package1.
Why not User4? User4 likely does not have a role with sufficient permissions (e.g., they might be a standard user or have a role like User Administrator that lacks access review management capabilities).
Why User3 and User5? These users are likely assigned roles like Global Administrator or Identity Governance Administrator, which are explicitly authorized to manage access reviews in Entitlement Management.

Detailed Reasoning:
In Microsoft Entra ID, access reviews for access packages are configured within Entitlement Management. The ability to create and manage these reviews is restricted to specific administrative roles.
The Identity Governance Administrator role is designed for managing access packages, policies, and access reviews, making it a likely role for User3 and User5.
The Global Administrator role also has full permissions to perform these tasks.
Other roles, such as User Administrator or Application Administrator, may have limited permissions that don’t extend to managing access reviews for access packages.
Standard users or those without specific governance roles (likely User4) cannot create or manage access reviews.

References:
Microsoft Documentation: Create an access review of an access package
Microsoft Documentation: Azure AD roles for Entitlement Management
Microsoft Learn: Govern access with Microsoft Entra ID

Explanation:
If sales department users are unable to invite or collaborate with external (guest) users, the issue typically lies in Azure AD’s User settings — specifically, the configuration for external collaboration (guest user invitations).
In Microsoft Entra ID (formerly Azure AD), under User settings → External users → External collaboration settings, admins can control whether users can invite guests to the directory.
To resolve the issue, you need to enable guest user invitations for users or specific groups (e.g., allow members of the sales department to invite guests).

Why the Other Options Are Incorrect:
B. Device settings
Used for managing device join and registration (e.g., Azure AD join, device writeback). Not related to user invitation or guest access.
C. Access reviews settings
Controls review cycles for access to groups, apps, or roles. Doesn’t impact the ability to invite or collaborate with external users.
D. Security defaults
Enforces baseline security policies like MFA for admins and disabling legacy auth. Not related to guest invitation permissions.

Reference:
Microsoft Learn – Configure external collaboration settings in Microsoft Entra ID
Microsoft Learn – Manage who can invite guests

Explanation:
When "planned changes" for SSPR are implemented, it typically means moving from a default or less secure configuration to a more controlled and secure one. The standard, secure configuration mandated in such scenarios is:

1.Number of authentication methods required: 2
This is a core security best practice for password reset. Requiring two distinct methods of verification significantly reduces the risk of an unauthorized individual successfully resetting a user's password.
The user must successfully complete the challenge for two different methods (e.g., receive a code on their mobile phone and receive a code via email).

2.Authentication methods that can be used: This depends on User3's registered security info.
The specific methods presented to User3 during the reset flow are the intersection of two things:
a) Methods enabled in the tenant's SSPR policy. (The "planned changes" would have enabled a set of methods like Mobile phone, Email, and Mobile app notification).
b) Methods that User3 has previously registered. For example, if the policy enables Mobile Phone and Email, and User3 has registered both, they will see both as options. If they have only registered their mobile phone, they will only see that one method and will be unable to complete the reset because they cannot satisfy the requirement for 2 methods.

What actually occurs when User3 attempts SSPR:
The process is as follows:
User3 enters their username and passes the CAPTCHA challenge.
The Azure AD system checks the enforced policy, which requires 2 methods to reset.
The system then displays the available verification methods that User3 has registered. The user must successfully complete two of them to proceed with creating a new password.

Why this is the answer:
The "planned changes" are designed to enhance security, and moving from 1 method to 2 is the most direct and common way to achieve this in an SSPR context for the SC-300 exam. The available methods are a direct result of user registration.

Reference:
Microsoft Learn:
Combine security information methods for MFA and SSPR
Azure AD allows you to choose the number of methods required for a user to register for combined security information and the number required to reset their password or use multi-factor authentication. Requiring two methods increases the security of your tenant.

Explanation:
Number of methods required: Azure AD SSPR allows administrators to set a policy requiring a user to successfully complete 1 or 2 authentication methods to reset their password. The industry best practice and most common secure configuration is 2. The user must successfully respond to the challenges for this number of distinct methods.
Authentication methods that can be used:
A user can only use methods that meet two criteria:
Enabled by the Administrator:
The methods must be selected in the tenant's SSPR authentication methods policy (e.g., Mobile app notification, Mobile app code, Email, Mobile phone).
Pre-registered by the User:
The user must have previously set up data for those methods in their security info (e.g., they have a phone number configured for "Mobile phone" or an email address configured for "Email").
When User3 starts the reset process, Azure AD will present them with the challenge for the number of methods required (e.g., 2), pulling from the list of methods they have registered that are also enabled in the policy.

What if User3 hasn't registered enough methods?
If the question implied User3 had not registered methods compliant with the new policy, the result would be that User3 cannot reset their password and must contact an administrator. However, standard exam questions testing the implementation of a new policy assume the user is compliant to demonstrate the policy's successful application.

Reference
Microsoft Learn:
How it works: Azure AD self-service password reset
This document explains the user experience and how the policy is applied during a password reset.
Microsoft Learn:
Password reset registration
This explains the requirement for users to pre-register their authentication methods.