Scenario practice questions

The query lacks a time filter

Why it fails: A missing time filter does not invalidate the query, because analytics rules in Microsoft Sentinel apply an implicit time range defined by the rule's query scheduling and lookback period, and KQL queries executed manually against a workspace default to a 24-hour or user-defined time span. While an explicit time filter is a best practice for performance and to avoid scanning irrelevant data, its absence does not cause the query to fail or miss detections that would otherwise occur within the evaluated window.

The 'IPAddress' field does not exist in SecurityEvent

Why it fails: The assertion that IPAddress does not exist in SecurityEvent is false; the SecurityEvent table does contain an IP address column (often referenced as IpAddress or IPAddress) that stores the source IP address, and it is commonly used in KQL queries for security analytics. Even if there are case-sensitivity nuances in KQL column references, the field itself is a valid part of the schema, so this is not a reason the query would be incorrect.

The 'count()' aggregation is incorrect

Why it fails: The count() aggregation is a standard KQL aggregation function that returns the number of rows per group when used with summarize, so it is not incorrect. There is no requirement to use count_distinct or other functions unless counting unique values, and the query's use of count() after a where clause and summarize group is syntactically and semantically valid. Therefore, this option does not represent a flaw in the detection query.

Microsoft Identity Manager (MIM)

Why it fails: MIM is an identity and access management solution that automates lifecycle workflows, self-service, and access certification, and it does include a Synchronization Service. However, it is designed for complex, customized provisioning scenarios such as HR-driven attribute distribution or multi-forest integration, not as the standard, recommended tool for routinely synchronizing a single on-premises Active Directory forest to Entra ID. Microsoft's default sync utility for that is Entra Connect, making MIM an over-engineered and rarely-correct choice for this requirement.

Microsoft Entra Connect Cloud Sync

Why it fails: Microsoft Entra Connect Cloud Sync uses a lightweight agent to sync users and groups, and it's especially useful for merging multiple disconnected forests or replacing existing sync solutions in branch environments. However, it is not the general-purpose default for a typical on-premises AD to Entra ID deployment; Microsoft recommends Entra Connect for common scenarios that require a single, feature-complete sync engine. Cloud Sync lacks some advanced capabilities like device writeback and is intended for specific topologies, so it's incorrect here.

Active Directory Federation Services (AD FS)

Why it fails: AD FS is a federation service that authenticates users by forwarding their claims to trusted relying parties, enabling single sign-on for web applications across organizational boundaries. It does not replicate directory objects, passwords, or groups; it only processes authentication requests. Therefore, it cannot synchronize on-premises AD to Entra ID and is fundamentally a different identity technology built for federated access, not directory synchronization.

Geo-redundant backup storage

Why it fails: Geo-redundant backup storage refers to how backup copies are replicated to a paired Azure region for durability, not how long they are kept. While it protects against regional loss by creating a secondary copy, the retention period is still governed by the backup policy—PITR at 35 days or LTR up to 10 years. Choosing GRS alone does not extend the retention window, so it fails to meet a compliance-driven need for long-term data protection.

Point-in-Time Restore

Why it fails: Point-in-Time Restore (PITR) enables recovery to any moment within a short retention window, which in Azure SQL is a maximum of 35 days. It is designed for operational recovery from accidental changes or corruption, not for long-term archival compliance. Because the retention period is bounded by the backup policy and cannot be extended beyond 35 days, PITR alone cannot satisfy a data protection strategy requiring multi-year retention.

Active Geo-Replication

Why it fails: Active Geo-Replication continuously replicates data to readable secondary databases in another region to support high availability and fast failover. It does not store historical backup snapshots or provide any retention mechanism; it is a live data synchronization feature, not an archival backup solution. While it improves business continuity, it offers nothing for long-term data retention or compliance, making it an incorrect answer here.

Use a session policy in Defender for Cloud Apps to monitor non-compliant devices.

Why it fails: Defender for Cloud Apps session policies are designed to monitor and control sessions in real time using app or OU controls, but they are not an access-gate mechanism; they do not evaluate device compliance or block a sign-in before a session begins. Conditional Access policies are the correct enforcement point to reject access based on location or device state. A session policy that merely 'monitors' non-compliant devices provides visibility only and fails to enforce the required block.

Create one conditional access policy that includes all cloud apps and requires compliant device for Microsoft 365 only.

Why it fails: A single Conditional Access policy cannot apply different grant controls to different included applications. If you include 'All cloud apps' and configure 'Require compliant device' as the grant, that same requirement is applied to every app in scope, including Microsoft 365. To enforce a compliant-device requirement only for Microsoft 365, you must create a policy exclusively targeting Microsoft 365, leaving other apps untouched by that control.

