Three Key Capabilities of Microsoft Entra ID Protection
Which TWO of the following are capabilities of Microsoft Entra ID Protection?
⚠ Common exam trap
It's easy for candidates to confuse the risk-based policies of Entra ID Protection (sign-in risk and user risk) with Conditional Access session controls or other Entra ID features like Access Reviews and RBAC, because all are part of the broader Entra ID suite but serve distinct functions.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Sign-in risk policy
Microsoft Entra ID Protection is specifically designed to detect identity-based risks and let administrators respond to them via two built-in policies: the sign-in risk policy (B), which evaluates each authentication attempt and can require MFA or block the sign-in when the sign-in is deemed risky, and the user risk policy (C), which evaluates the overall risk of a user account (for example, from leaked credentials) and can force a secure password change. Both B and C are core, out-of-the-box capabilities of Entra ID Protection and are configured directly in its Risk policies blade. Conditional Access session controls (A) are a feature of Conditional Access (sign-in frequency, app-enforced restrictions, Cloud App Security/Defender for Cloud Apps controls), not of ID Protection itself, even though risk signals can feed Conditional Access. Access reviews (D) belong to Entra ID Governance (Identity Governance), and role-based access control (E) is the general authorization model used across Azure and Entra ID, not a risk-detection capability of ID Protection.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Conditional Access session controls
Why it's wrong here
Conditional Access session controls operate at the access-request stage by limiting sign-in context — e.g., sign-in frequency, persistent browser session, or app-enforced restrictions — after successful authentication. They are a Conditional Access feature, not a Microsoft Entra ID Protection capability. ID Protection specifically focuses on risk detection and automated remediation, whereas session controls manage the post-authentication experience rather than evaluating sign-in risk.
- ✓
Sign-in risk policy
Why this is correct
Sign-in risk policy is a native Microsoft Entra ID Protection capability that automates responses to risky sign-in events. It evaluates real-time and offline risk detections (like impossible travel, anonymous IP addresses, or atypical sign-in behavior) and triggers actions such as requiring multi-factor authentication or blocking access. This policy is part of the risk-based protection model, not a generic access control, and is explicitly distinct from session controls or governance features.
- ✓
User risk policy
Why this is correct
User risk policy is another core ID Protection feature, addressing the overall risk level of a user account rather than a single sign-in. It aggregates risk signals like leaked credentials or anomalous activity to assign an ongoing user risk score. When the policy is triggered, it can enforce actions such as password reset or account block, directly protecting identities from compromise. This differentiates it from sign-in risk policy, which targets individual authentication events.
- ✗
Access reviews
Why it's wrong here
Access reviews are a feature of Microsoft Entra Identity Governance, not ID Protection. They enable admins to periodically review and confirm users' group memberships, application access, and role assignments, helping to reduce excessive access and meet compliance requirements. While governance supports security posture, it does not detect real-time risk or automate threat responses, which are the primary functions of ID Protection. Thus, access reviews are outside the scope of ID Protection capabilities.
- ✗
Role-based access control (RBAC)
Why it's wrong here
Role-based access control (RBAC) is a fundamental authorization model used to assign granular permissions to users, groups, and service principals based on role definitions. It ensures least privilege by restricting who can perform specific actions, but it does not analyze risk signals or respond to suspicious activities. RBAC is an underlying access-control mechanism in Entra ID, not a protection capability offered by ID Protection, which focuses on detecting identity compromise and automating mitigations.
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
About these practice questions
This AZ-500 question is part of Courseiva's 617-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-500 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-500 exam.