Scenario practice questions

Add a session control for sign-in frequency.

Why wrong: This does not remove the device compliance requirement.

Remove the cloudAppSecurity session control.

Why wrong: This does not remove the device compliance requirement.

Change cloudAppSecurityType to "blockDownloads".

Why wrong: This is a session control, not a grant control.

Azure AD Connect

Why wrong: Azure AD Connect is a directory synchronization tool that syncs on-premises Active Directory objects, including user attributes, password hashes, and group memberships, to Azure AD 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Modify the sensitivity label policy to include the footer.

Why wrong: Label policies publish labels; the label itself contains the settings.

Create a DLP rule that applies the footer and encryption.

Why wrong: DLP rules do not apply markings or encryption directly.

Set up auto-labeling to apply the footer and encryption.

Why wrong: Auto-labeling is for automatic application, not manual.

Microsoft Teams admin center

Why wrong: Teams admin center does not migrate data.

Exchange Admin Center migration tools

Why wrong: Only covers email migration.

Authorization code grant

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Attack Surface Reduction rules

Why wrong: 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 wrong: 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 wrong: 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.

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

Why wrong: Mail-enabled security groups are fully supported for Azure AD group-based licensing. Azure AD 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 wrong: 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. Azure AD 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 wrong: 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.

Enable domains to protect against impersonation

Why wrong: This setting protects an entire domain from being impersonated in the From header, but it does not flag a sender who simply mimics a specific executive's display name or email alias while using an unrelated domain. Impersonation of high-value individuals is usually based on the user identity (e.g., 'CEO Jane Doe') rather than the domain, so this option fails to catch attacks that target a named user. It also cannot be scoped to individual protected mailboxes, which is exactly what the scenario requires.

Mailbox intelligence

Why wrong: Mailbox intelligence leverages machine learning to baseline a user's normal email behavior and then flags anomalies such as unusual sending patterns or a compromised account sending bulk mail. It does not detect an external attacker spoofing a known user's display name or email address; instead, it focuses on behavioral deviations after the fact. This means it cannot proactively prevent impersonation attempts against specific executives before they reach the inbox.

Spoofed sender posture

Why wrong: Spoofed sender posture is part of spoof intelligence and evaluates the envelope and From domains against SPF, DKIM, and DMARC authentication results to identify senders who are unauthorized to use a domain. It addresses domain spoofing, not user impersonation, where the attacker may use a display name like 'Chief Financial Officer' while the underlying email address is a free webmail domain that passes authentication checks. Thus, it is ineffective for stopping attacks that rely on name-based deception.

DeviceEvents

Why wrong: DeviceEvents logs process and security events on endpoints, but does not directly capture email link clicks. It is not used in an email click detection scenario.

IdentityLogonEvents

Why wrong: This table tracks user authentication events and is not relevant to email events or link clicks.

Data Lifecycle Management

Why wrong: Data Lifecycle Management manages retention and disposition, not content discovery and review.

Records Management

Why wrong: Records Management is used to declare items as records and apply retention, not for discovery without protection.

Information Protection

Why wrong: Information Protection labels can be auto-applied and may apply encryption; it is not designed for passive discovery only.

Session policy

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

App discovery policy

Why wrong: App discovery policies identify shadow IT apps.

OAuth app policy

Why wrong: OAuth app policies manage third-party app permissions.