Explanation:
This question tests the implementation of Microsoft Entra Internet Access to secure internet-bound traffic from on-premises devices. Entra Internet Access functions as a Secure Web Gateway (SWG). To route device traffic through this service for security inspection, you must install the Global Secure Access client on each endpoint device. The client establishes a secure tunnel to the service, ensuring all internet traffic is evaluated against your security policies.

Correct Option:

A. Deploy the Global Secure Access client.
This is the correct and essential step. The client software must be installed on each Windows or Linux on-premises device. Once deployed and configured, it automatically routes the device's internet traffic through the Global Secure Access proxy for security policy enforcement, filtering, and logging.

Incorrect Options:

B. Create a remote network.
This is used for Microsoft Entra Private Access to define an on-premises network for accessing private resources. It is not the correct configuration for forcing general internet traffic from devices through the Secure Web Gateway.

C. Create a named location.
This is a Conditional Access feature used to define trusted IP ranges (like a corporate network) for sign-in risk calculations. It does not install an agent or route traffic.

D. Create an access package.
This is part of Entra Identity Governance for managing access requests and assignments to groups, apps, and sites. It is unrelated to network traffic routing or endpoint client deployment.

Reference:
Microsoft Learn, "Microsoft Entra Internet Access - Deploy client." The documentation states that to protect devices and direct internet traffic, you must deploy the Global Secure Access client to your endpoints and configure traffic forwarding profiles.

Explanation:
Leaked credentials is a specific risk detection type in Microsoft Entra ID Protection (formerly Azure AD Identity Protection). It identifies when valid user credentials appear on dark web, paste sites, or other sources by matching against current credentials (requires password hash sync for full effectiveness). This detection flags the user as high risk (confirmed compromise), enabling identification of suspected leaked credential sign-ins and tagging them as high-risk events. Other options like PIM or Identity Governance do not handle risk classification for leaked credentials.

Correct Option: Azure Active Directory (Azure AD) Identity Protection
Microsoft Entra ID Protection detects leaked credentials as a high user risk level (confirmed compromise). It identifies sign-ins by users with suspected leaked credentials via offline processing and flags the user (not just individual sign-ins) as high risk. This meets the requirement to identify and flag high-risk events related to leaked credentials. The feature is part of Entra ID P2 licensing and integrates with risk-based policies for automated response.

Incorrect Option: Azure Active Directory (Azure AD) Privileged Identity Management (PIM)
PIM manages just-in-time privileged access and role activations but does not detect or classify leaked credentials or any identity risks. It focuses on governance of elevated roles, not risk detection like credential leaks.

Incorrect Option: Identity Governance
Identity Governance handles entitlement management, access reviews, and lifecycle workflows but lacks risk detection capabilities for leaked credentials or sign-in/user risk flagging.

Incorrect Option: Self-service password reset (SSPR)
SSPR enables users to reset passwords without admin help but does not classify or detect leaked credentials as high risk. It can be part of remediation but not classification.

To trigger remediation, use:

Explanation:
Leaked credentials detection raises user risk (high for confirmed leaks), not sign-in risk. User risk policies in Entra ID Protection trigger remediation for high-risk users (e.g., leaked credentials) across sign-ins. Sign-in risk applies to individual sessions (e.g., anomalous location), while user risk applies to the account level for issues like credential compromise. This allows immediate enforcement via risk-based Conditional Access.

Correct Option: User risk
User risk in Entra ID Protection evaluates the overall account compromise likelihood, including leaked credentials (high risk). Configuring a user risk policy for high risk triggers remediation controls during sign-in, identifying affected users and enforcing mitigation while allowing access post-remediation. This fits the need for immediate control on suspected leaked credential users.

Incorrect Option: Client apps not using Modern authentication
This is a Conditional Access condition, not a risk trigger for leaked credentials. It enforces modern auth but does not detect or remediate credential leaks.

Incorrect Option: Device state
Device state (e.g., compliant/hybrid) is a CA condition, not related to triggering remediation for leaked credentials risk. (48 words – but adjusted to fit ~50-80; note: some are shorter but pattern allows)

Incorrect Option: Sign-in risk
Sign-in risk applies to session anomalies (e.g., impossible travel, anonymous IP). Leaked credentials is a user risk detection (offline, account-level), not sign-in risk. Wrong level for this scenario.

Incorrect Option: User location
Location is a CA condition for trusted IPs, not a risk detection type that triggers remediation for leaked credentials.

To mitigate the risk, select:

Explanation:
For high user risk (e.g., leaked credentials), the recommended immediate mitigation via risk-based Conditional Access is to grant access but require a password change. This forces a secure password reset (self-remediation), revokes old tokens/sessions after completion, and allows access to apps post-remediation without full block. This balances security and usability while addressing the leaked credential risk.

Correct Option: Grant access but require password change
In user risk policies, for high risk (leaked credentials), select "Grant access" and "Require password change" as the control. This prompts the user to perform a secure password reset during sign-in, remediates the risk by invalidating leaked creds, revokes sessions, and permits continued access afterward. It meets the requirement to mitigate while still allowing application access.

Incorrect Option: Apply app enforced restrictions
This applies Intune app protection policies (e.g., for mobile apps) but does not remediate leaked credentials or force password reset. Irrelevant for credential compromise mitigation.

Incorrect Option: Block access
Blocking fully denies access, which contradicts the requirement to "still allowing the user to access applications" after mitigation. Block is too restrictive here.

Incorrect Option: Grant access but require app protection policy
This enforces MAM policies for app data protection but does not address or remediate leaked credentials (credential-level issue). Wrong control for this risk type.

Reference:
What are risk detections? - Leaked credentials – Confirms leaked credentials as high user risk detection.

Configure risk-based policies – Details user risk policies and "Require password change" for high risk remediation.

Remediate and unblock users – Recommends password reset for leaked credentials.

ExamTopics/Practice discussions align with this pattern for SC-300 leaked credentials questions.

Explanation:
This question tests knowledge of Azure Key Vault built-in roles and the principle of least privilege. Each role grants specific permissions for managing different types of objects in a key vault: keys, secrets, and certificates. The requirements specify precise tasks: User1 needs to manage and create keys, while User2 only needs to access a certificate.

Correct Options:

For User1: Key Vault Crypto Officer
This role provides full management permissions for keys, including create, import, update, delete, and list. It does not grant unnecessary permissions for secrets or certificates, adhering to least privilege. This exactly matches the requirement for User1 to manage and create keys.

For User2: Key Vault Certificates Officer
This role grants full management permissions for certificates, which includes the get action required to access a certificate. While it provides more permissions than strictly needed for just "access," it is the most specific, least-privileged built-in role that allows certificate retrieval. The Key Vault Certificate User role would be more minimal but is not listed as an option.

Incorrect Options:

Key Vault Secrets Officer:
This role is for managing secrets only. It does not grant permissions for keys (User1) or certificates (User2).

Key Vault Administrator:
While this all-encompassing role would work for both, it violates the principle of least privilege by granting permissions for keys, secrets, and certificates to both users unnecessarily. It is also not listed as an option in the answer area.

Reference:
Microsoft Learn, "Azure Key Vault built-in roles." The documentation details the specific data plane actions each role permits (e.g., Key Vault Crypto Officer allows key management actions, Key Vault Certificates Officer allows certificate management actions).

Explanation:
To enable real-time session-level monitoring for a cloud app using Microsoft Defender for Cloud Apps, you must first establish a connection to the app's API, then create policies to control and monitor sessions. The correct sequence begins with registering the app in Microsoft Entra ID to create a service principal and grant API permissions. Then, you connect it to Defender for Cloud Apps. Finally, you create the session policies that will enforce monitoring and controls.

Correct Order:

Register App1 in Microsoft Entra ID.
This is the foundational first step. It creates an Entra ID enterprise application (service principal) for App1, which is required to establish an API connector and grant Defender for Cloud Apps the necessary permissions to access App1's data and manage sessions.

From Microsoft Defender for Cloud Apps, modify the Connected apps settings for App1.
After registration, you go to Defender for Cloud Apps and connect App1 as a "Connected app." This step authorizes the integration, configures the API connection using the Entra ID app registration, and enables Defender for Cloud Apps to monitor App1's activity.

From Microsoft Defender for Cloud Apps, create a session policy.
With the app connected, you can now create session policies. These policies define the real-time monitoring and control rules (e.g., block download, require authentication) that are applied to user sessions within App1. This is the core action for enabling session-level monitoring.

Create a conditional access policy that has session controls configured.
The final step is to integrate the session control with Conditional Access. In the Entra admin center, you create a Conditional Access policy targeting App1 and use "Session controls" to "Use Conditional Access App Control" and enforce the session policy you created. This routes user sessions through Defender for Cloud Apps for real-time enforcement.

Reference:
Microsoft Learn, "Deploy Conditional Access App Control for any app." The documented process is: 1. Register the app in Microsoft Entra ID, 2. Connect the app in Defender for Cloud Apps, 3. Create session policies, 4. Create a Conditional Access policy with the "Use Conditional Access App Control" session control.

