Secure Azure using Microsoft Defender for Cloud and Microsoft Sentinel practice questions

The VM is in a resource group that is excluded from the vulnerability assessment solution.

Why it fails: While resource group exclusions can prevent the vulnerability assessment from being applied, the scenario explicitly places the VM in scope, so an exclusion cannot be the reason. Exclusions are managed at the resource group level and would affect all VMs in that group. Because the VM is in scope, this option is not applicable.

The VM is behind a network security group that blocks outbound traffic.

Why it fails: A network security group that blocks outbound traffic could indeed prevent the Qualys extension from communicating with the scanning service, leading to missing scan results. However, the most common and immediate cause for absent vulnerability data is the lack of the Log Analytics agent, which is a prerequisite for the extension. The agent should be checked before evaluating network connectivity.

The VM does not have a valid Qualys license.

Why it fails: Defender for Cloud includes the Qualys vulnerability scanner without requiring a separate Qualys license; the license is fully managed by Microsoft. Therefore, an invalid or missing Qualys license cannot be the reason for the absence of vulnerability findings. This option is incorrect because the licensing is transparent to the customer.

Azure Sentinel analytics rule

Why it fails: Azure Sentinel is a separate cloud-native SIEM product, not part of Microsoft Defender for Cloud. Sentinel analytics rules are written in KQL and run against data in a Log Analytics workspace, whereas the scenario requires a custom security alert or recommendation inside Defender for Cloud's context. Since Defender for Cloud does not ingest or process Sentinel analytics rules, this option cannot fulfill the requirement.

Azure Activity Log alert

Why it fails: Azure Activity Log alerts are Azure Monitor alerts that trigger on resource-level operational events such as VM creation, deletion, or ARM configuration changes. They are not security alerts generated by Defender for Cloud's intelligent threat detection, and they lack the context and vitals of Defender for Cloud recommendations. Additionally, custom recommendations in Defender for Cloud rely on Azure Policy definitions, so an Activity Log alert does not provide the needed path to create a custom security control.

Custom alert rule in Defender for Cloud

Why it fails: Defender for Cloud does not expose any wizard or menu to create a standalone custom alert rule. Custom recommendations are instead implemented by authoring an Azure Policy initiative with 'Recommendation' effect definitions and assigning that initiative to selected scope. Because the described custom alert is actually a recommendation, trying to create a direct alert rule misrepresents the service's architecture and fails to produce a valid configuration.

Enable Azure Firewall on the SQL server

Why it fails: Azure Firewall is a cloud-native network security service that filters traffic at the network and application layers, but it cannot inspect database-level operations such as T-SQL queries. It is designed to control incoming/outgoing connectivity, not to detect malicious patterns inside the database engine like SQL injection or credential brute-force attempts. Network access control therefore does not provide the SQL-specific threat detection and alerting that defender for Cloud offers.

Enable Azure SQL Database Advanced Threat Protection

Why it fails: Azure SQL Database Advanced Threat Protection is not a standalone setting; it is a feature that is provisioned through Microsoft Defender for Cloud as part of the Defender for SQL plan. Attempting to enable it independently is not possible in the current Azure portal because ATP is consolidated under the Defender for SQL enabled state. The correct action is to enable the Defender for Cloud plan for Azure SQL databases, which automatically includes the ATP detection and alerting features.

Enable Azure SQL Database Auditing

Why it fails: Azure SQL Database Auditing merely logs database events to an audit log for compliance and forensic review; it does not analyze activity in real time or generate security alerts. Auditing is a passive, post-incident record keeper, so it cannot detect anomalous behavior or threats like SQL injection. Proactive threat detection requires the analytical engine of Microsoft Defender for SQL, not just the audit logging mechanism.

Run a custom anomaly detection job

Why it fails: Anomaly detection is for baseline deviations, not explicit correlation.

Create a Scheduled analytics rule with a KQL query

