Select Two (Multi-Select) Questions

named location for the corporate network

A named location defines the corporate network as a trusted IP range, letting the policy distinguish trusted from untrusted access. Without it, Conditional Access cannot evaluate whether a session originates inside or outside the office, so the MFA condition cannot be scoped correctly.

Conditional Access policy targeting all cloud apps

The Conditional Access policy targeting all cloud apps binds the MFA grant control to every application, satisfying the requirement to enforce MFA across cloud apps. Combined with the named location condition, it applies only when access originates from untrusted networks.

Scope (users and groups)

The Scope (users and groups) component is a mandatory and correct part of an anomaly detection policy in Microsoft Defender for Cloud Apps. It defines the set of users or groups whose activity is monitored and evaluated against the detection template. For example, you can scope the policy to only your global administrators or a specific group of high-privilege users, which reduces false positives and focuses on the accounts that matter most. Without a defined scope, the policy cannot determine whose activities are subject to anomaly analysis.

Anomaly detection policy template

The anomaly detection policy template is a core component, embodying the detection logic used to identify suspicious activities. Defender for Cloud Apps provides templates such as 'Impossible travel', 'Activity from infrequent country', and 'Unusual multiple sign-in attempts', each powered by machine learning to establish a per-user baseline and flag deviations from that baseline. The template dictates the specific behavioral anomalies that will trigger an alert, making it essential to the policy's function. Selecting the correct template is how you specify the type of threat you are trying to detect.

Alert settings

Alert settings are a correct and necessary component of an anomaly detection policy, as they determine how and where notifications are sent when an anomaly is triggered. This includes setting the alert severity level, email recipients, and integration with automation (e.g., Power Automate flows or external SIEM tools). You can also configure alert volume thresholds to suppress noise or escalate alerts to a security operations team. Without alert settings, the detection results would have no operational impact.

A minimal hybrid deployment allows you to manage mailboxes in both on-premises and Exchange Online.

A minimal hybrid deployment deliberately configures just enough coexistence to support mailbox management across both environments. Even at this baseline, the Hybrid Configuration Wizard creates a management relationship so administrators can view and move mailboxes from the on-premises Exchange admin center or the Exchange Online admin center, and mail flow works between the two. This makes it a valid and lightweight method for both coexistence and migration, so the statement is correct.

A cutover migration is suitable for organizations with fewer than 2000 mailboxes.

Cutover migration is designed for smaller organizations that can migrate all mailboxes in a single operation, and Microsoft's documented limit for this method is 2000 mailboxes. It synchronizes each mailbox to Microsoft 365 and then cuts over after a final sync, which is impractical for larger user populations because the process would be too slow and would require a single, organization-wide switch-over. Therefore the statement accurately describes when cutover migration is appropriate.

DeviceInfo

DeviceInfo is the core table in Microsoft Defender for Endpoint's Advanced Hunting that maintains a comprehensive inventory of all onboarded devices, including device ID, device name, OS platform, OS version, and last seen timestamp. It is the authoritative source for answering questions like 'which devices run Windows 11' or 'what OS versions are present.' By querying DeviceInfo and filtering on the OSVersion column, you can quickly retrieve the required device details.

DeviceTvmInfoGathering

DeviceTvmInfoGathering is a specialized table designed for Threat and Vulnerability Management, providing per-device telemetry about software inventory, vulnerability findings, and security configuration assessments. It does include a device identifier for correlation, but its primary content is vulnerability data, not a full inventory of OS version or general device attributes. Using it for basic OS queries would be inefficient and may exclude devices not fully assessed by TVM.

Microsoft Defender for Endpoint

Microsoft Defender for Endpoint contributes endpoint detection and response telemetry into the unified Microsoft Defender XDR portal, correlating device alerts with identity and email signals. It is one of the core workloads natively integrated into Microsoft Defender XDR, satisfying the stem's selection of three features.

Microsoft Defender for Office 365

Microsoft Defender for Office 365 supplies email, collaboration and phishing telemetry into Microsoft Defender XDR, enabling cross-domain incident correlation. It is a native workload of the suite, satisfying the stem's requirement to select three Microsoft Defender XDR features.

Microsoft Defender for Identity

Microsoft Defender for Identity feeds on-premises Active Directory signals into Microsoft Defender XDR, detecting identity-based attacks such as lateral movement and credential theft. It is a native component of the suite, satisfying the stem's requirement to identify three Microsoft Defender XDR features.

Entitlement management