Configure a conditional access policy that blocks access from untrusted locations for all apps.

Why it fails: Blocking access from untrusted locations for all apps indiscriminately denies Microsoft 365 to users on compliant devices who happen to be in an untrusted location. The desired outcome explicitly allows compliant devices to access Microsoft 365 regardless of location, so this blanket location block is too coarse. Excluding Microsoft 365 from the location-based block—and handling that app with a separate device-compliance policy—is what makes the two-policy approach correct.

B2B direct federation

Why it fails: B2B direct federation lets partners authenticate with their own SAML/WS-Fed IdP, but it does not provision or deprovision guest accounts in Microsoft Entra ID. It suits one-off partner access where lifecycle management is handled manually, not the automatic removal required when a user leaves their home organisation.

Self-service sign-up

Why it fails: Self-service sign-up lets external users request access via a custom application, but it creates no lifecycle link to their home organisation, so removal there does not deprovision the guest account. It fits open enrolment scenarios such as consumer apps, not managed partner access with automatic deprovisioning.

Identity Governance access reviews

Why it fails: Access reviews periodically recertify existing guest access but do not automatically deprovision accounts when a partner leaves their home organisation; they rely on reviewers acting. Access reviews suit attestation and compliance for standing access, not the entitlement lifecycle synchronisation that cross-tenant provisioning provides.

Consent Management

Why it fails: Consent Management tracks whether a user has granted or withdrawn permission for a given data processing activity, such as marketing or analytics. It does not locate or export personal data in response to a subject rights request; instead, it governs the lawful basis for processing. Therefore, while consent records may be relevant to a DSR, this module does not perform the retrieval or fulfillment actions needed.

Data Inventory

Why it fails: Data Inventory maps and classifies personal data across the tenant to provide a catalog of where different types of personal data reside, including attributes such as data classification and retention. It gives visibility into the data landscape but does not execute the search, extraction, or delivery of data to satisfy a subject rights request. It is a prerequisite for discovery but not the mechanism that fulfills the request.

Data Breach Notifications

Why it fails: Data Breach Notifications manages the detection, assessment, and notification obligations following a security incident or personal data breach, typically to regulators and affected individuals. It is a reactive compliance process triggered by an incident, whereas subject rights requests are proactive, user-initiated actions. This module does not search or retrieve data for a data subject under normal operations, so it is incorrect here.

Data loss prevention (DLP) policy

Why it fails: Data loss prevention (DLP) policies enforce protective actions such as blocking, restricting, or auditing data sharing, but they do not apply sensitivity labels. DLP is focused on preventing unauthorized transmission of sensitive data, not on classifying or labeling content for metadata purposes. Even if a DLP policy can detect sensitive info types, it cannot assign a sensitivity label to a document.

Retention label

Why it fails: Retention labels are designed to govern data lifecycle by specifying how long content is kept and whether it should be deleted after that period. They do not convey sensitivity level nor apply classification markings; a document can have both a retention label and a sensitivity label independently. For sensitivity classification, you need a sensitivity label rather than a retention label.

Trainable classifier

Why it fails: Trainable classifiers use machine learning to recognize content based on examples and patterns, rather than exact custom-defined rules. They are useful for identifying categories like resumes or source code, but they do not allow you to define a precise numeric pattern for a specific label. Consequently, they are not suitable when you need to match a bespoke pattern for sensitivity classification.

Microsoft Defender for Office 365

Why it fails: Microsoft Defender for Office 365 is a specialized security solution for email, attachments, Microsoft Teams, SharePoint, and OneDrive. It detects phishing, malware, and malicious links within collaboration and messaging workflows, but it does not monitor hybrid cloud infrastructure such as virtual machines, databases, or on-premises Active Directory. Therefore, it is not one of the three solutions that detect threats across hybrid environments.

Microsoft Intune

Why it fails: Microsoft Intune is a cloud-based endpoint management service that handles mobile device management (MDM) and mobile application management (MAM). It enforces compliance policies, manages OS and app configurations, and supports conditional access, but it does not analyze security telemetry or generate threat detection alerts. Intune is a management solution, not a detection solution, so it is incorrect for this question.

Application Insights

Why it fails: Application Insights is Azure Monitor's application performance management (APM) service, designed to receive telemetry streamed from instrumented application code via SDKs (e.g., requests, dependencies, exceptions). It does not perform file system scanning or monitor arbitrary directories for pre-existing log files; it simply has no mechanism to ingest flat .log or .txt files generated by custom applications unless that code explicitly sends telemetry to an Application Insights resource. Therefore, it cannot satisfy a requirement to collect existing custom application log files from a VM.