Why it fails: Creating a Scheduled analytics rule with a KQL query is unsuitable because it primarily focuses on detecting patterns or thresholds within a single query execution over a defined time window, not on tracking a user's state across sequential, distinct events. The scenario requires correlating an initial unfamiliar sign-in with a subsequent high-risk action, which demands a more stateful or behavioural detection mechanism. This option is tempting as scheduled rules are the most common type, ideal for identifying specific known patterns, aggregations, or anomalies that can be captured by a single KQL query run at regular intervals, such as detecting multiple failed sign-ins from a single IP address.

Create a Near-Real-Time (NRT) analytics rule

Why it fails: NRT rules are for single event types.

Azure Monitor

Why it fails: Azure Monitor is a telemetry and observability platform designed to collect metrics, logs, and application data, not security incident management. Although Defender for Cloud can stream alerts to a Log Analytics workspace, Azure Monitor's portal and workbooks do not natively aggregate or present Defender for Cloud incidents with their detection and correlation context. Using Azure Monitor would require significant custom querying and lacks the built-in incident triage workflows found in the dedicated security console.

Azure Security Center

Why it fails: Azure Security Center is the legacy name for the service now called Microsoft Defender for Cloud. The rebranding reflects an expanded scope that includes Defender plans, regulatory compliance, and unified incident correlation. Choosing the outdated name indicates a misunderstanding of the current service branding; the underlying functionality is identical, but the portal and exam answer should reference Microsoft Defender for Cloud, not the retired product name.

Microsoft Sentinel

Why it fails: Microsoft Sentinel is a native cloud SIEM that can ingest security alerts and incidents from Defender for Cloud, but it is an optional, separately licensed additional layer for advanced correlation and hunting. Viewing incidents generated by Defender for Cloud does not require Sentinel; Defender for Cloud itself provides the incident list, details, and investigation. Sentinel would only be the right answer if the question asked about an SIEM for cross-source analytics or extended detection and response (XDR).

Azure DNS

Why it fails: Azure DNS is a hosting service for DNS domains and name records; it does not expose a native Microsoft Sentinel connector that automatically streams DNS query logs into the workspace. To leverage DNS for threat detection, you would have to deploy a separate DNS analytics solution or forward Syslog/CEF from IaaS DNS servers, which is a custom setup, not a standard or broad-path connector. Consequently, Azure DNS cannot directly deliver the OS-level or management-plane telemetry needed for the required threat detection.

Office 365

Why it fails: The Office 365 connector ingests audit logs from Microsoft 365 services (Exchange, SharePoint, Teams, and Power BI) via the Office Management Activity API, capturing SaaS-level user and admin activities rather than anything generated by an Azure VM's operating system. Because the requirement is about threat detection for Azure resources, and specifically necessitates OS or control-plane telemetry, the Office 365 logs are intrinsically out-of-scope and cannot satisfy that need. Their telemetry is unrelated to VM security events.

Azure Firewall

Why it fails: Azure Firewall delivers network-layer logs like AZFWNetworkRule, AZFWApplicationRule, and AZFWThreatIntel through diagnostic settings, but these logs only cover traffic explicitly inspected by that firewall resource. They are situational—if a VM communicates directly without passing through the firewall, or if the firewall logs are not configured, you get no visibility. Moreover, Azure Firewall does not provide host-level operating system events; it is not a general-purpose Sentinel connector for broad threat detection across Azure VMs.

Azure Storage Firewall

Why it fails: Azure Storage Firewall restricts network access to a storage account by IP address or virtual network rules, but it is a network security control rather than a threat detection service. It does not analyze data-plane activity or generate security alerts for anomalous behavior, so it cannot satisfy the requirement for workload protection alerts. This control simply blocks traffic from unauthorized networks without inspecting the intent or pattern of requests.

Azure Defender for Storage

Why it fails: Azure Defender for Storage is an outdated product name; the capability is now delivered as part of Microsoft Defender for Cloud's storage workload protection. Microsoft retired the Azure Defender branding in 2022, so selecting this option would not reference an actual available service in the current Azure ecosystem. The correct service is Microsoft Defender for Cloud's Storage plan, which uses behavior analysis to alert on suspicious storage operations.

Azure Storage Encryption

