Scenario practice questions

location policy

Why it fails: A location policy is a named-locations container defining trusted IP ranges or countries; it holds no grant controls itself, so it cannot enforce MFA. It is tempting because named locations are central to the scenario, but the location policy is the correct component when merely defining which networks Conditional Access should treat as trusted.

Conditional Access policy targeting MFA registration

Why it fails: A policy targeting MFA registration governs enrolment in authentication methods, not access enforcement, so it cannot block cloud app sign-ins from untrusted networks. It is tempting because it relates to MFA, but it is the correct choice when requiring users to register methods before accessing resources.

OpenID Connect identity provider

Why it fails: The OpenID Connect option in the Microsoft Entra ID 'Add identity provider' pane is designed for custom OIDC-based enterprise identity providers such as Okta or Auth0, which you connect using a metadata endpoint, client ID, and client secret. It does not provide a pre-canned social login for Google, and manually wiring Google would require a conformant OIDC discovery document and custom claims mapping, which Google's consumer endpoints do not fully support. Thus it is not the correct method for allowing users to sign in with a Google personal account.

Microsoft account identity provider

Why it fails: Microsoft account (MSA) is a built-in consumer identity provider in Microsoft Entra ID and appears as a default option in External Identities, but it is not something you manually 'add' through the Add identity provider blade. When using that blade, you only create new custom providers; built-in providers like Microsoft account and Microsoft Entra ID are already present and cannot be created or duplicated. Therefore, choosing 'Microsoft account' as the provider to add is incorrect because it is not a newly added provider, and it would not bring in Google sign-in.

SAML/WS-Fed identity provider

Why it fails: The SAML/WS-Fed identity provider option is for federating with an enterprise identity provider that supports SAML 2.0 or WS-Federation, such as ADFS or a third-party corporate SSO solution, using an explicit federation metadata URL. It is not a social identity provider and cannot be used to let external users authenticate with Google personal accounts. Additionally, SAML/WS-Fed providers are used for B2B direct federation with organizations, not for consumer-facing social sign-in.

Microsoft Entra Connect

Why it fails: Microsoft Entra Connect is a directory synchronization tool that syncs on-premises Active Directory objects, including user attributes, password hashes, and group memberships, to Microsoft Entra ID for hybrid identity. It does not transport mailbox data such as email messages, calendar items, or contacts, and it cannot create or seed the Exchange Online mailbox. It is a necessary prerequisite for a hybrid migration, but it is not a data migration mechanism.

Third-party migration tool (e.g., BitTitan MigrationWiz)

Why it fails: Third-party products such as BitTitan MigrationWiz can migrate on-premises Exchange mailboxes and are often used for cross-tenant or complex coexistence scenarios. However, the question asks for a Microsoft-provided tool, and MigrationWiz is a paid external SaaS solution that requires separate licensing and deployment. For a straightforward 200-mailbox on-premises Exchange migration, the built-in EAC migration dashboard is the Microsoft-supported, no-additional-cost alternative.

IMAP migration

Why it fails: IMAP migration is designed for mail servers that expose the IMAP protocol, not for on-premises Exchange servers, which support MAPI, RPC-over-HTTP, and MRS endpoints. It can only sync email message items over IMAP, so calendar entries, contacts, tasks, and folder-level metadata are not migrated. It also lacks the granular batch controls and reporting that the EAC migration dashboard provides for a large mailbox migration.

Grant access requiring multi-factor authentication

Why it fails: Requiring MFA as an access condition does not explicitly identify or disable legacy authentication protocols. Because legacy clients such as Exchange Online PowerShell or Outlook basic auth cannot perform interactive modern authentication challenges, they would be denied access indirectly—but this grant control applies across all protocols and does not provide the granular 'Client apps' condition that directly blocks legacy auth traffic. The correct approach is to use the Client apps condition to block 'Other clients' and 'Exchange ActiveSync clients'.

Require compliant device

Why it fails: This grant control requires the client device to be marked as compliant by Intune (or another MDM), which typically requires the device to be enrolled and to have a compliance policy applied. However, many legacy authentication clients run on devices that are not enrolled or cannot report compliance state through basic auth; moreover, the control does not specifically target protocols—it evaluates the device state. Therefore it is unrelated to the protocol-level identification of legacy authentication and could block compliant modern clients while not explicitly preventing a legacy client on a noncompliant device from attempting basic auth (though the conditional grant would deny it).

Require approved client app