Entitlement management is a core Microsoft Entra ID Governance feature that creates and manages access packages containing groups, apps, and SharePoint sites. It lets administrators define policies for requesting access, including approvals, separation-of-duties checks, and automatic expiration, so access is granted consistently and governed through the resource's lifecycle. By automating the full access-assignment lifecycle and supporting connected organizations for external collaboration, entitlement management directly achieves identity governance objectives.

Access reviews

Access reviews are a governance feature because they provide recurring attestation of access to groups, applications, and Microsoft Entra ID roles. Administrators and resource owners can be asked to confirm whether each user still needs access, and results can automatically remove stale or inappropriate assignments. This creates an audit-ready control loop that enforces the principle of least privilege and reduces the risk of orphaned or excessive permissions.

Privileged Identity Management (PIM)

Privileged Identity Management (PIM) is included in Entra ID Governance because it governs administrative roles by enabling just-in-time activation, time-bound assignments, approval workflows, and eligible activation requiring MFA or other justification. PIM tracks privileged role activations in an audit history and can trigger alerts when risky or unexpected activations occur. It therefore controls who can hold elevated roles and for how long, fulfilling the governance requirement of managing and monitoring privileged access.

deviceModel

deviceModel is a valid device attribute representing the manufacturer-assigned model name (e.g., 'Surface Pro 8' or 'iPhone 13'). Dynamic group rules can reference it directly with the syntax (device.deviceModel -eq "Surface Pro 8") to automatically include or exclude devices by hardware model. It is populated during device enrollment or via management tools like Microsoft Intune and is frequently used to target specific device lines for configuration or access policies.

deviceCategory

deviceCategory is a custom, admin-defined string attribute on device objects that classifies devices into groups such as 'Sales', 'Executive', or 'Kiosk'. It is a valid attribute for dynamic device group rules, e.g., (device.deviceCategory -eq "Executive"), enabling automatic membership based on business or functional categories. Unlike deviceModel, this attribute is not automatically populated; it must be set manually in Microsoft Entra ID/Intune or via an automated process before it can be used effectively.

deviceOSVersion

deviceOSVersion is a valid device attribute that contains the operating system version string, such as '10.0.19044' for Windows 10/11 or '15.0' for iOS. Dynamic group rules can use it with operators like -eq or -startsWith, for example (device.deviceOSVersion -startsWith "10.0"), to target all devices running a specific OS version. Note that the format varies by OS, so you may also need to combine it with deviceOSType (e.g., Windows, iOS) in the rule for accurate matching.

Create a DLP policy that prevents users from sharing credit card numbers via email with external recipients.

A Data Loss Prevention (DLP) policy in Microsoft 365 can be configured to detect the presence of sensitive information such as credit card numbers in emails and block sharing with external recipients. Using policy rules with conditions, actions, and user notifications, the policy scans outbound messages and prevents the transmission, thereby helping organizations comply with data protection standards like PCI-DSS.

Use a retention label to automatically delete documents containing trade secrets after 7 years.

Retention labels allow administrators to apply a configurable retention period to documents based on classification or content. By assigning a label that deletes content after 7 years, the document is automatically disposed of through a disposition review or directly based on the label's retention action, ensuring regulatory compliance and lifecycle management.

Configure a sensitivity label with sublabels that apply different markings (e.g., 'Confidential' and 'Highly Confidential') to the same document.

Sensitivity labels support sublabels, which are child labels under a parent label. You can configure sublabels with different markings, such as 'Confidential' and 'Highly Confidential,' to be applied to the same document depending on context. This enables granular classification while keeping the parent label's protection settings intact.

Enable auditing in the Microsoft 365 compliance portal to track user activities such as file downloads and mailbox access.

Enabling auditing in the Microsoft 365 compliance portal activates unified auditing across services like Exchange, SharePoint, and OneDrive. It captures events such as file downloads and mailbox access, storing them in a searchable audit log. This provides administrators with a forensic trail to investigate security incidents, insider threats, or compliance violations.

Register a custom domain name (e.g., contoso.com) and verify ownership via DNS TXT record.

Registering and verifying a custom domain like contoso.com via a DNS TXT record is one of the first tasks in a Microsoft 365 deployment. It proves you control the domain and allows users to have email addresses and user principal names (UPNs) that match your corporate identity, rather than the placeholder onmicrosoft.com domain. This verification is mandatory before you can configure services like Exchange Online for that domain.

Create the initial global administrator account with a strong, unique password and enable multi-factor authentication.

The initial global administrator account holds the highest level of privilege, so creating it with a strong, unique password and immediately enabling MFA is a critical security baseline for a new tenant. If this account is compromised, an attacker gains full control over the entire directory and any connected services. Use a dedicated, non-personal account and store the credentials securely, and consider creating additional emergency access accounts as well.

