Visit here for our full Microsoft SC-200 exam dumps and practice test questions.
Question 91
You need to detect suspicious activity in Azure Cosmos DB, including unauthorized key regeneration, unusual query patterns, and unauthorized access to collections. Which log source should be ingested into Microsoft Sentinel?
A) Cosmos DB Diagnostic Logs
B) DeviceProcessEvents
C) Azure AD Sign-in Logs
D) DeviceNetworkEvents
Answer: A) Cosmos DB Diagnostic Logs
Explanation
Cosmos DB Diagnostic Logs provide comprehensive monitoring for Azure Cosmos DB, capturing both control-plane and data-plane activity. This makes them the correct log source for detecting suspicious database operations. Attackers who compromise cloud credentials or a workload may attempt to regenerate Cosmos DB keys, query sensitive collections, enumerate databases, or exfiltrate large volumes of high-value data. These actions are captured within Cosmos DB Diagnostic Logs, which include metadata such as operation type (Read, Query, Create, Replace, Delete), request charge (RU consumption), timestamps, caller IP address, database and collection names, and whether the operation succeeded. DeviceProcessEvents track endpoint processes and cannot detect cloud database activity. Azure AD Sign-in Logs only record authentication attempts and provide no insight into query-level operations. DeviceNetworkEvents captures network flow data and cannot identify database actions or unauthorized data access. Cosmos DB Diagnostic Logs help detect anomalies such as high-frequency queries indicative of data scraping, unauthorized key regeneration attempts, or unexpected access from unfamiliar service principals. When integrated with Sentinel, these logs empower SOC teams to create threat detection rules identifying abuse, privilege escalation attempts, or potential data exfiltration patterns. They also support long-term forensic investigations by correlating database activity with identity and workload behavior. Because Cosmos DB is often used to store sensitive customer, transactional, or operational data, monitoring it is critical. Thus, Cosmos DB Diagnostic Logs are the correct choice for detecting suspicious activity in Cosmos DB.
Question 92
Your SOC team wants to detect unauthorized modifications to Azure Virtual Machine disk settings, such as disk detachments, snapshot deletions, or adding new disks for data exfiltration. Which log source provides this visibility?
A) Azure Activity Logs
B) DeviceFileEvents
C) Azure AD Audit Logs
D) DeviceLogonEvents
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the authoritative source for detecting control-plane modifications to Azure Virtual Machine disks. Attackers often target VM disks to detach them for offline access, delete snapshots to destroy forensic evidence, or attach new disks to facilitate data exfiltration or persistence. Activity Logs capture all these operations, including disk attach/detach events, snapshot creation or deletion, disk encryption configuration changes, and disk import/export operations. DeviceFileEvents only capture local filesystem actions occurring within a running OS and cannot detect cloud disk modifications. Azure AD Audit Logs track directory-level identity changes and provide no visibility into VM disk events. DeviceLogonEvents track login activity but cannot reveal disk operations. Activity Logs include key metadata such as the requestor identity, API call executed, resource identifiers, timestamps, and IP address of the entity performing the operation. This allows SOC analysts to detect suspicious disk activity quickly. Examples of malicious behavior detectable through Activity Logs include a compromised admin detaching disks from critical VMs, creating snapshots for data theft, or disabling disk encryption. Because these logs capture all ARM-based administrative operations, ingested Activity Logs enable Sentinel to generate alerts on unauthorized or anomalous VM disk actions. Therefore, Azure Activity Logs are the correct log source.
Question 93
You need to detect suspicious Power BI behavior, such as unauthorized dataset exports, report sharing with external users, and unusual administrative changes to the Power BI tenant. Which log source should be ingested into Sentinel?
A) Power BI Activity Log
B) Azure AD Sign-in Logs
C) NSG Flow Logs
D) Microsoft Defender for Endpoint Alerts
Answer: A) Power BI Activity Log
Explanation
The Power BI Activity Log is the correct source for detecting suspicious activity within the Power BI environment because it captures all administrative and user-driven operations within the service. Attackers who compromise a Power BI account may attempt to export datasets, share reports externally, or modify tenant-level governance settings. These actions can lead to data exposure or manipulation of critical business intelligence assets. The Power BI Activity Log records activities such as report views, dataset exports, data refresh failures, workspace changes, sharing events, and administrative actions including tenant setting modifications. Azure AD Sign-in Logs capture authentication attempts but cannot show what Power BI actions occurred after login. NSG Flow Logs track network flows but cannot interpret Power BI usage patterns. Defender for Endpoint Alerts detect endpoint-based threats but not cloud analytics activities. Power BI Activity Logs provide detailed context such as the user identity, dataset accessed, report interacted with, action performed, timestamp, and whether the action was performed from an external or unmanaged device. When fed into Sentinel, these logs help detect abnormal behaviors such as mass dataset downloads, unusual export patterns, unexpected sharing outside the organization, or sudden permission changes. For organizations relying heavily on Power BI for sensitive analytics, the Activity Log is essential for monitoring and protecting these assets. Therefore, the Power BI Activity Log is the correct ingestion source.
Question 94
Your SOC wants to detect when Azure Event Hub is being abused for unauthorized data ingestion, exfiltration, or manipulation of event streams. Which log source should be connected to Sentinel to gain visibility into Event Hub operations?
A) Azure Event Hub Diagnostic Logs
B) DeviceNetworkEvents
C) Azure AD Audit Logs
D) DeviceProcessEvents
Answer: A) Azure Event Hub Diagnostic Logs
Explanation
Azure Event Hub Diagnostic Logs provide full visibility into event publishing, consumer group activity, connection attempts, authentication failures, and throughput anomalies. Event Hub is widely used as a streaming ingestion service, making it a valuable target for attackers attempting data exfiltration or service abuse. Attackers may attempt to publish malicious data, consume large volumes of messages, manipulate offsets, or hijack connections from compromised keys. Event Hub Diagnostic Logs capture details such as send/receive operations, IP addresses, authentication type, consumer group membership, error codes, and throttling events. DeviceNetworkEvents only monitor endpoint network traffic and cannot capture cloud event-stream operations. Azure AD Audit Logs monitor directory-level identity events but not streaming data. DeviceProcessEvents track process execution locally and cannot detect Event Hub interactions. By integrating Event Hub Diagnostic Logs into Sentinel, SOC analysts can monitor for unauthorized access, abnormal data volume, suspicious spikes in event publishing, or unexpected consumer access from unknown IPs. These insights help detect attackers who attempt to manipulate or steal data from real-time streams. Therefore, Event Hub Diagnostic Logs are the correct source.
Question 95
Your SOC needs to detect suspicious activity in Azure API connections used by Logic Apps, Power Automate, and Azure Functions, such as unauthorized connection creation, credential misuse, or unusual API request patterns. Which log source should be ingested into Sentinel?
A) Azure API Connection Diagnostic Logs
B) DeviceSecurityEvents
C) Azure Firewall Threat Intelligence
D) Azure AD Sign-in Logs
Answer: A) Azure API Connection Diagnostic Logs
Explanation
Azure API Connection Diagnostic Logs provide detailed telemetry for API connections used across Logic Apps, Power Automate, and Functions. These connections often store credentials, OAuth tokens, and service endpoints required to integrate with third-party or Microsoft services. Attackers may attempt to exploit or modify these API connections to exfiltrate data, impersonate workflows, or pivot across cloud resources. Diagnostic Logs capture operations such as connection creation, updates, deletion, failed authentication attempts, token refresh anomalies, and API request metadata. DeviceSecurityEvents relate only to Windows endpoint events and cannot detect cloud API connection behavior. Azure Firewall Threat Intelligence monitors network communication but cannot detect API connection misuse or workflow activity. Azure AD Sign-in Logs provide authentication activity but cannot reveal which API connections were modified or used. With API Connection Diagnostic Logs in Sentinel, analysts can detect unauthorized modifications, abnormal access patterns, suspicious connector usage by workflows, and potentially compromised service credentials. Because these logs expose both configuration and runtime API request behavior, they are the correct choice for securing automation environments.
Question 96
Your SOC wants to detect suspicious or unauthorized operations in Azure Backup, such as disabling backup protection, deleting backup vaults, or modifying retention policies. These actions could allow attackers to destroy recovery options before launching ransomware. Which log source should be ingested into Sentinel?
A) Azure Activity Logs
B) Azure AD Sign-in Logs
C) DeviceProcessEvents
D) NSG Flow Logs
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the correct log source for detecting suspicious operations targeting Azure Backup because they capture every control-plane action related to Backup Vaults, Recovery Services vaults, backup policies, and protection configurations. Attackers who compromise privileged accounts often attempt to weaken or dismantle backup protections before initiating destructive activities like ransomware or large-scale data deletion. They may disable backup protection on virtual machines, remove items from backup policies, modify retention rules, or delete Recovery Services vaults entirely. Azure Activity Logs record these actions, including who initiated them, the resource affected, the timestamp, the API method invoked, and whether the operation succeeded. Azure AD Sign-in Logs only track authentication attempts and cannot detect backup configuration changes. DeviceProcessEvents only capture endpoint behavior and are unrelated to cloud backup operations. NSG Flow Logs track network flows but do not log backup configuration actions. Because backup systems serve as a last line of defense, monitoring their configuration is critical. Activity Logs allow SOC teams to detect unauthorized modifications such as disabling protection, reducing retention periods, or deleting restore points. When ingested into Sentinel, analysts can build rules to immediately alert on high-risk operations like “Disable Backup Protection” or “Delete Backup Vault.” Correlating these events with identity behavior further strengthens incident detection. For these reasons, Azure Activity Logs are the correct source.
Question 97
Your SOC team wants to detect suspicious use of Azure Service Bus, including unauthorized queue access, abnormal message send/receive rates, and access from untrusted networks. Which log source should be integrated into Sentinel?
A) Azure Service Bus Diagnostic Logs
B) DeviceSecurityEvents
C) Azure AD Audit Logs
D) DeviceNetworkEvents
Answer: A) Azure Service Bus Diagnostic Logs
Explanation
Azure Service Bus Diagnostic Logs provide deep visibility into queue and topic operations, making them the correct source for detecting suspicious or malicious activity. Attackers may attempt to consume sensitive messages, flood queues to cause denial-of-service conditions, inject malicious payloads, or manipulate subscriptions to intercept internal communications. Service Bus Diagnostic Logs capture details such as Send, Receive, Complete, Abandon, and DeadLetter operations, along with authentication details, sender identity, IP address, and timestamps. DeviceSecurityEvents monitor local device security events, not cloud-based message queues. Azure AD Audit Logs record identity directory changes but do not capture Service Bus interactions. DeviceNetworkEvents only monitor network connections and cannot detect queue operations. Service Bus Diagnostic Logs allow SOC analysts to detect abnormal spikes in send/receive activity, unauthorized client connections, repeated authentication failures, or suspicious queue enumeration attempts. In Sentinel, these logs can be correlated with other identity and network data to detect multi-stage attacks involving cloud messaging abuse. Because Service Bus often handles sensitive workflows and integrations, monitoring it with diagnostic logs is essential to identifying compromised workloads or stolen credentials. Therefore, Azure Service Bus Diagnostic Logs are the correct choice.
Question 98
You need to detect when attackers modify Azure Application Gateway settings, such as backend pool changes, listener updates, or disabling WAF protections. These modifications could expose applications to attacks or redirect traffic to attacker-controlled systems. Which log source should be ingested into Sentinel?
A) Azure Activity Logs
B) Azure WAF Logs
C) DeviceFileEvents
D) Azure AD Sign-in Logs
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the correct detection source for identifying unauthorized modifications to Application Gateway configurations because they capture all control-plane operations executed through Azure Resource Manager (ARM). Attackers who compromise administrative privileges may modify backend pools, update routing rules, change SSL certificates, remove listeners, or disable WAF protections to facilitate further exploitation. Activity Logs capture metadata such as the user or service principal initiating the request, the API call used, timestamps, IP address, and the specific resource modified. Azure WAF Logs capture data-plane activity such as blocked or allowed web requests, but they do not record configuration changes. DeviceFileEvents track local file modifications and have no relevance to cloud configuration. Azure AD Sign-in Logs monitor authentication but cannot detect Application Gateway modifications. In Sentinel, analysts can build detection rules for high-risk changes like deletion of listeners, disabling WAF, or unauthorized backend redirection. Because Activity Logs offer complete visibility into Application Gateway administrative operations, they are the correct source for detecting configuration tampering.
Question 99
Your SOC needs to detect unauthorized changes to Azure Monitor Alerts, such as disabling critical alerts, modifying thresholds, or deleting alert rules. Attackers may attempt to silence monitoring systems before executing malicious activity. Which log source should you integrate with Sentinel?
A) Azure Activity Logs
B) DeviceEvents
C) Azure AD Sign-in Logs
D) Microsoft 365 Audit Logs
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the authoritative source for detecting configuration changes to Azure Monitor Alerts. When attackers compromise privileged accounts, they frequently attempt to disable or weaken alerting systems to hide malicious activity. This may include lowering thresholds for CPU or network alerts, changing severity levels, disabling rules, or deleting entire alert configurations. Azure Activity Logs capture these actions by logging ARM-based operations with metadata including the identity making the change, subscription, resource group, timestamps, and API calls executed. DeviceEvents capture local endpoint activity and cannot detect cloud monitoring configuration changes. Azure AD Sign-in Logs track authentication but not alert rule modifications. Microsoft 365 Audit Logs focus on M365 services, not Azure Monitor Alerts. By ingesting Activity Logs into Sentinel, SOC teams can detect high-risk operations such as “Microsoft.Insights/scheduledQueryRules/delete” or “write” operations that indicate alert tampering. These logs allow rapid detection of attempts to blind security monitoring. Therefore, Azure Activity Logs are the correct source.
Question 100
Your SOC wants to monitor for suspicious activity in Azure Web Apps, such as unauthorized code deployments, configuration changes, or manipulation of authentication settings. Which log source provides full visibility into Web App administrative actions?
A) Azure Activity Logs
B) App Service HTTP Logs
C) Azure AD Sign-in Logs
D) DeviceProcessEvents
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs provide comprehensive visibility into administrative operations performed on Azure Web Apps, such as deploying new code, modifying configuration settings, altering environment variables, updating authentication methods, or changing custom domains. Attackers who gain access to Azure may attempt to tamper with Web Apps to deploy malicious code, redirect traffic, disable authentication, or modify backend connections. Activity Logs track all ARM-level operations including writes, deletes, updates, and configuration actions. App Service HTTP Logs capture only incoming HTTP traffic, not administrative modifications. Azure AD Sign-in Logs monitor authentication but cannot reveal Web App configuration changes. DeviceProcessEvents monitor endpoint activity and are unrelated to cloud Web App operations. By ingesting Activity Logs into Sentinel, SOC teams can detect unauthorized deployments, suspicious configuration changes, and identity misuse. These logs allow correlation with code repository changes, identity events, and VM telemetry to identify supply-chain or cloud-native attacks. Because Activity Logs capture all Web App administrative changes, they are the correct log source.
Question 101
Your SOC needs to detect suspicious activity in Azure App Configuration, such as unauthorized modifications to feature flags, configuration keys, or app settings that could compromise application behavior. Which log source must be ingested into Sentinel?
A) Azure App Configuration Diagnostic Logs
B) DeviceFileEvents
C) Azure AD Audit Logs
D) NSG Flow Logs
Answer: A) Azure App Configuration Diagnostic Logs
Explanation
Azure App Configuration Diagnostic Logs provide full visibility into all administrative and operational actions performed within Azure App Configuration, making them the correct source for detecting unauthorized modifications. Attackers who gain access to cloud identities or automation may attempt to manipulate application behavior by modifying key-value pairs, changing feature flags, altering configuration settings, or deleting critical configuration entries. Such changes can disable security features, redirect services to malicious endpoints, or break application stability. App Configuration Diagnostic Logs capture details such as the exact configuration key modified, old and new values, timestamp, identity performing the action, client IP address, and API method invoked. DeviceFileEvents record only local file changes and cannot monitor cloud configuration actions. Azure AD Audit Logs track directory changes but provide no insight into App Configuration activity. NSG Flow Logs capture network flows but cannot detect configuration-level operations. With Diagnostic Logs ingested into Sentinel, SOC analysts can detect anomalies such as unexpected updates from unfamiliar service principals, rapid or bulk configuration changes, off-hours modifications, or unauthorized deletion of feature flags. This log data supports threat hunting for supply-chain manipulation attempts and ensures that configuration integrity is maintained. Because App Configuration Diagnostic Logs are the only source that captures configuration-level operations, they are the correct choice.
Question 102
Your SOC team wants to detect suspicious behavior in Azure Logic Apps Standard (the isolated single-tenant version), such as unauthorized workflow deployments, runtime manipulation, and unusual connector usage. Which log source provides the required visibility?
A) Logic Apps Standard Diagnostic Logs
B) Azure AD Sign-in Logs
C) DeviceProcessEvents
D) Azure Firewall Logs
Answer: A) Logic Apps Standard Diagnostic Logs
Explanation
Logic Apps Standard Diagnostic Logs deliver comprehensive end-to-end monitoring for workflow executions, deployment operations, runtime behavior, and connector interactions within the single-tenant Logic Apps environment. Attackers who compromise credentials may attempt to deploy malicious workflows, alter triggers, manipulate environment variables, or modify connectors to exfiltrate sensitive data. Diagnostic Logs capture telemetry such as workflow run details, action invocations, trigger executions, pipeline deployment actions, failure events, and HTTP request payloads. Azure AD Sign-in Logs monitor authentication attempts but not workflow operations. DeviceProcessEvents record endpoint process activity and cannot detect cloud workflow executions. Azure Firewall Logs capture network flows, not internal Logic Apps activity. Logic Apps Standard Diagnostic Logs allow SOC analysts to detect suspicious workflow updates, off-hours deployments, unauthorized connector access, and unusual request patterns. Because they expose both configuration and runtime details, these logs are essential for detecting automation-based attacks. Therefore, Logic Apps Standard Diagnostic Logs are the correct source for monitoring Logic Apps Standard security posture.
Question 103
Your organization wants to detect malicious use of Azure Cognitive Search, such as unauthorized index access, abnormal query patterns, high-volume data extraction, or unauthorized index updates. Which log source should be integrated into Sentinel?
A) Azure Cognitive Search Diagnostic Logs
B) DeviceNetworkEvents
C) Azure AD Sign-in Logs
D) DeviceSecurityEvents
Answer: A) Azure Cognitive Search Diagnostic Logs
Explanation
Azure Cognitive Search Diagnostic Logs are the authoritative and essential log source for detecting malicious, unauthorized, or anomalous behavior within Azure Cognitive Search environments. Cognitive Search is widely used by organizations to aggregate, index, and retrieve structured and unstructured data from a wide variety of sources such as Azure Storage, Cosmos DB, SQL databases, SharePoint, and custom document repositories. Because search indexes often contain metadata extracted from sensitive documents, classification tags, embedded PII, confidential terms, and deep insights about internal information, they become a valuable target for attackers. Threat actors who gain access to a Cognitive Search service may attempt to exfiltrate indexed data, manipulate index content, poison search results, delete important indexes, or issue malicious queries that degrade system functionality. Azure Cognitive Search Diagnostic Logs provide the deep telemetry necessary to detect those behaviors.
These logs include two major categories of insights: data-plane activity and control-plane operations. On the data plane, Cognitive Search Diagnostics capture every search query executed, including query text, search terms, scoring profiles, filters, facets, paging instructions, result counts, and query parameters. They also record index updates, document ingestion, merge or delete operations, and indexer execution results. Cloud applications rely heavily on these queries for retrieving data, so having complete visibility is essential for determining whether queries are being used normally or as vectors for abuse.
On the control plane, Diagnostic Logs capture administrative operations such as index creation, schema modifications, updating scoring profiles, rebuilding or resetting indexes, enabling or disabling indexers, rotating API keys, and updating data source configurations. Each of these actions can have a dramatic impact on the confidentiality, integrity, or availability of search data. Attackers who successfully compromise Cognitive Search configuration may attempt to manipulate indexes to hide malicious content, corrupt search results, poison data quality, or delete indexes to disrupt applications.
Diagnostic Logs include granular metadata such as the identity performing the operation, timestamp, client IP address, caller type, search service name, index name, and operation status. For search queries, logs capture the exact terms that were queried. For index operations, they capture the object modified, fields added or deleted, and the type of schema change performed. This rich telemetry allows SOC analysts to reconstruct events precisely, determine whether an action was authorized, and identify patterns that reveal malicious intent.
DeviceNetworkEvents, in contrast, provide only endpoint-level network telemetry. They show that a machine communicated with a Cognitive Search endpoint, but offer no insight into what query was executed, what index was accessed, or whether the activity was suspicious. Network logs cannot interpret query contents, cannot identify document ingestion patterns, and cannot reveal control-plane modifications. They simply lack the semantic visibility needed for search service security monitoring.
Azure AD Sign-in Logs record authentication activity such as successful and failed logins, token issuance, conditional access outcomes, and identity risk signals. While these logs are essential for detecting compromised accounts, they provide no visibility into Cognitive Search operations. Even if an attacker successfully authenticates using a stolen key or compromised identity, only Cognitive Search Diagnostic Logs reveal what queries, updates, or administrative changes were performed after authentication.
DeviceSecurityEvents are limited to Windows endpoint security events such as malware detections, suspicious processes, exploit attempts, and device-level threat signals. They do not monitor cloud search service activity. Even if a compromised endpoint is used to execute malicious queries against Cognitive Search, DeviceSecurityEvents will show only the local process behavior, not the search activity itself.
Indexer execution logs are also critical. A compromised identity might attempt to alter an indexer’s configuration to ingest malicious files, corrupt trusted content, or replace legitimate document sources with attacker-controlled ones. Diagnostic Logs show when indexers are run, fail, or are manually triggered outside normal schedules. They also reveal unexpected connections to data sources, which can indicate tampering.
Control-plane attacks against Cognitive Search are equally dangerous. Deleting an index can cripple an application. Updating an index schema to remove specific fields can hide data. Changing sorting logic or scoring profiles can manipulate search results. Disabling an indexer can halt data ingestion, leading to stale or misleading search results. All of these operations appear clearly in Cognitive Search Diagnostic Logs, enabling SOC analysts to differentiate between legitimate administrative actions and malicious tampering.
These logs also assist in insider threat detection. Employees with legitimate access to Cognitive Search could misuse their permissions by querying sensitive indexes not required for their work, modifying index schemas without approval, or extracting aggregated customer data via broad queries. Diagnostic Logs capture these actions and allow SOC teams to detect misuse patterns that deviate from baseline behavior.
Finally, Cognitive Search Diagnostic Logs support compliance, audit readiness, and post-incident investigations. Because they provide timestamped, identity-rich, operation-specific records, organizations can demonstrate accountability and traceability for search data access and modifications. In the event of a breach, these logs serve as forensic evidence for determining what was accessed or changed.
For all these reasons, Azure Cognitive Search Diagnostic Logs are the correct and essential log source for detecting malicious activity targeting Cognitive Search resources.
Question 104
Your SOC needs to detect suspicious or unauthorized modifications to Azure Virtual Desktop (AVD) host pools, application groups, or session host settings. Attackers may attempt to reconfigure AVD to hijack user sessions or gain access to sensitive environments. Which log source should be connected to Sentinel?
A) Azure Activity Logs
B) Windows Event Logs
C) Azure AD Sign-in Logs
D) DeviceFileEvents
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the authoritative and indispensable source for monitoring administrative operations performed against Azure Virtual Desktop (AVD) resources. These logs capture every control-plane action executed through Azure Resource Manager (ARM), providing SOC teams with complete visibility into configuration changes, infrastructure modifications, and administrative activity that affects the security and stability of AVD environments. Because AVD represents a mission-critical remote desktop infrastructure platform, often used for secure access to corporate applications, sensitive workloads, developer workstations, and regulated environments, maintaining the integrity of its configuration is essential. Azure Activity Logs offer the level of observability required to detect, investigate, and respond to malicious or unauthorized modifications across AVD components.
Azure Virtual Desktop relies heavily on ARM for managing host pools, session hosts, application groups, workspaces, scaling plans, load balancing configurations, and networking associations. Every time an administrator—or an attacker using compromised credentials—modifies one of these components, ARM generates an event recorded in Azure Activity Logs. These events include detailed metadata that is critical for forensic analysis and threat detection. The logs capture information such as the identity performing the operation, whether it is a human user, automation account, managed identity, or service principal; the exact operation being executed; the timestamp; the resource impacted; the subscription and resource group context; the API version used; and the success or failure of the operation. This level of authoritative telemetry enables SOC teams to uncover unauthorized administrative actions before attackers can use them to pivot into session environments or compromise user access.
One of the most dangerous attack vectors involving AVD is unauthorized modification of host pool configurations. Host pools define the set of session hosts available for user connections and specify load-balancing behavior, session limits, and assignment policies. Attackers who gain elevated Azure privileges may attempt to alter a host pool to redirect user sessions to malicious session hosts under their control, or to remove legitimate session hosts to disrupt operations. Azure Activity Logs capture these host pool modification events, including updates to friendly names, max session limits, assignment types, validation environments, or load-balancing settings. Without these logs, such critical changes could occur unnoticed, enabling sophisticated supply-chain–style attacks on desktop virtualization infrastructure.
Similarly, session host registration is a sensitive operation. Attackers may attempt to register rogue virtual machines as session hosts, allowing them to capture user credentials, intercept traffic, or insert malware into the remote desktop environment. Azure Activity Logs track every session host registration event, including which identity initiated the registration and when it occurred. If a session host is unexpectedly added or removed, SOC teams can detect the anomaly immediately through Activity Logs. This visibility is especially important in large, dynamic AVD deployments where session hosts scale automatically and administrators rely on automated processes that attackers may attempt to exploit.
Application groups define which applications users can access within AVD, such as published desktops or RemoteApp programs. Misconfigurations or unauthorized changes to application groups can expose sensitive applications to unauthorized users or revoke access for legitimate users. Attackers who compromise administrative roles may update application groups to grant themselves or malicious accounts access to high-value applications. Azure Activity Logs capture these changes, including updates to group assignments, application definitions, and user mappings. SOC teams analyzing these logs can immediately detect unusual modifications to application availability or user entitlements.
Scaling plans, used to automatically scale session hosts based on demand, also represent a potential attack vector. Attackers might modify scaling rules to force shutdown of infrastructure, reduce available capacity, or create excessive session hosts to generate cost damage. Azure Activity Logs capture all modifications to scaling plans, including schedule changes, capacity targets, minimum and maximum host counts, and ramp-up/ramp-down settings. Detecting unauthorized modifications to scaling behavior is essential for maintaining service availability and preventing cost-based sabotage.
Other log sources commonly misunderstood as AVD-relevant do not provide visibility into these ARM-level administrative activities. Windows Event Logs capture events inside individual AVD session hosts, such as user logons, process creation, security events, and system operations. While useful for detecting malware or unauthorized activity within a specific host, they cannot detect changes made to the AVD environment from the Azure portal or ARM API. If an attacker alters a host pool or deletes a session host definition, Windows logs will not register that event.
Azure AD Sign-in Logs focus exclusively on identity authentication events. They record sign-ins, token issuance, conditional access decisions, and risky login detections. While these logs are crucial for detecting compromised administrator accounts, they do not record the actual configuration changes those accounts perform after signing in. Azure AD Sign-in Logs may show that an administrator authenticated from an unusual location, but only Azure Activity Logs show whether that administrator modified an AVD resource afterward.
DeviceFileEvents are irrelevant to AVD control-plane operations. These logs capture file-level activity on Windows endpoints protected by Defender for Endpoint. They cannot detect modifications made to Azure resources. Even if an attacker uses a compromised endpoint to change AVD settings, the device logs will only show local processes but not the ARM calls used to modify AVD infrastructure.
In contrast, Azure Activity Logs provide the definitive visibility required to detect and respond to control-plane attacks against AVD. When ingested into Microsoft Sentinel, SOC teams can create analytics rules that detect suspicious administrative behavior, such as unexpected deletion of host pools, removal of scaling plans, registration of rogue session hosts, or unauthorized modification of application groups. Analysts can correlate Activity Logs with logon anomalies, Defender alerts, network telemetry, and identity-based risk indicators to identify multi-stage attacks targeting AVD environments.
For example, a sophisticated attacker may first compromise an Azure AD administrator account, then use that privilege to modify AVD host pool networking settings, add a malicious session host, change an application group, or disable diagnostics. Only Azure Activity Logs provide the necessary record of these operations. By analyzing these logs, SOC teams can catch early signs of compromise and respond before attackers harvest user credentials, exfiltrate data, or disrupt remote access infrastructure.
Protecting Azure Virtual Desktop requires strong governance and continuous monitoring of control-plane operations, and Azure Activity Logs are the correct and essential log source for achieving that visibility.
Question 105
Your SOC wants to detect when attackers attempt to tamper with Azure Log Analytics Workspace settings, such as modifying data retention periods, deleting custom logs, or altering workspace access control. Which log source must be ingested into Sentinel?
A) Azure Activity Logs
B) DeviceProcessEvents
C) Azure AD Sign-in Logs
D) NSG Flow Logs
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the authoritative control-plane telemetry source for monitoring administrative actions performed against Azure Log Analytics Workspaces. These logs capture every management operation executed through Azure Resource Manager (ARM), which is the API-driven control plane for creating, modifying, and deleting Azure resources. Because ARM governs the configuration and lifecycle of Log Analytics Workspaces, Azure Activity Logs provide the only complete, tamper-resistant visibility into changes that could impact logging integrity, retention, or security posture. For SOC teams relying heavily on Sentinel for threat detection and forensic evidence, monitoring Activity Logs becomes a foundational requirement.
Log Analytics Workspaces serve as the central repository for telemetry ingestion across Azure monitoring, Microsoft Sentinel, and multiple security-related services. They store logs from Azure Activity Logs, Azure AD Sign-in Logs, Defender for Cloud data, Storage Analytics Logs, Key Vault diagnostics, SQL auditing, and dozens of other data sources. As such, compromising a workspace—or modifying its configuration—can cripple an organization’s ability to detect malicious behavior or investigate incidents. Attackers who gain privileged access know this, and they may attempt to weaken or destroy log retention, disable ingestion, or modify access control configurations to silence the SOC’s visibility. Azure Activity Logs provide the granular insight necessary to detect such tampering quickly.
Azure Activity Logs capture events such as modifying workspace retention policies, deleting or purging tables, enabling or disabling diagnostic settings, regenerating workspace keys, altering access control assignments, or updating data export rules. Each entry includes rich metadata that allows SOC teams to reconstruct administrative actions with precision. This metadata includes the caller identity, whether it was a user, a service principal, or a managed identity; the API endpoint invoked; the exact operation name; the timestamp; the target resource; the subscription and resource group IDs; and the result of the operation. Because these logs are generated at the ARM layer, they cannot be suppressed by simply tampering with Log Analytics itself—making them a trustworthy and authoritative source for tracking administrative changes.
For example, if an attacker compromises a Global Administrator or an Owner role assignment, one of their first objectives may be to modify workspace retention settings. By reducing retention to a minimal number of days, attackers can cause older logs to be purged automatically. Azure Activity Logs capture any update to the retention policy, including which identity performed the modification. Similarly, disabling diagnostic settings on critical Azure resources prevents future logs from being written to the workspace. Azure Activity Logs record these changes as well, enabling the SOC to detect logging suppression attempts in real time.
Deleting tables or purging large volumes of logs is another method attackers use to erase forensic evidence. Even though Sentinel retains some of its own tracking, the raw logs stored in the workspace are essential for investigation. Azure Activity Logs record administrative purge requests and table deletion operations. If a malicious actor deletes the Security table, modifies the Heartbeat table, or removes custom logs used for critical detections, the Activity Logs provide a clear trace of who initiated the action and when.
Azure AD Sign-in Logs, while critical for detecting compromised identities, cannot detect control-plane changes to Log Analytics Workspaces. They show authentication activity, conditional access evaluations, token issuance, and risk detections, but they do not capture actions such as retention updates or diagnostic setting modifications. Even if an attacker successfully authenticates using a stolen identity, only Azure Activity Logs reveal what configuration changes they perform after authentication.
DeviceProcessEvents capture process execution, command-line usage, and file interactions on endpoints monitored by Defender for Endpoint. These logs are invaluable for detecting malware, persistence mechanisms, and lateral movement on Windows, macOS, or Linux machines, but they cannot observe cloud resource modifications. Administrative actions taken against Azure Workspaces occur entirely within the Azure control plane; no endpoint processes are involved. Thus, DeviceProcessEvents offer no visibility into Log Analytics tampering.
NSG Flow Logs provide network-layer telemetry within Azure virtual networks, showing IP flows, ports, and traffic direction. They are designed for network forensics, not control-plane auditing. They cannot reveal whether an attacker has changed retention policies, disabled logs, or altered workspace keys. Even if malicious activity originates from a compromised VM, NSG Flow Logs capture only the traffic—not administrative actions performed through ARM.
Because Sentinel itself depends on Log Analytics to function, detecting attempts to weaken or disable logging is essential for preserving the platform’s integrity. Sentinel cannot detect threats effectively if attackers have crippled its data source, which is why Azure Activity Logs must remain thoroughly monitored.
Azure Activity Logs also support forensic reconstruction following a breach. If logs were deleted or retention shortened, investigators can use Activity Logs to identify exactly when the change occurred and which identity initiated it. This is crucial for understanding attacker behavior, pinpointing privilege escalation, and determining the timeline of malicious activity. Without Activity Logs, organizations may be left without a reliable record of administrative actions, severely limiting incident response effectiveness.
Additionally, Azure Activity Logs protect against insider threats. Privileged insiders may attempt to modify workspace settings to hide unauthorized activity, disable ingestion for sensitive resources, or purge data that could expose misuse. Activity Logs capture these actions regardless of whether the insider uses the Azure Portal, PowerShell, CLI, Terraform, API calls, or third-party tools.
In Zero Trust architectures, monitoring control-plane activity is as important as monitoring data-plane activity. Azure Activity Logs provide the only comprehensive visibility into control-plane operations on Log Analytics Workspaces. Without these logs, organizations cannot enforce least-privilege controls, detect role misuse, or investigate workspace-level attacks.
Because Log Analytics is the backbone of Sentinel’s entire detection ecosystem, protecting its configuration is mission-critical. Azure Activity Logs provide the authoritative visibility necessary to identify tampering, misuse, or malicious modifications, making them the correct choice for detecting attacks targeting Log Analytics Workspace configurations.