Why it fails: Azure Storage Encryption protects data at rest using server-side encryption with Microsoft-managed or customer-managed keys, ensuring confidentiality against disk-level theft. It does not monitor or log who accesses storage, nor does it generate alerts for threats or anomalies in access patterns. Encryption is a data-integrity and privacy feature, not a workload protection detection mechanism, so it fails to address the need for security alerts.

Microsoft Defender for Cloud enabled

Why it fails: Enabling Microsoft Defender for Cloud is not a prerequisite for deploying Sentinel because Defender for Cloud is a separate security posture management service. While Sentinel can ingest alerts from Defender for Cloud as a data source, the SIEM itself functions independently without it. You can enable Sentinel on a subscription that has never had Defender for Cloud enabled, and disabling Defender for Cloud does not block Sentinel deployment.

The Microsoft.Sentinel resource provider registered

Why it fails: There is no Azure Resource Manager resource provider namespace named "Microsoft.Sentinel" in Azure. Sentinel's onboarding and management are handled through the Microsoft.OperationsManagement provider (for solutions) and the Microsoft.SecurityInsights provider (for Sentinel-specific resources like rules and incidents). Attempting to register "Microsoft.Sentinel" would fail because the provider does not exist; the actual registration requirement is the OperationsManagement namespace.

The effect parameter is set to 'AuditIfNotExists'.

Why it fails: The exhibit's policy definition uses the DeployIfNotExists effect, not AuditIfNotExists. Changing the effect to AuditIfNotExists would only generate compliance results for VMs missing the Azure Monitor agent, leaving the agent undeployed and requiring manual remediation; therefore it cannot explain the missing deployment block. The actual defect is that the policy's then.details section lacks a deployment specification, which is mandatory for DeployIfNotExists to perform its intended action.

The policy mode should be 'All' instead of 'Indexed'.

Why it fails: Azure Policy mode 'Indexed' is specifically designed for resource types that support tags and locations, which includes virtual machines, the target of this policy. The 'All' mode is reserved for policies that need to evaluate resource types that do not support tags/locations, such as extension resources or provider-defined non-standard types. Since the policy is assigning DeployIfNotExists to deploy the Azure Monitor agent on VMs, Indexed mode is correct and not the cause of the incompleteness.

The policy is a built-in policy and cannot be assigned.

Why it fails: Built-in Azure Policy definitions are provided by Microsoft and are fully assignable to management groups, subscriptions, or resource groups, exactly like custom definitions. The Azure portal and CLI both allow you to assign any built-in definition, and doing so is a routine administrative task. The exhibit likely shows a built-in definition that is syntactically malformed due to the absent deployment block, but its status as built-in does not prevent assignment.

The Microsoft Sentinel solution is not installed on the VM.

Why it fails: The Microsoft Sentinel solution is installed at the workspace level, not on the virtual machine itself. This solution enables the Windows Security Events data connector and related content in Log Analytics, but the VM only needs the Azure Monitor Agent (or Log Analytics agent) installed to transmit data. Because the agent is already connected and sending other data, the absence of a workspace-level solution would not selectively stop security event collection. Therefore, this is not the root cause.

The Azure VM has a network security group blocking port 443.

Why it fails: An NSG rule blocking outbound port 443 would prevent the Azure Monitor Agent from establishing any communication with the Log Analytics service. This would terminate the agent's heartbeat and all data uploads, not just Windows security events. Since the analyst reports that other data is being received from the VM, network connectivity to the service on port 443 is functioning normally. Alternatively, security events are collected over the same agent channel, so a port block would degrade all log flow.

The Log Analytics workspace key is incorrect.

Why it fails: If the Log Analytics workspace key were incorrect, the agent would fail to authenticate during onboarding and would not appear as connected in the workspace. A functioning agent that is actively sending heartbeats and other operational data proves that the workspace ID and key are valid. The workspace key is used only for initial registration and secure authentication; an invalid key would yield no data at all, not a selective gap in one event category. Hence this option is incorrect.

Configure Microsoft Purview compliance portal to include Azure subscriptions.