Why it fails: This grant control restricts access to apps that have been marked as approved by Microsoft, such as the latest Outlook mobile app. Legacy authentication protocols like POP/IMAP/Exchange ActiveSync are not recognized as approved client apps in Conditional Access, so they do not qualify under this control. However, the condition is intended to enforce app-based access for mobile or modern clients, not to create a protocol block; it also requires the app to support the Intune SDK or have app-based CA policies. Thus it is not a replacement for directly blocking legacy authentication via the Client apps condition.

Data Lifecycle Management retention policy

Why it fails: Data Lifecycle Management retention policies are designed to apply at the container level—for example, to an entire mailbox, folder, or Teams channel—and cannot evaluate the content of individual emails. They lack the ability to detect sensitive information types or other content patterns, so you cannot use one to target only emails containing PII. As a result, such a policy would either over-retain emails without PII or fail to capture the specific emails that need retention, making it incorrect for this content-based scenario.

Data classification

Why it fails: Data classification, such as the Content Explorer and activity explorer in Microsoft Purview, identifies and categorizes content based on sensitive information types and trainable classifiers, but it does not itself apply retention or deletion actions. Its purpose is visibility and governance; while it can inform the creation of a policy, the classification tool has no automated lifecycle enforcement capabilities. Therefore, using it alone will not cause qualifying emails to be retained for ten years and then deleted.

eDiscovery

Why it fails: eDiscovery is a search-and-hold tool built for legal, regulatory, and investigative scenarios; it can preserve content with a hold or export results, but it is not designed to automatically delete emails after a retention period. Placing an eDiscovery hold actually prevents deletion, which directly conflicts with the stated requirement to retain for ten years and then delete. It also does not continuously scan inboxes for sensitive information types to decide which messages to manage, so it is the wrong mechanism here.

Block Office applications from creating child processes

Why it fails: While blocking Office applications from creating child processes does mitigate many macro-based attacks and exploits like DDE where Office spawns PowerShell or cmd.exe, it does not address the underlying credential theft vector. An attacker who has already gained code execution on a device could directly access LSASS memory using an existing system process or a standalone credential-dumping utility, without needing Office to launch a child process. This rule therefore reduces one attack chain but leaves LSASS memory exposure unmitigated.

Block executable files from running unless they meet a prevalence, age, or trusted list criterion

Why it fails: This rule restricts execution of untrusted executables based on prevalence, age, or a trusted-list criterion, which is effective against unknown malware dropped by an initial intrusion. However, credential dumping from LSASS is often performed using built-in Windows tools or trusted binaries (such as comsvcs.dll) that meet prevalence or trusted-list criteria, or by injecting code into an already-running trusted process. Because it controls when executables launch rather than restricting existing processes from accessing LSASS memory, it fails to directly block the specific credential-stealing action.

Block Adobe Reader from creating child processes

Why it fails: This rule is narrowly scoped to Adobe Reader, preventing it from spawning child processes to stop PDF-based attacks that chain to other binaries. It has no bearing on LSASS credential theft because it neither restricts access to the Local Security Authority Subsystem nor covers the wide range of other processes (browsers, Office apps, or system utilities) that might be abused. A credential-dumping tool running as a standalone process or from an entirely different application would still be able to read LSASS memory, making this rule irrelevant to the investigation.

Seamless single sign-on.

Why it fails: Seamless single sign-on is an authentication method that silently signs users in when they are on domain-joined devices by presenting a Kerberos ticket, so they do not need to re-enter credentials. It does not include any password modification or writeback capability; it simply avoids prompting during sign-in. Therefore it cannot synchronize or return password changes from Microsoft Entra ID back to the on-premises directory.

Pass-through authentication.

Why it fails: Pass-through authentication validates a user's password by forwarding it from Microsoft Entra ID to the on-premises Active Directory for verification at sign-in time, but it never persists or propagates password changes. The validation is one-way: Microsoft Entra ID does not send updated passwords back to on-premises, and does not store the cloud password. Because the feature lacks any writeback mechanism, a cloud-initiated password reset would not affect the user's on-premises password.

Password hash synchronization.

Why it fails: Password hash synchronization copies a hash of the on-premises password to Microsoft Entra ID, enabling cloud authentication with the same password, but the flow is strictly one-way from on-premises to Microsoft Entra ID. If a user changes or resets a password in Microsoft Entra ID, that new password is not hashed and synchronized back to on-premises; password writeback is required for that reverse direction. Thus PHS alone cannot fulfill a requirement to propagate cloud password changes to the local Active Directory.

