Lab 03: Practice Questions
Scenario-Based Questions
Question 1
Scenario: You create a Conditional Access policy with these settings:
- Users: All users
- Cloud apps: All cloud apps
- Conditions: None configured
- Grant: Block access
- Enable policy: On
What happens when you click Save?
A) All users except Global Admins are blocked
B) All users including your admin account are blocked immediately
C) Nothing - the policy won't save without an exclusion
D) Only guest users are blocked
Answer
B) All users including your admin account are blocked immediately
Explanation: This is the most dangerous Conditional Access mistake. There are NO automatic exclusions - not even for the person creating the policy or Global Admins. This will lock out your entire tenant.
Prevention: ALWAYS exclude a break-glass group before creating such broad policies.
Question 2
Scenario: A user has two Conditional Access policies that apply to them:
- Policy A: Require MFA
- Policy B: Require compliant device
Both policies target the same app. What must the user do to access the app?
A) Satisfy either Policy A OR Policy B
B) Satisfy both Policy A AND Policy B
C) Only the most recent policy applies
D) Only the policy with higher priority applies
Answer
B) Satisfy both Policy A AND Policy B
Explanation: When multiple policies apply, ALL requirements must be met. Conditional Access is cumulative - the user needs MFA AND a compliant device.
If one policy says "require MFA" and another says "block," then "block" wins because all conditions cannot be satisfied.
Question 3
Scenario: You want to block sign-ins from Russia, but your company has contractors in Russia who need access.
What is the BEST approach?
A) Don't create the country block policy
B) Create the block policy and exclude a group containing Russian contractors
C) Create the block policy and use named locations to whitelist contractor IPs
D) Tell contractors to use VPN to a different country
Answer
C) Create the block policy and use named locations to whitelist contractor IPs
Explanation:
- Create a Named Location with the contractors' office IP addresses
- Mark it as trusted if appropriate
- In the block policy, use Conditions → Locations → Exclude the contractor IPs
Option B would exclude contractors from ALL policies, not just the location block. Option D is a workaround, not a solution.
Question 4
Scenario: A policy is in Report-only mode. A user's sign-in shows "Report-only: Failure" in the Conditional Access tab.
What does this mean?
A) The user's sign-in was blocked
B) The user's sign-in succeeded but would have been blocked if policy was enabled
C) The policy has an error and couldn't be evaluated
D) The user doesn't have MFA registered
Answer
B) The user's sign-in succeeded but would have been blocked if policy was enabled
Explanation: Report-only mode allows sign-ins to proceed regardless of the policy result. It only LOGS what WOULD have happened. "Report-only: Failure" means the user would have been blocked or failed requirements if the policy was set to "On."
Use this to safely test policies before enforcement.
Question 5
Scenario: You want to require MFA for administrators, but only when they're accessing sensitive admin portals (Azure Portal, Microsoft 365 Admin Center).
How should you configure the Target Resources?
A) All cloud apps
B) Select apps → Microsoft Azure Management + Office 365
C) Select apps → Microsoft Azure Management + Microsoft 365 Admin Center
D) All cloud apps, then use Conditions to filter
Answer
B) Select apps → Microsoft Azure Management + Office 365
Explanation:
- Microsoft Azure Management = Azure Portal, CLI, PowerShell, ARM API
- Office 365 = Includes M365 Admin Center (admin.microsoft.com)
These are the service principal names that cover the admin experiences. "Microsoft 365 Admin Center" doesn't exist as a separate app - it's part of Office 365.
Question 6
Scenario: Your organization wants to block legacy authentication (IMAP, POP3, SMTP) because these protocols don't support MFA.
Which Client Apps condition should you configure?
A) Browser: Block
B) Mobile apps and desktop clients: Block
C) Exchange ActiveSync clients + Other clients: Block
D) All client apps: Block
Answer
C) Exchange ActiveSync clients + Other clients: Block
Explanation: Legacy authentication protocols are categorized as:
- Exchange ActiveSync clients - Older mobile email clients
- Other clients - IMAP, POP3, SMTP, older Office versions
Modern authentication (Browser, Mobile apps, Desktop clients) should NOT be blocked.
Select only the legacy options to block them while allowing modern apps.
Question 7
Scenario: You mark an IP range as a "trusted location" in Named Locations.
What does "trusted" actually do?
A) Automatically skips all Conditional Access policies
B) Nothing by itself - it's just a label for use in policies
C) Disables MFA requirements for that location
D) Adds the location to Microsoft's safe list
Answer
B) Nothing by itself - it's just a label for use in policies
Explanation: The "trusted" flag is a marker that you can use in policies, but it has no automatic effect. You must explicitly configure policies to treat trusted locations differently (e.g., exclude from MFA requirement).
It's also used by:
- Identity Protection (risk detection may exclude trusted locations)
- Some reporting features
Question 8
Scenario: A user is traveling and tries to sign in from a country where they've never signed in before. They have MFA set up. The sign-in fails with "Your sign-in was blocked."
You check and there's no policy blocking that country. What could cause this?
A) The user's password expired
B) Identity Protection detected high sign-in risk
C) The user's device is not compliant
D) The user exceeded sign-in attempt limits
Answer
B) Identity Protection detected high sign-in risk
Explanation: If you have Identity Protection with a policy that blocks high-risk sign-ins, an unusual location can trigger a risk alert. The sign-in is blocked even without a Conditional Access policy specifically for that country.
Check: Entra ID → Security → Identity Protection → Risk detections
Note: Identity Protection requires P2 license.
Question 9
Scenario: You create a policy requiring MFA for all cloud apps. Users report that MFA works in the browser, but the Outlook desktop app repeatedly prompts for credentials and then fails.
What is the most likely cause?
A) The policy doesn't apply to desktop apps
B) Outlook is using legacy authentication
C) The user's MFA registration is incomplete
D) There's a network connectivity issue
Answer
B) Outlook is using legacy authentication
Explanation: Older Outlook versions (2013 and earlier, or 2016 without updates) may use legacy authentication by default. Legacy auth doesn't support MFA, so the connection fails after the MFA requirement.
Solutions:
- Update Outlook to latest version
- Enable modern authentication via registry/group policy
- Or the legacy auth block policy will prevent these connections (forcing users to update)
Quick Knowledge Check
What license is required for Conditional Access?
Answer
Entra ID P1 or P2Can you create a policy that applies to a single user?
Answer
Yes - select specific users instead of "All users"What happens if two policies have conflicting grants (one requires MFA, one requires compliant device)?
Answer
User must satisfy BOTH requirementsHow long does it take for a new policy to take effect?
Answer
Almost immediately (within minutes), but token caching can delay full effect up to 1 hourCan Conditional Access block users during an active session?
Answer
Not immediately. Requires Continuous Access Evaluation (CAE) for near-real-time, or wait for token refresh (1 hour default)What's the difference between "Block" and requiring MFA with no method registered?
Answer
Block prevents access entirely. MFA requirement without registration allows the user to register during sign-in
Troubleshooting Scenario
A user reports: "I can sign in at home with MFA, but when I'm in the office, I'm still being asked for MFA even though you said we don't need it in the office."
Troubleshooting steps:
Solution Approach
Check Named Location:
- Is the office IP correctly entered?
- Is it marked as trusted?
- Did the IP range change (ISP update)?
Check Sign-in Logs:
- Find the user's sign-in from the office
- Check Location tab - what IP is detected?
- Check Conditional Access tab - which policy triggered MFA?
Check Policy Configuration:
- Is the correct Named Location excluded?
- Is there another policy requiring MFA that doesn't have the location exclusion?
Common Causes:
- IP address is different than expected (NAT, proxy)
- User on VPN that exits outside office
- Multiple policies, one without exclusion
- Named Location IP entered incorrectly (missing CIDR notation)