Why it fails: Microsoft Purview Compliance Manager is a data governance and insider-risk tool, not a cloud security compliance engine. It cannot ingest Defender for Cloud security findings, map policy recommendations to controls, or surface them in the Regulatory Compliance dashboard. Adding Azure subscriptions to Purview would not register a custom standard in Defender for Cloud, because that dashboard is populated only by compliance standards and initiatives configured inside Defender for Cloud.

Use Azure Policy to apply custom definitions and assign to management groups.

Why it fails: Azure Policy is the underlying mechanism that Defender for Cloud uses to evaluate resources, but assigning custom definitions to management groups only generates individual recommendation results. The Regulatory Compliance dashboard will not display those assignments as a compliance standard unless you explicitly add the corresponding initiative as a custom regulatory compliance standard in Defender for Cloud and assign it at the appropriate scope. Therefore, using Azure Policy alone does not populate the compliance dashboard.

Create an Azure Blueprint with custom policies.

Why it fails: Azure Blueprints was a packaging service for deploying Azure resources, RBAC assignments, policies, and locks at scale, but it is deprecated and had no direct relationship to Defender for Cloud's Regulatory Compliance blade. A blueprint assignment might create policy effects, yet it never creates a standard that appears in the compliance dashboard. To track custom compliance, you must use a custom regulatory compliance standard in Defender for Cloud, not a deprecated Blueprint.

The VMs are not backed up to Azure Backup.

Why it fails: Azure Backup is a data-protection service for creating and restoring recovery points; it does not apply or evaluate disk-level encryption. The policy in question uses the audit effect to detect VMs lacking Azure Disk Encryption (the AzureDiskEncryption extension with BitLocker/DM-Crypt settings), not backup configuration. Even if a VM is fully backed up, it would still be non-compliant unless the disk-encryption extension is deployed and encryption settings are present.

The VMs have encryption at host enabled but not Azure Disk Encryption.

Why it fails: Encryption at host is a platform-level capability that encrypts temporary disks and cached data on the physical host using disk-encryption-set managed keys; it does NOT install the AzureDiskEncryption extension or encrypt the OS/data disks inside the guest OS. The policy specifically checks for the existence of the AzureDiskEncryption extension, not whether encryption at host is enabled, so a VM with host-level encryption only still fails the audit. This is a common misunderstanding because both features provide 'encryption,' but only ADE satisfies the policy's extension-based condition.

The VMs are missing critical Windows security patches.

Why it fails: Missing Windows security patches are evaluated by a completely separate policy category, such as system-updates recommendations from Azure Security Center or Defender for Cloud, not by a disk-encryption audit policy. The policy in question has no condition referencing patch level or Windows Update compliance; it only examines the disk-encryption extension and encryption settings. Therefore, a fully patched VM would remain non-compliant if the AzureDiskEncryption extension is absent, while an unpatched VM with ADE installed could be compliant with this particular policy.

Use continuous export to Azure Event Hubs for long-term storage.

Why it fails: Incorrect. Event Hubs is for real-time streaming, not long-term retention.

Store logs in Azure SQL Database for seven years.

Why it fails: Incorrect. Azure SQL Database is expensive and not optimized for log storage.

Microsoft Entra ID

Why it fails: Microsoft Entra ID is Microsoft's identity and access management service, not a workload protection plan within Defender for Cloud. Defender for Cloud does not list Microsoft Entra ID as a plan; identity-related security is handled by Microsoft Entra ID Protection and Microsoft Entra, so this option is incorrect.

Microsoft 365 Defender

Why it fails: Microsoft 365 Defender is a separate enterprise security suite that correlates signals across endpoints, email, identities, and applications. It is not a plan inside Defender for Cloud, and it does not offer per-resource protection plans for Azure VMs, so selecting this option would be incorrect.

Microsoft Sentinel

Why it fails: Microsoft Sentinel is a cloud-native SIEM/SOAR solution that ingests logs and performs incident investigation, not a workload protection plan within Defender for Cloud. While Sentinel can integrate with Defender for Cloud to collect and analyze security alerts, it is a distinct service and not a plan that you enable for VM protection.

The SecurityAlert table does not contain malware alerts.

