Task 2.3: Manage risk by using Microsoft Entra ID Protection

• AA Conditional Access policy for sign-in risk High that requires multifactor authentication

  Incorrect

  Sign-in risk policies remediate risky sign-ins, not the user risk this requirement covers.

• BA Conditional Access policy for user risk High and all users, with the Require password change grant control

  Incorrect

  Passwordless users have no password to change, so they couldn't remediate their risk themselves.

• CA Conditional Access policy for user risk High with the Block access grant control

  Incorrect

  Blocking stops the risky users but leaves an administrator to remediate every one of them.

• DA Conditional Access policy for user risk High with the Require risk remediation grant control

  Correct

  ID Protection then picks the remediation per user: a secure password change, or session revocation for passwordless users.

Require risk remediation lets one Conditional Access user risk policy cover all authentication methods: users with passwords complete a secure password change after MFA, and passwordless users have their sessions revoked and reauthenticate. It applies an authentication strength and sign-in frequency Every time automatically. Require password change suits only users who have a password. The legacy risk policies in ID Protection were retired on October 1, 2026, so the replacement is a Conditional Access policy.

• ASign-in risk level High only

  Incorrect

  Microsoft recommends including both High and Medium sign-in risk.

• BSign-in risk levels High and Medium

  Correct

  These are the levels Microsoft's guidance selects for the policy.

• CThe Require password change grant control

  Incorrect

  Password change remediates user risk; sign-in risk is remediated with strong authentication.

• DPersistent browser session set to Always persistent

  Incorrect

  Keeping sessions alive works against reauthenticating risky sign-ins.

• EThe sign-in frequency session control set to Every time

  Correct

  Microsoft recommends forcing reauthentication for risky sign-ins.

Microsoft's guidance targets sign-in risk High and Medium, grants access after multifactor authentication or an authentication strength, and adds sign-in frequency Every time. A successful strong authentication is the only way to self-remediate sign-in risk; password change is a user risk control.

• ASelect Confirm user safe

  Incorrect

  Confirm safe marks a false positive and puts the user back into learning mode, which isn't what happened here.

• BSelect Dismiss user risk

  Correct

  Dismiss is for benign true positives such as a known penetration test; future activity is still evaluated.

• CSelect Confirm user compromised, then reset their passwords

  Incorrect

  Confirming compromise treats the authorized tests as a real attack on the accounts.

• DExclude the five accounts from every risk-based Conditional Access policy

  Incorrect

  Exclusions hide risk from policies but leave it on the accounts and remove their protection.

ID Protection offers Confirm compromised for true positives, Confirm safe for false positives and Dismiss for benign true positives, such as detections from a known penetration test. Dismissing removes the current risk while similar activity keeps being evaluated.

• ACreate a Conditional Access policy for workload identities that blocks Billing-Sync at high risk

  Incorrect

  Risk-based Conditional Access for workload identities needs Workload Identities Premium.

• BSelect Confirm compromised on the risky workload identity and keep the leaked secret for evidence

  Incorrect

  Confirming records the compromise but doesn't take the leaked secret away from the attacker.

• CAdd a certificate credential, move the job to it, then remove the leaked and other old secrets

  Correct

  Rotating credentials ends the attacker's access while the job keeps working on the new credential.

• DDismiss the workload identity's risk once the secret is deleted from the GitHub repository

  Incorrect

  Deleting the public copy doesn't invalidate the secret, which the attacker may already hold.

Microsoft's remediation for a risky workload identity is to inventory its credentials, add a new one (x509 certificates are recommended), remove the compromised ones and rotate Key Vault secrets the service principal can read. Risk-based Conditional Access for workload identities requires Workload Identities Premium.

• AMicrosoft Entra ID P2

  Correct

  ID Protection's key capabilities require P2 (or the Microsoft Entra Suite).

• BMicrosoft Entra ID Free

  Incorrect

  Free includes only limited risk information.

• CMicrosoft Entra ID P1

  Incorrect

  P1 covers Conditional Access but not ID Protection's risk policies and full reports.

• DMicrosoft Entra Workload ID Premium

  Incorrect

  This license adds workload identity features, not user risk policies.

Microsoft Entra ID Protection requires Microsoft Entra ID P2 licenses; the Microsoft Entra Suite also includes it. Workload Identities Premium is needed for risk-based Conditional Access on workload identities.

• AA real-time sign-in risk detection on the user's next sign-in

  Incorrect

  The leak isn't tied to a particular sign-in.

• BAn Anonymous IP address detection

  Incorrect

  That detection concerns sign-ins from anonymizing networks.

• CA Leaked credentials user risk detection

  Correct

  Leaked credentials raises the user's risk, not a sign-in's.

• DNo detection unless the user signs in from a new country

  Incorrect

  The leak itself raises risk, whatever the sign-in location.

Leaked credentials is a user risk detection: it indicates that the user's valid credentials were leaked, for example on the dark web or paste sites, and it raises user risk independently of any sign-in. Anonymous IP address is a sign-in risk detection.

• A7 days

  Incorrect

  Seven days is the Free retention.

• B30 days

  Incorrect

  Thirty days is the P1 retention.

• CIndefinitely

  Incorrect

  Risky users have no limit, but risky sign-ins do.

• D90 days

  Correct

  With P2, risky sign-ins are kept for 90 days.

Microsoft Entra keeps risky sign-ins for 7 days with Free, 30 days with P1 and 90 days with P2. Risky users have no retention limit and aren't deleted until the risk is remediated.

• ASelf-service password reset with two required methods

  Incorrect

  SSPR settings govern password reset, not a nudge toward stronger MFA.

• BA Conditional Access policy that blocks SMS sign-ins

  Incorrect

  Blocking SMS would stop users from signing in before they register a new method.

• CCombined security info registration with security questions required

  Incorrect

  Security questions don't count for MFA and don't replace SMS.

• DA registration campaign in the authentication methods policy

  Correct

  It nudges users who complete MFA with SMS or voice to set up a passkey or Microsoft Authenticator.

A registration campaign prompts users, after they complete interactive MFA with a weaker method such as SMS or voice call, to set up a passkey (FIDO2) or Microsoft Authenticator. You choose which users and groups the campaign includes or excludes.