Syslog

Why it fails: Syslog is a network logging protocol used primarily by Linux/Unix hosts, network appliances, and firewalls to send structured event messages over UDP/TCP (typically port 514) to a central collector. The Microsoft Sentinel Syslog connector relies on the Log Analytics agent to receive and parse those RFC 3164/5424 syslog messages — not to read arbitrary text-based application log files with custom formatting. Even though some applications can be configured to write to syslog, the question expects ingesting existing log files directly from disk, which Syslog does not do unless the application is modified to emit syslog messages.

Windows Event Forwarding

Why it fails: Windows Event Forwarding (WEF) uses the Windows Remote Management (WinRM) protocol to forward Windows Event Log entries from source computers to an event collector, then those events can be ingested into Microsoft Sentinel via the Windows Event Log connector. WEF works exclusively with the structured Event Log service (Security, System, Application channels); it has no capability to read or forward plain-text log files created by custom applications outside of the Windows Event Log subsystem. Therefore, it is unsuitable for ingesting a custom application's file-based logs.

Syslog via AMA

Why it fails: Syslog via AMA is not suitable for this use case because Syslog is a standard for logging on Linux systems and network devices, not for Windows operating system security events. While Windows can be configured to forward logs via Syslog through third-party agents, the Azure Monitor Agent (AMA) does not natively collect Windows Security log entries through the Syslog protocol. To detect lateral movement on Windows hybrid identities, you need authentication-related event IDs such as 4624 and 4625, which are found in the Windows Security log, not in Syslog streams.

Office 365 Logs

Why it fails: Office 365 Logs are cloud-only audit logs that capture activities from Microsoft 365 services like Exchange Online, SharePoint, and Teams. They do not include on-premises or virtual machine authentication events, such as user logons to domain controllers or Windows servers. Therefore, they cannot provide the security event data needed to detect lateral movement across on-premises or hybrid-joined Windows machines. This option fundamentally misses the OS-level sign-in telemetry required for the scenario.

Azure Activity Log

Why it fails: Azure Activity Log provides subscription-level resource management events, such as creating or deleting Azure resources and starting or stopping VMs. It does not capture guest OS-level security events, including authentication attempts or processes running inside a virtual machine. Consequently, it cannot reveal lateral movement within your on-premises or hybrid-joined Windows environment. To monitor Windows sign-ins and other OS-level activities, you must rely on Windows Security Events collected by Azure Monitor Agent (AMA).

The policy mode should be 'report-only'

Why it fails: Changing the policy mode to 'report-only' would not address the flaw because report-only mode only simulates policy outcomes and does not enforce any actions. The real issue lies in the conditional logic: both user risk and sign-in risk must be High for the 'Block access' control to trigger. Switching to report-only would actually make the policy less effective, since it would never block anything, even for users who meet all conditions.

The JSON syntax is invalid

Why it fails: The policy contains valid JSON; all quotes, colons, braces, brackets, and property names follow the correct syntax for Microsoft Graph's conditionalAccessPolicy resource. If the JSON were malformed, the policy creation or update request would be rejected, but the policy is present and being evaluated. The administrator's concern is not a parsing error but a design flaw in how the risk levels are logically combined.

The conditions are combined with 'Or' instead of 'And'

Why it fails: This option incorrectly reverses the actual logic: Conditional Access policies combine multiple conditions with an implicit AND, not OR. Because both user risk and sign-in risk must be High under the current AND semantics, a High user risk with Low sign-in risk bypasses the block. Switching to an OR operator would be the remedy, not the cause of the problem, so claiming the conditions are ORed is factually incorrect.

Anomaly rule

Why it fails: Anomaly rules in Microsoft Sentinel use built-in machine learning models to identify unusual behavior without requiring custom KQL definitions. They are not suitable for matching a specific, known pattern such as a user exceeding 10 failed sign-ins, because that is a deterministic condition, not a baseline deviation. The rule's logic is based on statistical deviations from a normal baseline, so it cannot enforce an exact numeric threshold.

ML Behavior Analytics rule

Why it fails: ML Behavior Analytics (MLBA) rules use machine learning models to analyze patterns of entity behavior, and they do not accept custom KQL queries or user-set numeric thresholds. They are built to detect deviations in a user's activities (such as impossible travel or unusual sign-in locations) rather than a fixed condition like 'more than 10 failed sign-ins in 5 minutes.' Since the scenario requires a precise KQL query and threshold, MLBA is the wrong choice.