Session policy

Why it fails: Session policies apply real-time controls, not download thresholds.

App discovery policy

Why it fails: App discovery policies identify shadow IT apps.

OAuth app policy

Why it fails: OAuth app policies manage third-party app permissions.

Authorization code grant

Why it fails: The authorization code grant is an interactive OAuth 2.0 flow in which a resource owner signs in and consents, producing an authorization code that the app exchanges for tokens at the token endpoint. A background service runs with no browser, no redirect URI handler, and no signed-in user, so it cannot initiate the user-interactive consent step. Although refresh tokens can extend a session, the flow fundamentally depends on delegated user authorization and is therefore unsuitable for an unattended daemon.

Device authorization grant

Why it fails: Device authorization grant (device code flow) is meant for input-constrained devices such as smart TVs or IoT devices: the device receives a device code and user code, then instructs the user to open a browser on another device, sign in, and enter the code. It still requires a human to authenticate and grant consent interactively, and it results in delegated tokens tied to that user rather than application-only tokens. A background service running on a server has no such interactive user requirement and should instead authenticate itself with client credentials.

Implicit grant

Why it fails: Implicit grant is an OAuth 2.0 flow originally built for browser-based JavaScript SPAs, where the authorization server returns an access token directly in the URL fragment and no client secret is ever used. Because tokens are exposed in the browser history and can be intercepted, and because the flow cannot support the confidential application authentication expected of a daemon, it is fundamentally insecure and technically incompatible with a background service that must keep its credentials secret.

A litigation hold is applied to the data.

Why it fails: Litigation hold is a legal preservation mechanism that suspends deletion of all content in a mailbox or site, regardless of any retention policy. However, the question does not indicate that a litigation hold was placed on this data; it describes a retention policy outcome. If a retention policy with deletion were the only configured policy, the data would be deleted unless a hold actively overrides it. Therefore, while a litigation hold could cause items to remain, it is not the most direct or correct explanation here.

The retention policy is configured to retain data for 7 years and then delete it.

Why it fails: If the retention policy were configured to retain data for 7 years and then delete it, the system would irrevocably purge the items once the 7-year period elapsed and any holds were released. The persistence of the data after the retention period directly contradicts such a configuration. The fact that sensitive data remains indicates that the policy lacks the deletion action, not that it includes one. Thus, this option incorrectly describes the actual policy settings.

The data is marked as a record and requires disposition review.

Why it fails: Disposition review is an optional approval step that occurs only when a retention policy includes a deletion action at the end of the retention period. Marking data as a record with disposition review adds a workflow requiring user approval before deletion, but it does not change the underlying retention action. Since the correct explanation is that the policy has no deletion action, no disposition review would ever be triggered. Even if a record were under disposition review, that mechanism assumes deletion is configured—which is not the case here.

Phishing email with malicious link: Microsoft Defender for Office 365 Safe Attachments

Why it fails: Safe Attachments is designed to detonate attachment payloads, such as executables or macro-enabled documents, in an isolated sandbox to catch malware before it reaches the inbox. A phishing email with just a malicious link contains no attachment payload for the sandbox to analyze, and the danger occurs when the user clicks the URL. Therefore, using Safe Attachments would not protect against the link, which is why Safe Links is the correct service.

Accidental data leak via email: Microsoft Defender for Office 365 Safe Links

Why it fails: Safe Links is a URL reputation and time-of-click scanning service, so it has no awareness of the data classification or sensitivity of the message's content. An accidental data leak is a policy-driven governance problem where the risk is sensitive content leaving the organization, not a malicious destination or potential malware. Only Purview DLP can apply sensitive-information-type rules and remediation actions like blocking or encrypting the message, which is why Safe Links does not address this scenario.

Create an app discovery policy

Why it fails: An app discovery policy analyses shadow-IT usage from firewall and proxy logs, so it cannot read SharePoint Online file-download events or count them per user within a ten-minute window. It is tempting because discovery policies do identify unsanctioned cloud apps, which would be right when cataloguing unknown SaaS usage rather than alerting on sanctioned SharePoint activity.

Create a session policy

Why it fails: Session policies apply inline DLP and real-time controls to active user sessions, not threshold-based alerting on file downloads. Activity policies evaluate user actions against filters such as download volume and trigger alerts; this scenario requires exactly that. Session policy is the right choice when you must block or protect content during a live session.