Configure tenant-wide service settings such as external sharing for SharePoint and OneDrive.

Configuring tenant-wide service settings, such as external sharing for SharePoint and OneDrive, is an essential governance step during initial deployment. These settings control how users can share content with people outside the organization and help prevent data leakage. You should establish external sharing policies before users start using these services, because retroactively restricting sharing can be both disruptive and error-prone. Other settings like password expiration are less critical than this.

Using the New-MsolDomain PowerShell cmdlet.

The New-MsolDomain cmdlet comes from the legacy MSOnline module and directly invokes Microsoft Entra ID's domain registration API, creating an unverified domain object in the tenant's directory. After that, you run New-MsolDomainVerificationDns to obtain the TXT record and New-MsolDomain to re-verify once the record is live. It is a valid, scriptable method, though Microsoft now deprecates MSOnline in favor of Microsoft Graph.

Using the 'Add domain' wizard in the Microsoft 365 admin center.

The 'Add domain' wizard in the Microsoft 365 admin center, located under Setup > Domains, is the primary guided GUI method for adding a custom domain. It walks you through entering the domain name, selecting how you will verify it, and then prompts you to create the required DNS record (typically TXT or MX) at your registrar. After verification, the wizard can also help configure default DNS records for Exchange, SharePoint, and Teams, making it the recommended user-friendly option.

retention label

A retention label defines the retention and deletion rules for content at a granular level, such as preserving documents for a specific number of days, years, or permanently. You can apply it manually to individual items or through auto-labeling policies, and it triggers a retention period that cannot be overridden by users. For the compliance officer's requirement to manage document retention, this is the direct and authoritative mechanism.

An auto-labeling policy for retention labels

An auto-labeling policy is the correct way to apply a retention label to all matching documents at scale, using criteria such as sensitive info types, keywords, or trainable classifiers. This policy automates the assignment of the chosen retention label, ensuring that every affected document receives the retention treatment without manual intervention. It is correct because it operationalizes the retention label across all required content.

Cloud Discovery

Cloud Discovery is the Defender for Cloud Apps feature that analyzes traffic logs from enterprise proxies or Microsoft Defender for Endpoint to identify brand-specific cloud app usage across the organization. It continuously monitors shadow IT by discovering applications that users access, then scores them for risk (e.g., security, compliance) to create a catalog of sanctioned and unsanctioned apps. This is the correct first step for understanding 'which cloud apps are being used' — it provides the raw visibility that later enables blocking.

Conditional Access App Control

Conditional Access App Control is a reverse-proxy capability that works with Microsoft Entra Conditional Access to route selected user sessions through Defender for Cloud Apps. Based on the app's risk profile and policies, it can block sign-in or block actions (e.g., upload, download, copy) for unsanctioned apps in real-time — for example, preventing a user from downloading a file from a newly detected app. It does not perform discovery on its own; rather, it relies on Cloud Discovery to identify which apps are actually in use, and it enforces access decisions after the app is known.

Review the incident timeline to understand the sequence of events.

Reviewing the incident timeline is the critical first step in an XDR investigation because it presents a chronological, correlated view of all alerts, user activities, and device events associated with the incident. This lets you reconstruct the attack chain from initial access to lateral movement and data exfiltration, identify which entities are truly affected, and establish what evidence must be preserved. Without this context, any containment or remediation action may be premature or miss the root cause.

Use advanced hunting to query for related activities across devices and identities.

Advanced hunting in Microsoft Defender XDR allows you to write KQL (Kusto Query Language) queries to pivot on specific indicators across data schemas like EmailEvents, IdentityLogonEvents, and DeviceProcessEvents. This correlative analysis goes beyond the preset incident timeline and lets you uncover related activities on other devices or identities that were not initially flagged as alerts. It is invaluable for mapping the full scope of the attack and for testing hypotheses about attacker behavior in your specific environment.

Isolate affected devices from the network using Microsoft Defender for Endpoint.

Isolating affected devices using Microsoft Defender for Endpoint is a proper containment move because it immediately stops the device from communicating with other assets and the internet, which limits lateral movement and disrupts command-and-control traffic while preserving the device's disk and memory for later forensic analysis. This action is reversible and can be applied selectively (for example, allowing certain Microsoft services) depending on the investigation needs. It is a standard incident-response step that prevents the attack from spreading without destroying evidence.

Configure email notifications for the alert policy.

Configuring email notifications for the alert policy ensures that the security team is notified when the specified alerts are triggered. This step is essential to actually receive the notifications for malicious file detection and suspicious sign-in attempts, as the policy alone does not send emails.

Create an alert policy in Microsoft 365 Defender with the appropriate detection sources.