Why it fails: The SecurityAlert table is a central alerts table in Microsoft Sentinel that ingests alerts from all connected sources, including malware detections from Defender and other security products. Its schema includes the AlertName, Severity, and TimeGenerated columns, so the absence of results cannot be due to the table lacking malware alerts. The table contains all security alerts, so this explanation misidentifies the cause.

The time range filter is incorrect.

Why it fails: The time range filter, typically written as `TimeGenerated > ago(7d)`, is a valid KQL expression that correctly captures the last seven days. If the user knows alerts exist in that window, the filter is not causing the zero-result outcome. The problem is not the time range but the case-sensitive string comparison on the alert name.

There are no high-severity alerts in the past week.

Why it fails: This option suggests that no high-severity alerts were generated in the past week, but that contradicts the user's knowledge that alerts exist. Even if high-severity alerts are present, the query's filter on the exact alert name prevents them from being returned. Removing or correcting the alert name filter would reveal the high-severity alerts, demonstrating that the severity filter is not the issue.

The Defender for Cloud pricing tier is set to 'Standard' but should be 'Free' for Sentinel.

Why it fails: Microsoft Sentinel is a separate SIEM service and does not require Defender for Cloud to be set to the 'Free' pricing tier. Defender for Cloud is an independent solution whose 'Standard' tier enables continuous security assessments, threat detection, and alerting—features that Sentinel can ingest and use as data sources. Downgrading to 'Free' would disable those valuable signals and would not make Sentinel work better or any more correctly.

The workspace retention is set to 90 days, but Sentinel requires at least 180 days.

Why it fails: Microsoft Sentinel does not impose a mandatory minimum retention period on the underlying Log Analytics workspace. The 90-day retention setting is a valid, configurable value and can be adjusted to meet an organization's compliance or cost requirements. Some built-in analytics rules or user data types might benefit from longer retention, but there is no platform-level requirement of 180 days that must be met before Sentinel can be enabled.

The Log Analytics workspace SKU is set to 'PerGB2018' but Sentinel requires 'PerNode'.

Why it fails: PerGB2018 is the correct consumption-based pricing SKU for Log Analytics workspaces used with Microsoft Sentinel; it bills based on data volume ingested. PerNode is a legacy OMS pricing model that is not supported for new workspaces or for Sentinel onboarding. Therefore the template's 'PerGB2018' setting is not an error, and the option incorrectly reverses the actual requirement.

The analytics rule is disabled due to a pricing tier downgrade.

Why it fails: A Microsoft Sentinel pricing tier downgrade (for example, moving from Standard to Free, or reducing capacity reservation) does not disable existing analytics rules. Sentinel analytics rules remain enabled and continue to execute based on their configured schedule and query regardless of the workspace's pricing tier, though some features may be limited by the Free tier (e.g., fewer machine learning models). The scenario describes the rule as enabled, so this is not the reason for zero alerts.

The rule's trigger threshold is set too high (e.g., 100 events).

Why it fails: The scenario does not mention any threshold, and an analytics rule with no explicit threshold would fire on every query result, making a high threshold (e.g., 100 events) an unlikely cause. Even if a threshold existed, it would not explain the problem, because the grouping issue means each IP appears once; a per-group count threshold would rarely be exceeded. The question's premise is that the rule should detect new IPs, not a count of events per IP, so a threshold is irrelevant here.

The SigninLogs data connector is not properly configured and is ingesting data with a 24-hour delay.

Why it fails: A 24-hour ingestion delay in SigninLogs would cause alerts to be generated late, but they would still eventually fire if the query matched the delayed data. A properly configured connector that ingests data with a delay does not outright suppress alert generation; the rule would run on the available data and produce delayed results. For zero alerts, the connector would need to be completely failing or the data completely missing, which is not what the option describes, so this is not the root cause.

NIST SP 800-53 Rev. 5

Why it fails: NIST SP 800-53 Rev. 5 is a US federal security and privacy controls catalog, and Azure Policy's built-in regulatory-compliance initiative for it maps to controls such as SC-12 (cryptographic key establishment and management) rather than enforcing a direct audit that storage accounts use customer-managed keys. Its policy definitions are organized by control families, not by Azure resource-specific audit patterns, so a naked assignment would not flag a storage account solely for missing CMK. It is therefore not the initiative purpose-built for this audit requirement.