Fusion rule

Why it fails: Fusion rules in Microsoft Sentinel correlate multiple alerts and signals to recognize multistage attack chains, using built-in logic and machine learning to combine evidence across different entities and time windows. They are not designed to run a user-defined query or to trigger on a simple threshold; instead, they automatically create incidents when a correlated attack sequence is detected. A single condition such as 'X failed sign-ins by one user' is not a multistage pattern, so Fusion does not apply here.

An ExpressRoute circuit.

Why it fails: An ExpressRoute circuit is an entirely different connectivity service that provides a private, dedicated connection to Azure via a carrier or exchange provider, bypassing the public internet. It does not require an IPsec tunnel, a pre-shared key, or a local network gateway, and it is an alternative to VPN rather than a component that supports it. Therefore, it is not one of the three required components for a secure hybrid network built with Site-to-Site VPN.

An Azure Firewall.

Why it fails: Azure Firewall is an optional, stateful firewall service that filters and logs traffic between virtual networks and to the internet, and it can be placed in a hybrid architecture to enforce security policies. However, Site-to-Site VPN connectivity will function perfectly without it, because the IPsec tunnel is established by the virtual network gateway and the connection resource. Thus, while it adds security, it is not a required component of the VPN implementation.

Microsoft Entra Identity Protection.

Why it fails: Identity Protection uses machine learning and heuristics to detect risky sign-ins and user behaviors, such as anonymous IP addresses, leaked credentials, or impossible travel, and it can enforce conditional access policies to challenge or block those sessions. It is focused on security risk remediation, not on reviewing the ongoing necessity of user access assignments or group memberships for governance. Consequently, it does not address a requirement to periodically recertify access entitlements.

Privileged Identity Management (PIM).

Why it fails: PIM delivers just-in-time privileged access to Microsoft Entra ID roles, Azure resources, and Microsoft 365 roles, allowing activation for a limited time, optionally with approval and multi-factor authentication, and maintains logs for privileged assignments. Its scope is deliberately limited to high-privilege roles that represent security risk, rather than the broad range of ordinary user access that must be reviewed as part of identity governance. General access certifications are therefore outside PIM's purpose.

Create a DLP policy with the action 'Audit only' for credit card numbers

Why it fails: The 'Audit only' action in a Microsoft Purview DLP policy simply logs the detection of credit card numbers without imposing any restriction. Users can still share, email, or transfer the data externally, so this approach fails to stop data loss; it only provides visibility after the fact.

Create a DLP policy that encrypts emails containing credit card numbers

Why it fails: Encrypting emails with credit card numbers (e.g., via Microsoft Purview Message Encryption) protects the content from being read by unauthorized parties, but it does not prevent the email from being sent to an external recipient. The sharing action itself is allowed, so the data leaves the organization's control, violating the requirement to block the sharing.

Create a DLP policy with the action 'Block' for credit card numbers

Why it fails: The 'Block' action in Purview DLP completely prevents the sharing of credit card numbers without any option for users to override the restriction. While this ensures data is not accidentally exposed, it is too rigid for legitimate business scenarios, causing productivity disruption and forcing data owners to find unmonitored workarounds.

Android Enterprise managed Google Play

Why it fails: Android Enterprise managed Google Play is the deployment mechanism for Android devices, not iOS. It uses Play-managed accounts and work-profile containers to push apps from Google Play or private apps, but it has no integration with Apple's iOS signing or enrollment. Therefore it cannot deliver an enterprise-signed IPA to iPhones or iPads.

Volume Purchase Program (VPP) token

Why it fails: A Volume Purchase Program (VPP) token, now handled through Apple Business Manager, only authorizes the bulk purchase and assignment of public App Store apps. It does not support uploading or sideloading enterprise-signed line-of-business binaries. Even with a valid VPP token, Intune cannot use it to deploy a custom in-house iOS app outside the App Store.

Microsoft Store for Business

Why it fails: Microsoft Store for Business is a Windows-centric storefront that historically allowed IT admins to distribute UWP/Win32 apps to managed Windows clients. It was deprecated and no longer exists for app distribution in current Intune scenarios. Because it never supported iOS, it cannot be used to deploy enterprise-signed apps to Apple devices.

Store secrets in Azure DevOps pipeline variables with encryption enabled

