An identity team is preparing a tenant-wide Conditional Access policy that will require phishing-resistant multifactor authentication for every user signing in to all cloud apps. The tenant keeps two cloud-only emergency access accounts that must never be locked out by the policy, and the team must confirm the policy's real-world impact before any user is actually challenged. Which TWO configuration steps should the team apply before enforcing the policy? Select TWO.
- AAdd the two emergency access accounts to the Users assignment exclusion so the grant control is never evaluated against those break-glass accounts. Correct
- BSet the policy state to report-only so sign-in logs record how the policy would evaluate for each sign-in without enforcing the grant control on users. Correct
- CEnable security defaults alongside the policy so the tenant gains a baseline multifactor requirement while the new Conditional Access policy is validated.
- DAdd a trusted named location to the policy conditions so sign-ins from the corporate network bypass the phishing-resistant requirement during validation.
Why A is correct: Excluding the emergency accounts in the Users assignment keeps them outside the grant control, so a misconfigured phishing-resistant requirement can never lock the tenant out of recovery.
Why B is correct: Report-only mode evaluates the policy and writes the would-be result to the sign-in logs while granting access normally, letting the team measure impact before turning enforcement on.
Why C is wrong: Security defaults cannot run while custom Conditional Access policies are enabled, and they offer no exclusions or report-only evaluation, so they neither protect break-glass accounts nor measure impact.
Why D is wrong: A trusted named location only changes which sign-ins the grant applies to and does nothing to protect emergency accounts or to capture the policy's impact before enforcement.