AZ-305 Practice Question: Design identity, governance, and monitoring solutions
You need to ensure that only authorized users can access the Azure portal. What should you use?
⚠ Common exam trap
Many exam-takers confuse authorization (what you can do after signing in, handled by RBAC) with authentication and access control (who can sign in, handled by Conditional Access), leading candidates to incorrectly choose Azure RBAC or PIM.
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
✓
Conditional Access policies
Conditional Access policies are the correct choice because they enforce access control decisions at the Microsoft Entra ID authentication layer, allowing you to require specific conditions (e.g., MFA, compliant device, trusted IP) before a user can sign in to the Azure portal. This directly ensures that only authorized users—those meeting the defined conditions—can access the portal, regardless of their role assignments. Azure RBAC controls what actions a user can perform after authentication, not whether they can sign in at all.
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 policies
Why this is correct
Conditional Access policies are Microsoft Entra ID policies that evaluate multiple signals—such as user and group membership, device compliance, location, and sign-in risk—before allowing access to the Azure portal. They can enforce multi-factor authentication, block access from high-risk geographies, or require hybrid-joined devices, thereby making the authorization decision at the authentication layer. This is the correct mechanism for ensuring only authorized users can access the portal, because it does not rely on resource-level permissions but on the user's identity and sign-in context.
- ✗
Azure RBAC
Why it's wrong here
Azure RBAC (Role-Based Access Control) governs what an already-authenticated user can do with Azure resources by assigning roles at management group, subscription, resource group, or resource scope. It operates only after the user has signed in and is entirely separate from the initial portal authentication. A user with even the lowest role such as Reader can still freely access the portal, so RBAC cannot enforce conditions like MFA, device state, or geographic restrictions that are needed to control portal access itself.
- ✗
Privileged Identity Management (PIM)
Why it's wrong here
Microsoft Entra Privileged Identity Management (PIM) provides just-in-time and time-bound activation for Microsoft Entra ID roles and Azure resource roles, with approval workflows, MFA on activation, and audit history. Its purpose is to minimize the standing privilege of administrators by requiring temporary elevation, not to act as a general gatekeeper for sign-in to the portal. Any non-privileged user is not subject to PIM constraints and can sign in at will; therefore, it does not address the broader requirement of ensuring only authorized users access the portal.
- ✗
Microsoft Entra ID Protection
Why it's wrong here
Microsoft Entra ID Protection uses machine learning and threat intelligence to detect risky sign-ins and potentially compromised users, assigning risk levels such as low, medium, and high. However, these detections do not, by themselves, enforce access decisions like blocking sign-in or requiring MFA; those actions must be enabled through Conditional Access policies that consume the risk signals. Identity Protection is best understood as a risk-detection and mitigation engine feeding other access controls, not as a standalone authorization mechanism that restricts portal access.
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-305 question is part of Courseiva's 795-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-305 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-305 exam.