Why it fails: Encrypted variables in Azure DevOps are stored encrypted at rest, but once a pipeline runs, they are decrypted and injected as plaintext environment variables that any script or task can read or output to logs, and they can also be exported through the REST API by any user with pipeline edit permissions. They do not support per-secret access control, rotation schedules, or independent auditing the way Key Vault does, and they remain tied to the pipeline project's security model. Thus they are neither a replacement for nor equal to Key Vault.

Store secrets in a configuration file in a private Git repository

Why it fails: Storing secrets in a configuration file under a private Git repository is dangerous because repositories are often cloned to local workstations, shared with multiple developers, and persist every historical state in git history—so a secret deleted later remains recoverable. Even with private access, there are no secret-level permissions, no rotation, and no audit trail, and a single compromised developer account exposes all secrets. This violates the principle of least privilege and is why Azure Key Vault is preferred.

The query syntax is invalid.

Why it fails: The custom detection rule's KQL query uses standard verbs like `let`, `where`, and `or` with proper column references from the DeviceProcessEvents schema, and would pass Microsoft 365 Defender's validation when saved. A syntactically invalid query would be rejected at creation time with a parser error, preventing the rule from ever being enabled. Since the rule is active and generating alerts, the syntax is demonstrably correct.

The severity should be Medium instead of High.

Why it fails: Changing the severity from High to Medium would alter how the alert ranks in the queue and its escalation path, but it would not reduce the number of alerts generated because severity is a label applied to each alert, not a trigger condition. The rule still fires at the same 5-event threshold, so the SOC would face the same overwhelming alert volume regardless of the assigned severity. Therefore this criticism fails to address the actual root cause of the alert fatigue.

The rule does not cover PowerShell 7 (pwsh.exe).

Why it fails: The query explicitly includes both `powershell.exe` and `pwsh.exe` in the file-name filter, meaning the rule covers Windows PowerShell 5.1 and PowerShell 7 instances equally. A true coverage gap for PowerShell 7 would be a legitimate finding, but it is not applicable here because the rule's process filter already accounts for both executables. As a result, this option is a factually incorrect objection.

The storage account is compliant only if encryption is enabled for blob and file services.

Why it fails: The exhibit already shows encryption enabled for both blob and file services, so this is not a missing requirement. Storage compliance is not 'only if' encryption is on; it also requires customer-managed keys (keySource: Microsoft.Keyvault) and network restrictions (defaultAction: Deny with a specific virtual network rule). This option wrongly isolates encryption as the sole condition.

The storage account is non-compliant because it uses Microsoft-managed keys for encryption.

Why it fails: The JSON output for the encryption property shows 'keySource': 'Microsoft.Keyvault', which indicates customer-managed keys from an Azure Key Vault, not Microsoft-managed keys. Microsoft-managed keys would be represented by 'Microsoft.Storage' as the key source. Therefore the storage account is not non-compliant for this reason; in fact, it satisfies the customer-managed key requirement.

The storage account is non-compliant because network access is allowed from any virtual network.

Why it fails: The storage account does not allow access from any virtual network; the network ACLs show a default deny behavior with a virtualNetworkRules entry referencing a specific virtual network resource group and ID. If 'any' virtual network were allowed, the rule would use an addressPrefix covering public internet or no restriction. Thus this non-compliance claim is factually incorrect.

Microsoft Defender for SQL

Why it fails: Microsoft Defender for SQL is scoped to database workloads, providing vulnerability assessment, advanced threat protection, and auditing for Azure SQL Database, SQL Managed Instance, and SQL Server on Azure VMs. However, the scenario involves migrating general-purpose on-premises servers, which likely host a mix of applications, services, and operating system roles beyond just SQL Server. This plan does not offer broader server-level protections like endpoint detection and response or malware scanning for the entire VM, so it is not the correct choice.

Microsoft Defender for Storage

Why it fails: Microsoft Defender for Storage is dedicated to securing Azure Blob Storage, Azure Files, and Azure Data Lake Storage by detecting suspicious access patterns, malicious file uploads, and data exfiltration attempts. Since the migration plan concerns on-premises servers (compute infrastructure) rather than storage accounts, this plan would not protect the operating system, running processes, or installed software on the migrated VMs. Consequently, it is not suitable for this scenario.

Microsoft Defender for Containers

Why it fails: Microsoft Defender for Containers protects containerized environments, including Azure Kubernetes Service (AKS), Azure Container Instances, and container registries, with security for cluster nodes, runtime threat detection, and image scanning. The migration involves on-premises servers, which are traditionally deployed as virtual machines, not necessarily as container workloads; unless the organization explicitly rearchitects applications into containers, this plan would miss the actual VMs. Thus, it is not the appropriate protection plan for a straightforward server migration.