Creating an alert policy in Microsoft 365 Defender allows you to specify the conditions and sources for alerts. By including detection sources such as Microsoft Defender for Endpoint and Microsoft Defender for Identity, you can receive notifications for malicious file detection and suspicious sign-in attempts, respectively.

Add members to the group

Members inherit license.

Create a security group

Group must exist to assign license.

Assign a license to the group

License is assigned to group.

Define sanctioned and unsanctioned app categories in Microsoft Defender for Cloud Apps

Sanctioned and unsanctioned app tags let Defender for Cloud Apps apply governance actions such as blocking or unsanctioning, converting discovery data into enforcement. Without these categories, discovered apps cannot be controlled, which the scenario explicitly requires.

Use Cloud Discovery in Microsoft Defender for Cloud Apps to analyze traffic logs

Cloud Discovery parses firewall and proxy traffic logs to build an app catalogue with risk scores, providing the visibility needed to identify shadow IT. This satisfies the discovery half of the requirement before any control actions can be applied.

The user must be assigned a role that includes live response permissions

Initiating a live response session is gated by role-based access control (RBAC). The user must be assigned an Microsoft Entra ID role such as Security Operator, or a custom Defender for Endpoint role with the 'Live response' permission, and must have the device in their assigned scope; without this, the Start session button is unavailable even for an onboarded, supported device.

The device must be running a supported operating system (e.g., Windows 10 or newer)

Live response depends on the target endpoint running a platform that Microsoft Defender for Endpoint supports for this feature—for example, Windows 10, Windows 11, or Windows Server 2019/2022, and on macOS in later service releases. On older or unsupported operating systems, the sensor may be present but does not implement the low-level commands needed for live response, so no session can be created.

The device must be onboarded to Microsoft Defender for Endpoint

For a device to appear as a selectable target, its Microsoft Defender for Endpoint sensor must be installed and reporting to the tenant—a state known as onboarding. Only devices that have completed onboarding and are showing an active status in the device inventory can be connected to via live response; an unonboarded endpoint is invisible to the service and cannot host a session.

Trainable classifier

A trainable classifier is an AI-based content detection model in Microsoft Purview that you train with seed documents to recognize specific patterns, such as SWIFT codes. Once published, the classifier can be used as a condition inside an auto-apply retention label policy; when documents match the classifier's model, the policy automatically assigns the appropriate retention label. It is the detection component that identifies the content, not the policy that performs the actual label assignment.

Auto-apply retention label policy

An auto-apply retention label policy is a Purview compliance policy that automatically assigns a retention label to all items matching specified conditions, such as a trainable classifier, a sensitive information type, or a keyword. When you configure this policy to use a trainable classifier that detects SWIFT codes, the policy evaluates content and applies the retention label without manual intervention. This policy is the enforcement mechanism that delivers the retention label to the matched documents.

Sensitivity labels

Sensitivity labels are the core classification mechanism in Microsoft Purview Information Protection. When applied, they embed metadata into the document and enforce protection settings such as encryption, rights management restrictions, and visual markings like headers, footers, or watermarks. The label persists with the content even when it leaves the organization, ensuring classification and protection follow the file. This directly satisfies the compliance officer's need to classify documents, especially when combined with auto-labeling for full automation.

Auto-labeling policies

Auto-labeling policies automate the assignment of sensitivity labels by scanning content against conditions such as sensitive info types, keywords, or trainable classifiers. They can run in simulation mode to assess impact before enforcement, and they are able to label documents at rest in SharePoint/OneDrive as well as emails in transit in Exchange. This is the direct mechanism that lets a compliance officer automatically classify documents at scale without requiring manual user effort. Auto-labeling works hand-in-hand with sensitivity labels, making the classification process consistent and policy-driven.

Tenant ID (or Microsoft 365 tenant domain name)

Tenant ID (or the Microsoft 365 tenant domain name such as contoso.onmicrosoft.com) is the primary key Microsoft Support uses to locate your specific tenancy in their backend systems. It lets support immediately verify service health, tenant-level configurations, and any recent changes or incidents affecting that environment. Without this identifier, they cannot authenticate the tenant context, route the request correctly, or correlate your issue with backend telemetry.

Detailed description of the problem and troubleshooting steps attempted

A well-written problem description with the exact error text, affected workload, timestamps, and any troubleshooting already performed (e.g., reboot, channel repair, Microsoft Remote Connectivity Analyzer results) is a mandatory-quality element for effective support. It primes the engineer with a hypothesis and lets them determine whether the issue belongs to Exchange Online, Teams, SharePoint, or a client misconfiguration. This specificity prevents generic loops and is one of the strongest accelerators to first-response resolution.