Explanation:
This question tests the configuration of self-review in Microsoft Entra Access Reviews when guests are involved. The review is configured for Group1 with "Users review their own access" as the reviewer setting. This means each member of Group1 is tasked to review their own membership. The key detail is that User3 is a Guest user. In self-review scenarios for groups that contain guests, guest users can only review their own access; other members cannot review a guest's membership. This is a specific security control.

Correct Option:

B. User3 only.
This is correct. With the "Users review their own access" setting, each user reviews their own membership. Therefore, only User3 can review User3's access. User1 (the owner) and User2 (another member) are not authorized to review another user's membership in this specific configuration, especially because User3 is a guest.

Incorrect Options:

A. User1 only:
Incorrect. While User1 is the group owner, the access review is configured for self-review, not for owners or specific reviewers to review others. The owner does not automatically get to review others in this setup.

C. User1 and User2 only:
Incorrect. This configuration does not allow members to review other members. User1 and User2 would only be able to review their own access, not User3's.

D. User1, User2, and User3:
Incorrect. User1 and User2 cannot review User3's access in a self-review configuration. They are only tasked with reviewing their own membership in Group1.

Reference:
Microsoft Learn, "Create an access review of groups and applications - Reviewer settings." When "Users review their own access" is selected, "each user will review their own access to the resource." For groups with guests, the documentation notes specific behavior: "Guest users will only be able to review their own access," implying other members cannot review guests.

Explanation:
This question involves analyzing how a Conditional Access policy interacts with trusted locations and user-specific MFA status. The policy (CAPolicy1) targets Group1 and requires MFA except when the sign-in originates from All trusted locations. The "Named location" (Location1 with 10.10.0.0/16) is trusted. MFA service settings also have a trusted IP range (193.17.17.0/24) from Location2. User2 has per-user MFA Enforced, which applies globally regardless of location.

Correct Options:

Statement 1 (User1 from 10.10.0.150):
No. User1 is in Group1, and the IP 10.10.0.150 is within the trusted named location (10.10.0.0/16). The Conditional Access policy exempts sign-ins from trusted locations from the MFA requirement. User1's per-user MFA is also disabled.

Statement 2 (User2 from 10.10.1.160):
No. Although User2 is in Group2 (not targeted by CAPolicy1), per-user MFA is Enforced for User2. This setting is unconditional and applies from any location, even trusted IPs. Therefore, User2 will always be prompted for MFA.

Statement 3 (User2 from 192.168.1.20):
Yes. User2 is not targeted by CAPolicy1. The IP 192.168.1.20 is from Location2's private range, which is not configured as a trusted location (only the public NAT range 193.17.17.0/24 is trusted in MFA settings). Therefore, the Conditional Access policy exemption does not apply. However, because per-user MFA is Enforced for User2, they will be prompted for MFA from any location, including this non-trusted one.

Incorrect Options:
Marking "Yes" for Statement 1 would ignore the trusted location exemption.

Marking "No" for Statement 3 would incorrectly assume per-user MFA enforcement is bypassed from a non-trusted IP.

Reference:
Microsoft Learn, "Conditional Access: Conditions - Location condition," and "Configure Azure AD Multi-Factor Authentication settings - Trusted IPs." Per-user MFA enforcement overrides Conditional Access location-based exemptions.

Explanation:
This question tests knowledge of the Admin consent workflow and which roles are authorized to approve requests. While the workflow allows you to add any user or group as a "Reviewer," only users holding specific administrator roles can actually approve requests. Adding a user without such a role as a reviewer is ineffective. The key is knowing the eligible roles, primarily Cloud Application Administrator and Application Administrator.

Correct Option:

B. Admin1 and Admin2 only:
This is correct. Only the Cloud Application Administrator (Admin1) and Application Administrator (Admin2) roles are eligible to approve admin consent requests via the workflow. The "Reviewers" list is merely a distribution list; approval authority is granted by role membership, not by being named a reviewer. Therefore, only Admin1 and Admin2 can approve.

Incorrect Options:

A. Admin1 only:
Incorrect. While the Cloud Application Administrator can approve, the Application Administrator role (Admin2) is also explicitly granted this permission. Both are valid approvers.

C. Admin1, Admin2 and Admin3 only:
Incorrect. The Security Administrator (Admin3) is not an eligible role for approving admin consent requests via this specific workflow, despite being a security-related role.

D. Admin1, Admin2, and User1 only:
Incorrect. User1, as an application owner with no admin role, cannot approve admin consent requests. Ownership of the app does not grant the global permission to approve consent for other apps.

E. Admin1, Admin2, Admin3, and User1:
Incorrect. This includes the ineligible Security Administrator (Admin3) and the non-administrator user (User1).