Create an OAuth app policy

Why it fails: OAuth app policies govern permission grants and consent for connected applications, not user download volumes. They suit scenarios where a risky third-party app requests excessive scopes or an admin wants to revoke an app's access.

Attack Surface Reduction rules

Why it fails: Attack Surface Reduction rules are designed to prevent exploit techniques that originate on the host, such as blocking Office applications from creating child processes, executing macro payloads, or writing to removable drives. They do not inspect or filter TCP/IP packets or DNS queries destined for external endpoints, so they cannot interrupt an already active outbound communication channel. While they could block the initial compromise chain, they are ineffective once the device is compromised and needs network egress contained.

Session control in Defender for Cloud Apps

Why it fails: Session control in Defender for Cloud Apps operates as a reverse proxy for monitored SaaS applications, intercepting and applying conditional access policies at the HTTP/HTTPS session layer. It can restrict actions like downloads or uploads within a cloud app based on user and device risk, but it is transparent to traffic going to non-SaaS destinations and does not touch the bare network sockets or IP flows from the device. Thus, it cannot block an outbound connection from the system to a malicious endpoint regardless of the app involved.

Windows Firewall with Advanced Security

Why it fails: Windows Firewall with Advanced Security can indeed block outbound connections by creating rules for ports, programs, or IP address ranges, but it is not natively managed through the Microsoft 365 Defender portal. In a Windows domain, firewall policies are typically pushed via Group Policy, and in modern endpoint management via Configuration Manager or PowerShell, requiring separate, siloed administration. More importantly, it lacks the dynamic, cloud-sourced threat intelligence feeds that network protection uses, so its outbound rules are static and cannot automatically adapt to newly discovered malicious infrastructure during an incident.

Add a session control for sign-in frequency.

Why it fails: Sign-in frequency sets how often users must reauthenticate; it adds a session requirement rather than relaxing the compliant-device grant, so the block persists. It is the right control for enforcing periodic reauthentication on sensitive apps or admin portals.

Remove the cloudAppSecurity session control.

Why it fails: Cloud app security session controls govern in-session actions like download blocking, not device compliance; removing one leaves the compliant-device grant untouched, so users remain blocked. It is the correct control when you want to restrict downloads or monitor sessions on unmanaged devices.

Change cloudAppSecurityType to "blockDownloads".

Why it fails: BlockDownloads is a session control applied after access is granted; it cannot override the compliant-device grant that is denying access. It is the correct choice when you want unmanaged devices to view but not download Office 365 content, paired with a permissive grant.

The group is a mail-enabled security group, which is not supported for group-based licensing

Why it fails: Mail-enabled security groups are fully supported for Microsoft Entra ID group-based licensing. Microsoft Entra ID supports assigning licenses via security groups, mail-enabled security groups, and Microsoft 365 groups, so this group type would not prevent license assignment. If a licensing problem applied to the group type, no member would receive licenses, but here only some users are affected, so this is not the cause.

The license product name in the group setting does not match the available licenses in the tenant

Why it fails: If the product name or SKU specified in the group-based licensing settings was invalid or did not match an available license in the tenant, the group assignment would fail for every member, not just a subset. Microsoft Entra ID validates the SKU against the tenant's available license catalog before applying it. Since some users did receive licenses, the product name is correct and this is not the reason for the issue.

The users have not accepted the Microsoft Online Service Terms

Why it fails: Acceptance of the Microsoft Online Service Terms is an organization-level agreement, not an individual user prerequisite for license assignment. Group-based licensing applies licenses at the directory level without requiring end-user consent or acceptance. Therefore, a user not having accepted these terms would not block or skip a license assignment, so this cannot explain why only some users are missing the license.

Retention labels

Why it fails: Retention labels are designed for records management, not for content classification or access control. They govern how long content must be kept, when it should be permanently deleted, and whether disposition reviews are required, all based on regulatory or business rules. While they attach metadata to content, that metadata is focused on retention and deletion schedules, not on sensitivity or protection. Consequently, retention labels do not implement encryption, rights restrictions, or access policies, so they cannot fulfill the automatic classification requirement.

Data Loss Prevention (DLP) policies

Why it fails: DLP policies inspect content in motion and at rest to detect sensitive information types such as credit card numbers, bank account numbers, or national identifiers. When a match occurs, they can block sharing, warn users, or trigger incident reports, but they never write classification labels onto the content itself. DLP might even use sensitivity labels as a condition for its actions, yet the policy's role is enforcement and remediation, not classification. Therefore, a DLP policy alone cannot automatically classify documents; it only reacts to existing labels or detected sensitive data.