ISO 27001:2013

Why it fails: ISO 27001:2013 is an information-security management standard, and its Azure Policy regulatory-compliance initiative is built around Annex A controls such as A.10.1.1 (policy on the use of cryptographic controls) and A.18.1.3 (protection of records), not a granular Azure resource audit for storage encryption key source. The initiative includes many controls and policies, but none are specifically designed to audit all storage accounts for customer-managed key usage, so it would not produce the targeted CMK compliance signal you need.

CIS Microsoft Azure Foundations Benchmark

Why it fails: Although CIS Microsoft Azure Foundations Benchmark is available as a built-in Azure Policy initiative, it is structured as a list of benchmark recommendations (for example, ensure secure transfer required, ensure no public access), and it does not contain a discrete policy that audits storage accounts for customer-managed keys. Its encryption-related checks focus on TLS and shared access signatures, not on the keySource property that governs CMK. For this reason, assigning the CIS initiative would not directly flag storage accounts lacking customer-managed keys.

AzureActivity | where OperationName contains 'encrypt' | summarize count() by Resource

Why it fails: AzureActivity stores control-plane audit logs from Azure Resource Manager, capturing operations like VM creation or disk encryption when you explicitly act on an Azure resource. It does not see guest OS–level data-plane events such as individual files being created or encrypted on a virtual machine. A filter on `OperationName contains 'encrypt'` therefore surfaces only management operations (e.g., `Microsoft.Compute/disks/encrypt/action`), not ransomware file activity, making this query incapable of detecting encrypted files.

SecurityEvent | where EventID == 4688 | summarize count() by Computer, bin(TimeGenerated, 5m)

Why it fails: SecurityEvent collects Windows security audit logs, and EventID 4688 specifically tracks process creation via Windows Security Auditing. While ransomware does spawn processes, filtering solely on process creation yields an extremely broad result set and does not directly indicate that files are being encrypted. This query has no reference to file names, extensions, or encryption-related behavior, so it cannot reliably identify ransomware activity or distinguish it from benign applications that create processes.

CommonSecurityLog | where DeviceEventClassID == 'ransomware' | summarize count() by DeviceName

Why it fails: CommonSecurityLog ingests syslog or CEF-format messages from network appliances and security devices such as firewalls and proxies, not endpoint file-system telemetry. `DeviceEventClassID` is a vendor-defined string that may contain words like 'ransomware' in a threat-intel feed, but there is no standard mapping that guarantees this field represents actual file-encryption events. Unlike dedicated file-event tables, CommonSecurityLog lacks native fields like `FileName` or `FileCreateTime`, so it cannot properly search for encrypted file artifacts.

Contributor on the subscription

Why it fails: Contributor can manage Azure resources and deploy VMs, but it lacks the Microsoft.Security/locations/jitNetworkAccessPolicies/write and other Microsoft.Security control-plane actions used by Defender for Cloud to configure JIT. Enabling JIT is a security policy operation, not a standard resource management operation, so Contributor's generic wildcard on resources does not extend to Microsoft.Security/... endpoints. As a result, a Contributor would receive an authorization error when attempting to enable JIT on a VM.

Reader on the subscription

Why it fails: Reader provides only read-only access to Azure resources, meaning it has no permission to execute write actions such as creating or modifying a JIT network access policy. The JIT enablement process requires a PUT request to the jitNetworkAccessPolicies endpoint, which is a write operation that Reader explicitly forbids. Consequently, an account with Reader on the subscription cannot invoke this action or change any Defender for Cloud security settings.

Owner on the subscription

Why it fails: Owner has all permissions, including those needed to enable JIT, but it is not the correct answer because it violates the principle of least privilege by granting far more access than required. The Security Admin role already contains the specific Microsoft.Security/jitNetworkAccessPolicies write actions, so there is no need to assign the subscription Owner role for this task. Using Owner would expose the organization to unnecessary risk and is not the minimum role needed to administer JIT.