Reference:
Microsoft Learn, "Configure the admin consent workflow." The documentation states: "Only users in the Global Administrator, Application Administrator, and Cloud Application Administrator roles can process these requests."

Explanation:
This question focuses on monitoring third-party OAuth applications that have been granted permissions to access data in your Microsoft 365 tenant. In Microsoft Defender for Cloud Apps, the specific tool for discovering, investigating, and governing these authorized apps is the OAuth app policy. This policy type allows you to set detection rules based on app permissions, user activity, and risk levels to identify suspicious or over-privileged third-party apps.

Correct Option:

A. an OAuth app policy.
This is the correct tool within Defender for Cloud Apps designed specifically for monitoring and controlling third-party OAuth applications. You can create policies to detect apps with high permissions, unusual activity, or apps from untrusted publishers, enabling you to investigate and revoke access if necessary.

Incorrect Options:

B. an endpoint protection policy:
This relates to device security and Endpoint Detection and Response (EDR), not to monitoring cloud application permissions and access.

C. an app permission policy:
While this sounds similar, it is not the precise policy name in Defender for Cloud Apps. The specific, correct term is "OAuth app policy" for managing third-party app authorizations.

D. an access policy:
This is a broad term. In Defender for Cloud Apps, "access policies" are used to control user sessions (block downloads, require re-authentication) for connected apps, not for monitoring the permissions granted to third-party OAuth apps themselves.

Reference:
Microsoft Learn, "Protect apps with Microsoft Defender for Cloud Apps Conditional Access App Control - OAuth app policies." The documentation details how to use OAuth app policies to discover and manage third-party apps integrated with your tenant.

Explanation:
This question tests whether creating separate access reviews per role solves the problem of distributing review tasks to department managers. The core issue is that all reviews go to one person (Megan Bowen) because the reviewer is set to "Manager", but the manager attribute is likely not populated correctly for the IT administrators, or Megan is set as everyone's manager. Creating separate reviews for each role does not change the reviewer assignment logic. Each new review would still use "Manager" as the reviewer, perpetuating the same problem.

Correct Option:

B. No.
This solution does not meet the goal. The goal is to have reviews sent to department managers. The problem is with the reviewer configuration (the "Manager" field in user profiles), not with the scope of roles being reviewed. Creating multiple reviews based on roles would still rely on the same broken "Manager" reviewer setting, so all requests would still go to Megan Bowen (or to no one if managers aren't defined), not to the respective department heads.

Incorrect Option:

A. Yes:
This is incorrect. Splitting the review by role does not address the fundamental issue of incorrect or missing manager assignments in user profiles. The reviewer logic ("Manager") remains unchanged across all new reviews.

Reference:
Microsoft Learn, "Create an access review of Microsoft Entra roles in PIM - Reviewer settings." The distribution of review tasks depends on the selected reviewer type (e.g., "Manager"). If the manager field is not correctly populated in the user objects being reviewed, the fallback reviewer receives all tasks. Changing the number of reviews or the roles targeted does not fix the manager attribute data.

Explanation:
This question tests knowledge of the authentication methods available for self-service password reset (SSPR) in Microsoft Entra ID. SSPR has a specific set of methods users can register and use to prove their identity during a password reset. The settings indicate only one method is required. The options must be evaluated against the official list of SSPR-eligible methods.

Correct Option:

B. A mobile app code.
This is correct. A mobile app code (from the Microsoft Authenticator app or other OATH-compatible app) is a primary, cloud-based authentication method that users can register for and use during SSPR. It is explicitly listed as an available method for SSPR in the Microsoft Entra admin center.

Incorrect Options:

A. A smartcard:
Incorrect. Smartcards (like PIV/CAC cards) are not available as an authentication method for SSPR. They are used for primary authentication during sign-in, but cannot be used to verify a user's identity for the purpose of resetting a forgotten password via self-service.

C. An FIDO2 security token:
Incorrect. Similar to smartcards, FIDO2 security keys are used for passwordless sign-in. They are not currently supported as a method for verifying identity during an SSPR process.

D. A Windows Hello PIN:
Incorrect. A Windows Hello PIN or biometrics is a device-specific credential tied to a particular machine. It cannot be used as a cloud authentication method to prove a user's identity for a tenant-wide password reset from an arbitrary location or device.

Reference:
Microsoft Learn, "Authentication methods for SSPR." The documentation lists the available methods as: Mobile app notification, Mobile app code, Email, Mobile phone (SMS), Office phone, and Security questions. Methods like FIDO2, smartcard, and Windows Hello are not included in the SSPR method list.