OpenID Connect

Why it fails: OpenID Connect (OIDC) is an authentication protocol built on OAuth 2.0 that enables a client to verify a user's identity via an ID token. It is widely used for single sign-on and depends on a centralized identity provider (IdP) to issue tokens, which means the IdP controls the identity lifecycle. In Verified ID, OIDC can be used for authentication in presentation flows, but it is not the decentralized identity technology; that role belongs to DIDs and verifiable credentials, which remove the need for a central authority.

OAuth 2.0

Why it fails: OAuth 2.0 is an authorization framework that allows an application to obtain limited access to a user's resources using access tokens, but it does not define any mechanism for decentralized identifiers or credentials. Its trust model is based on centralized authorization servers, registered scopes, and resource owners, which conflicts with the decentralized, self-sovereign model of Verified ID. Although OAuth tokens may appear in verification flows, OAuth is about delegated permission, not identity, making it categorically different from DIDs.

Security Assertion Markup Language (SAML)

Why it fails: SAML is a federated identity standard that exchanges XML-based assertions for authentication and authorization between parties, typically through a centralized identity provider. It enables single sign-on across domains but relies on pre-established trust relationships that are often centrally managed, and its assertions are not cryptographically tied to a decentralized identifier. The trust model is not designed for verifiable credentials, so SAML cannot provide the decentralized verification that Microsoft Entra Verified ID requires; instead, EC (or DIDs) serve that purpose.

Passwordless MFA

Why it fails: Passwordless MFA is a broader concept that includes Microsoft Authenticator with number matching, Windows Hello for Business, and even phone-based push prompts, none of which are inherently phishing-resistant. While FIDO2 keys are also passwordless, the standard 'Passwordless MFA' authentication strength in Entra ID does not require phishing-resistant methods, leaving room for push notification fatigue or SIM-swapping attacks. Therefore, selecting this option does not meet the strict phishing-resistant requirement.

Multifactor authentication

Why it fails: The generic Multifactor authentication option simply requires two or more factors, such as a password plus a TOTP code or a phone call, without mandating any phishing-resistant mechanism. These traditional MFA methods can be bypassed by adversary-in-the-middle (AiTM) phishing kits that relay one-time passcodes, and SMS-based verification is particularly vulnerable to interception or SIM-swapping. Because this option permits those weaker factors, it fails to provide the same level of protection as a dedicated phishing-resistant authentication strength.

No authentication strength

Why it fails: If No authentication strength is chosen, the Conditional Access policy uses the default Entra ID multifactor authentication flow, which allows many low-assurance methods like OATH tokens, phone calls, and Microsoft Authenticator push notifications. This configuration imposes no requirement for a phishing-resistant credential, meaning users can still complete sign-in using methods that are susceptible to MFA fatigue, SMS interception, or credential relay. Without an explicit authentication strength policy, the organization cannot ensure that the MFA performed is actually phishing-resistant.

Microsoft Entra B2B collaboration

Why it fails: Microsoft Entra B2B collaboration is a subset of External identities focused on inviting external business partners to collaborate on your enterprise apps. While it can be configured to accept social identity providers, its purpose is partner access and collaboration, not a general social-sign-in solution. Therefore, it does not match the described scenario as well as External identities.

Managed identities

Why it fails: Managed identities are service principals that Azure resources, such as virtual machines and Azure Functions, use to authenticate to Microsoft Entra-protected APIs and resources. They are machine identities, not user identities, and they cannot be used by end users to sign in with Google or Facebook. This makes them irrelevant to the question.

Microsoft Entra Identity Protection

Why it fails: Microsoft Entra Identity Protection is a risk-detection and automated-response service that analyzes sign-ins and users for threats like impossible travel, leaked credentials, and anomalous behavior. It operates on existing Microsoft Entra identities and does not provide identity federation or connect external social identity providers. Therefore, it is not the feature that supports social identity provider sign-in.

Microsoft Entra ID Free

Why it fails: Microsoft Entra ID Free does not include password writeback functionality.

Microsoft Entra ID P2

Why it fails: Premium P2 also includes writeback, but it is not the minimum required.

Microsoft 365 E3

Why it fails: Microsoft 365 E3 includes Microsoft Entra ID P1, but the license name is Microsoft Entra ID P1.