How are multiple Conditional Access policies evaluated when more than one applies to a sign-in?
All applicable policies are evaluated. If ANY policy blocks, access is denied (block always wins). If no policy blocks, ALL grant controls from ALL matching policies must be satisfied. Grant controls are merged/summed across policies.
Policy A requires MFA. Policy B requires compliant device. Both match a sign-in. What must the user provide?
Both MFA AND a compliant device. Grant controls from multiple matching policies are cumulative. The user must satisfy every control from every matching policy.
Policy A blocks access from outside the country. Policy B grants access with MFA from anywhere. A user signs in from abroad. What happens?
Access is BLOCKED. If any matching policy blocks, block always wins regardless of what other policies grant. There are no exceptions to this rule.
What is the difference between ‘Require one of the selected controls’ and ‘Require all the selected controls’?
‘Require one’ (OR): user satisfies ANY one of the listed controls (e.g., MFA OR compliant device). ‘Require all’ (AND): user must satisfy EVERY listed control (e.g., MFA AND compliant device). Default is AND.
What are all the available grant controls in Conditional Access?
Block access, Require MFA, Require authentication strength, Require device compliant (Intune), Require Entra hybrid joined device, Require approved client app (retiring March 2026), Require app protection policy, Require password change, Require Terms of Use.
What is authentication strength in Conditional Access?
Allows admins to require specific authentication method combinations instead of just ‘MFA’. Built-in: MFA strength, Passwordless MFA strength, Phishing-resistant MFA strength. Custom strengths can be defined with specific method combinations.
A policy requires ‘Require compliant device’. A user on an unmanaged personal laptop completes MFA. Is access granted?
No. The policy specifically requires a compliant device (managed by Intune with passing compliance policy). MFA alone does not satisfy a device compliance requirement. The device must be enrolled and marked compliant.
How are assignments within a single Conditional Access policy logically combined?
All assignment sections are combined with AND logic. Users AND Cloud apps AND Conditions must all be true for the policy to apply. Within each section, multiple selections are combined with OR (e.g., user in Group A OR Group B).
A policy targets ‘All users’ and excludes ‘Group_Admins’. User1 is in Group_Admins. Does the policy apply?
No. Exclusions override inclusions. User1 is excluded because they are in Group_Admins, even though ‘All users’ includes them.
Can Conditional Access target specific Azure resources like a single storage account or VM?
No. CA targets cloud apps or user actions. You can target ‘Microsoft Azure Management’ (covers Azure portal, CLI, PowerShell, ARM API) but not individual resources. For resource-level control, use Azure RBAC and resource firewalls.
What does the ‘Microsoft Azure Management’ cloud app cover in Conditional Access?
Azure portal (portal.azure.com), Azure PowerShell, Azure CLI, Azure Resource Manager API, Azure mobile app. A CA policy targeting this app affects ALL Azure management activities through these clients.
What does the ‘Office 365’ cloud app cover vs. selecting individual Office apps?
‘Office 365’ is a meta-app that includes Exchange Online, SharePoint Online, Teams, and other O365 services. Selecting individual apps gives finer control. Selecting Office 365 applies the policy to all O365 services at once.
What sign-in risk levels can be used as conditions?
No risk, Low, Medium, High. Requires Entra ID P2. Configure: if sign-in risk is Medium or High â require MFA. Common risks: anonymous IP, atypical travel, malware-linked IP, unfamiliar properties, password spray, token anomaly.
What user risk levels can be used as conditions?
No risk, Low, Medium, High. Requires Entra ID P2. Configure: if user risk is High â require secure password change + MFA. Common risks: leaked credentials, anomalous user activity, suspicious API traffic.
What client app types can be used as conditions?
Browser, Mobile apps and desktop clients, Exchange ActiveSync clients, Other clients (legacy auth: POP, IMAP, SMTP, older Office). Default: all client apps. To block legacy auth, target ‘Other clients’ with Block access.
How do device platform conditions work?
Filter by: Android, iOS, Windows, macOS, Linux. Based on user-agent strings (not verified). Best practice: create policies for supported platforms, then a separate policy blocking ‘Any device’ excluding supported platforms.
User signs in from a trusted Named Location but their user risk is High. Policy 1: exclude trusted locations from MFA. Policy 2: require password change for high user risk. What happens?
Policy 1 does NOT apply (trusted location excluded). Policy 2 DOES apply (high user risk). User must change password. These are independent policies evaluating different conditions.
You want to allow access to Exchange Online only from compliant iOS/Android devices OR from corporate network. How do you configure this?
Create two policies: Policy 1: target Exchange Online, condition = mobile platforms, grant = require compliant device. Policy 2: target Exchange Online, condition = ANY location except corporate network + desktop platforms, grant = block. Or: single policy with require compliant device OR trusted location.
A legacy mail client (POP3) attempts to sign in. Your policy requires MFA for all users. What happens?
The sign-in is BLOCKED. Legacy auth clients cannot complete MFA. When a CA policy requires MFA and the client uses legacy auth, the sign-in fails. This is why you should explicitly block legacy auth with a dedicated policy.
What is the Conditional Access What If tool?
A testing tool that simulates a sign-in with specified parameters (user, app, location, device, risk) and shows which policies would apply and their results. Found in Entra ID > Security > Conditional Access > What If. Essential for troubleshooting.
What does ‘Sign-in frequency’ session control do?
Forces users to re-authenticate after a specified time period (e.g., every 8 hours). Overrides the default token refresh behavior. Useful for sensitive apps. Setting of ‘Every time’ forces re-auth on every access.
What does ‘Persistent browser session’ control do?
Controls whether users stay signed in after closing and reopening the browser. ‘Never persistent’ forces re-auth on new browser sessions. ‘Always persistent’ allows Remember Me. Overrides the ‘Stay signed in?’ prompt behavior.
Describe the complete NSG evaluation flow for inbound traffic to a VM.
1) Traffic hits subnet NSG first â evaluated against inbound rules by priority (lowest number first). 2) If subnet NSG allows, traffic then hits NIC NSG â evaluated against its inbound rules. 3) BOTH must allow. If either denies, traffic is dropped. 4) If no rule matches, default DenyAllInBound (65500) applies.
Describe the complete NSG evaluation flow for outbound traffic from a VM.
1) Traffic hits NIC NSG first â evaluated against outbound rules by priority. 2) If NIC NSG allows, traffic then hits subnet NSG â evaluated against its outbound rules. 3) BOTH must allow. Outbound is NIC first, then subnet (opposite of inbound).