Visit here for our full Microsoft SC-200 exam dumps and practice test questions.
Question 181
Your SOC must detect unauthorized or suspicious modifications to Azure Firewall Threat Intelligence settings, such as disabling threat intelligence filtering, switching from “Alert and Deny” to “Alert Only,” or adding custom allow rules that bypass threat detection. Which log source should be ingested into Sentinel?
A) Azure Activity Logs
B) Azure Firewall Threat Intelligence Logs
C) NSG Flow Logs
D) DeviceSecurityEvents
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the correct source for detecting control-plane changes to Azure Firewall Threat Intelligence settings because these changes occur via ARM-based modifications rather than through data-plane behavior. Threat Intelligence configurations determine how the firewall identifies and blocks traffic associated with known malicious IPs, domains, and command-and-control infrastructures. Attackers who compromise cloud administrative credentials may attempt to weaken security by switching Threat Intelligence from “Alert and Deny” to a less secure “Alert Only” mode, disabling the feature entirely, or introducing custom rules that override global protections. Azure Activity Logs capture every such configuration modification, including details about who made the change, the time of the update, the originating IP address, the API action invoked (“Microsoft.Network/azureFirewalls/write”), and the exact configuration attributes altered. Azure Firewall Threat Intelligence Logs show data-plane detections but not configuration modifications. NSG Flow Logs record network traffic flows and cannot reveal changes to security policies. DeviceSecurityEvents relate only to endpoint-level security telemetry. By ingesting Activity Logs into Sentinel, SOC analysts can detect unauthorized attempts to weaken network security posture and correlate these events with identity anomalies or suspicious configuration changes elsewhere in the environment. Because the firewall is a core security control, monitoring its Threat Intelligence settings is a critical part of defending Azure environments.
Question 182
Your SOC wants to detect unauthorized or suspicious modifications to Azure Load Balancer inbound NAT rules, such as exposing new ports, changing backend VM mappings, or disabling secure ports. Which log source should be connected to Sentinel?
A) Azure Activity Logs
B) Load Balancer Health Probe Logs
C) NSG Flow Logs
D) Azure AD Audit Logs
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the correct log source for detecting unauthorized modifications to inbound NAT rules for Azure Load Balancer because NAT rule creation, modification, and deletion all occur as ARM control-plane operations. NAT rules determine which inbound ports are exposed on the load balancer and which backend resources receive that traffic. Attackers may attempt to open sensitive management ports (e.g., 22, 3389) to the internet, redirect NAT traffic to compromised VMs, or remove rules that protect administrative endpoints. Azure Activity Logs capture these critical configuration changes, including the user making the change, the timestamp, originating IP, and details about the specific NAT rule updated. Load Balancer Health Probe Logs only indicate backend health—they do not track NAT rule modifications. NSG Flow Logs show network traffic flows but cannot detect NAT configuration updates. Azure AD Audit Logs focus on identity directory operations and cannot monitor load balancer configurations. In Sentinel, ingesting Activity Logs allows SOC analysts to create alerts for unauthorized port exposure, unexpected backend VM changes, or off-hours NAT rule updates, all of which could indicate compromise or misconfiguration. Because NAT rules can expose critical systems to attack, monitoring them via Activity Logs is essential.
Question 183
Your SOC must detect unauthorized or suspicious changes to Azure Data Factory integration runtime settings, such as switching from managed IR to self-hosted IR, modifying compute configuration, or redirecting IR network routing. Which log source should be ingested?
A) Azure Activity Logs
B) Data Factory Pipeline Run Logs
C) NSG Flow Logs
D) DeviceProcessEvents
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the correct log source for detecting integration runtime (IR) configuration changes in Azure Data Factory because IR settings—including compute type, network integration, scaling behavior, and connection routing—are all managed at the ARM control-plane layer. An attacker who gains administrative access could weaken security by switching to a self-hosted IR to redirect data flows through compromised machines, adjusting IR compute resources for cryptomining, or modifying VNet and private endpoint associations to intercept sensitive data transfers. Azure Activity Logs capture each of these configuration changes including metadata such as the performing identity, timestamp, IP address, and the exact API operation performed (“Microsoft.DataFactory/factories/integrationRuntimes/write”). Data Factory Pipeline Run Logs reflect pipeline execution events—successful runs, failures, parameter values—but do not capture IR configuration modifications. NSG Flow Logs record network flows but cannot detect IR changes. DeviceProcessEvents track local host processes and are irrelevant to cloud IR configuration. In Sentinel, ingesting Activity Logs helps SOC analysts detect unauthorized data routing, suspicious compute configuration updates, or tampering with integration runtimes. Because IR determines how and where data moves across the environment, monitoring these changes through Activity Logs is essential.
Question 184
Your SOC wants to detect suspicious or unauthorized modifications to Azure App Service Authentication providers, such as switching identity providers, disabling authentication entirely, or altering token validation settings. Which log source should be used?
A) Azure Activity Logs
B) App Service Authentication Logs
C) NSG Flow Logs
D) Azure AD Sign-in Logs
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the correct logging source for detecting unauthorized modifications to App Service Authentication providers because all provider configuration settings—such as enabling/disabling authentication, modifying OAuth/OIDC provider settings, updating client IDs, or altering token validation rules—are ARM-based configuration changes. Attackers may attempt to weaken security by switching to an insecure provider, disabling authentication altogether, or replacing trusted provider configurations with malicious endpoints. Azure Activity Logs record operations like “Microsoft.Web/sites/config/authsettingsV2/write,” capturing critical metadata including who made the change, when, from where, and what configuration values were altered. App Service Authentication Logs capture runtime authentication events but not administrative configuration modifications. NSG Flow Logs show network traffic, not authentication provider updates. Azure AD Sign-in Logs capture authentication attempts but cannot reflect App Service configuration changes. In Sentinel, ingesting Activity Logs allows SOC analysts to detect unauthorized or suspicious authentication configuration updates—an essential capability because modifying authentication settings is one of the fastest ways an attacker can compromise access controls. Therefore, Azure Activity Logs are the correct ingestion source.
Question 185
Your SOC must detect unauthorized or suspicious changes to Azure Storage replication configurations, such as switching from GRS to LRS, disabling cross-region redundancy, or modifying failover priority. Which log source should be connected to Sentinel?
A) Azure Activity Logs
B) Storage Analytics Logs
C) Azure AD Audit Logs
D) DeviceSecurityEvents
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the correct log source for detecting configuration changes to Azure Storage replication settings because replication mode changes—such as switching between LRS, ZRS, GRS, and RA-GRS—are performed via ARM control-plane operations. Attackers or malicious insiders may weaken durability and disaster recovery protections by switching to lower-redundancy models, disabling cross-region replication, or modifying failover policies. These actions can significantly increase the risk of data loss during an attack or disaster scenario. Azure Activity Logs capture all such replication configuration changes with metadata such as the performing identity, timestamp, original and updated replication settings, IP address of the requester, and the specific API call invoked (“Microsoft.Storage/storageAccounts/write”). Storage Analytics Logs focus on data-plane operations (reads, writes, deletions) and cannot detect replication configuration updates. Azure AD Audit Logs capture directory operations but do not track storage replication changes. DeviceSecurityEvents reflect on-premises endpoint security activity and are irrelevant to cloud data-redundancy settings. In Sentinel, ingesting Activity Logs helps SOC teams detect unauthorized attempts to weaken storage durability, manipulate failover behavior, or disable geo-replication to make destructive attacks irreversible. Therefore, Azure Activity Logs are the correct ingestion source.
Question 186
Your SOC must detect unauthorized or suspicious modifications to Azure API Management (APIM) Named Values, such as altering connection strings, injecting malicious URLs, or modifying secrets used across APIs. Which log source should be ingested into Sentinel?
A) Azure Activity Logs
B) APIM Gateway Logs
C) Azure AD Sign-in Logs
D) DeviceSecurityEvents
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the correct source for detecting configuration changes to APIM Named Values because these settings—often containing sensitive configurations such as credentials, backend URLs, OAuth secrets, and custom connection strings—are managed via ARM. Attackers who compromise administrative privileges may attempt to manipulate Named Values to redirect API calls to malicious endpoints, insert harmful secrets, or weaken the integrity of backend communication. Named Values are frequently used across multiple APIs, meaning a single modification can compromise an entire API ecosystem. Azure Activity Logs record all changes to APIM configuration objects, including Named Values, with essential metadata such as the performing identity, timestamp, the API used (“Microsoft.ApiManagement/service/namedValues/write”), the originating IP address, and the specific fields altered. APIM Gateway Logs provide visibility into data-plane activities like request/response logs but cannot detect administrative configuration changes. Azure AD Sign-in Logs show authentication activity only and cannot reveal configuration-level tampering. DeviceSecurityEvents monitor endpoint-level behavior and are irrelevant in this context. In Sentinel, ingesting Azure Activity Logs allows SOC analysts to identify unauthorized configuration updates, track malicious attempts to inject harmful settings, and detect identity-based compromise scenarios. Because Named Values often hold sensitive keys and configuration details, ensuring their integrity is crucial. Therefore, Azure Activity Logs are the correct ingestion source.
Question 187
Your SOC wants to detect unauthorized changes to Azure Policies assigned at the management group level, such as removing regulatory compliance policies or altering critical security configurations. Which log source should be used?
A) Azure Activity Logs
B) Azure AD Audit Logs
C) Azure Monitor Metrics
D) NSG Flow Logs
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the correct log source for monitoring changes to Azure Policies at the management group level because all policy assignments, modifications, and removals occur through ARM. Policies assigned at this level affect entire cloud environments and enforce compliance frameworks like CIS, NIST, ISO 27001, PCI DSS, and others. Attackers or compromised insiders may attempt to remove or weaken these policies to bypass compliance enforcement, deploy insecure configurations, or hide malicious actions. Activity Logs capture ARM actions such as “Microsoft.Authorization/policyAssignments/write” with detailed metadata including the performing identity, timestamp, IP address, subscription context, and the exact policy object changed. Azure AD Audit Logs record directory-level operations, but they do not capture Azure resource governance changes. Azure Monitor Metrics track resource performance and cannot log policy modifications. NSG Flow Logs record network traffic, not configuration updates. By ingesting Activity Logs into Sentinel, SOC analysts can detect suspicious policy changes at the highest governance levels, including unauthorized exemption creation, policy deletion, or assignments being weakened. Because management group policies serve as foundational guardrails for enterprise governance, monitoring their integrity is critical. Thus, Azure Activity Logs are the correct ingestion source.
Question 188
Your SOC team must detect unauthorized or suspicious modifications to Azure Cosmos DB role assignments, such as assigning high-privilege roles to unauthorized identities or removing essential least-privilege roles. Which log source should be ingested?
A) Azure Activity Logs
B) Cosmos DB Diagnostic Logs
C) Azure AD Sign-in Logs
D) DeviceProcessEvents
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the correct log source for detecting unauthorized modifications to Cosmos DB role assignments because Cosmos DB RBAC and role assignments are managed through ARM. Attackers may attempt to escalate privileges by granting themselves high-level database roles, removing restrictive roles, or enabling administrative-level access to sensitive data. Cosmos DB often houses globally replicated, mission-critical data, making RBAC integrity vital. Azure Activity Logs capture role assignment changes such as “Microsoft.DocumentDB/databaseAccounts/sqlRoleAssignments/write” and include rich contextual information like the user performing the operation, timestamp, IP address, subscription path, and details of the new role mapping. Cosmos DB Diagnostic Logs track data-plane activity—queries, updates, and endpoint interactions—but not role configuration updates. Azure AD Sign-in Logs record authentication events only. DeviceProcessEvents relate to local machine activity and cannot observe cloud resource configuration. In Sentinel, ingesting Activity Logs allows SOC analysts to detect unauthorized increases in database privileges, the removal of least-privilege restrictions, or suspicious changes performed during off-hours. Because role assignments are foundational to Cosmos DB data access, monitoring their modification is essential. Therefore, Azure Activity Logs are the correct ingestion source.
Question 189
Your SOC wants to detect unauthorized modifications to Azure App Configuration stores, such as altering key–value pairs, modifying feature flags, or injecting malicious configuration settings used by applications. Which log source should be used?
A) Azure Activity Logs
B) App Configuration Diagnostic Logs
C) Azure AD Sign-in Logs
D) NSG Flow Logs
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the correct source for monitoring configuration changes to App Configuration stores because the creation, modification, or deletion of configuration stores, feature flags, and key–value pairs happens through ARM operations. App Configuration often serves as a centralized configuration layer for distributed applications, and attackers who gain administrative access may insert malicious configuration values, alter backend connection URLs, disable critical feature flags, or inject behaviors that compromise application integrity. Azure Activity Logs capture these actions through operations such as “Microsoft.AppConfiguration/configurationStores/write,” with detailed metadata including the acting identity, timestamp, IP address, and specific changes applied. App Configuration Diagnostic Logs provide data-plane visibility into key retrieval and request activity but do not capture control-plane configuration modifications. Azure AD Sign-in Logs capture authentication attempts but cannot record configuration updates. NSG Flow Logs track network traffic, not configuration changes. In Sentinel, ingesting Activity Logs helps SOC analysts detect unauthorized tampering that could potentially enable application-level attacks, redirect data flows, or disable important security features. Because App Configuration is often mission-critical, monitoring configuration integrity is essential. Thus, Azure Activity Logs are the correct ingestion source.
Question 190
Your SOC must detect unauthorized or suspicious modifications to Azure Search Service configurations, such as altering API keys, weakening query restrictions, or modifying indexer configurations to include sensitive data. Which log source should be ingested into Sentinel?
A) Azure Activity Logs
B) Search Service Query Logs
C) Azure Monitor Metrics
D) DeviceSecurityEvents
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the correct log source for detecting unauthorized configuration changes to Azure Search Service because all control-plane actions—such as API key regeneration, security configuration updates, indexer definition changes, and network access modifications—occur through ARM operations. Attackers who gain administrative access may regenerate admin keys, weaken IP restrictions, modify access policies, or adjust indexers to pull sensitive data from unprotected sources. These actions can expose search endpoints, compromise data confidentiality, or enable large-scale data exfiltration. Azure Activity Logs record operations such as “Microsoft.Search/searchServices/write,” capturing vital information including the identity performing the change, timestamp, originating IP, the fields updated, and the operation details. Search Service Query Logs show data-plane search activity but cannot detect configuration changes. Azure Monitor Metrics record performance and availability metrics only. DeviceSecurityEvents reflect endpoint-level events and are irrelevant for cloud search configurations. By ingesting Activity Logs into Sentinel, SOC analysts can detect unauthorized API key regenerations, suspicious indexer updates, changes to encryption settings, or new network exposure pathways added by attackers. Because Azure Search often indexes sensitive enterprise data, maintaining configuration integrity is critical. Thus, Azure Activity Logs are the correct ingestion source.
Question 191
Your SOC must detect unauthorized or suspicious modifications to Azure Cognitive Search indexers, such as adding new data sources, altering field mappings, or enabling access to sensitive unstructured files. Which log source should be ingested into Sentinel?
A) Azure Activity Logs
B) Cognitive Search Query Logs
C) DeviceSecurityEvents
D) Azure AD Audit Logs
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the correct log source for detecting unauthorized or suspicious modifications to Azure Cognitive Search indexers because all configuration changes—including creating new indexers, altering field mappings, modifying index schedules, or connecting to additional data sources—occur through ARM-based control-plane actions. Cognitive Search indexers often serve as the ingestion pipeline for structured and unstructured data, pulling information from Storage accounts, SQL databases, Cosmos DB, or custom data sources. If an attacker compromises administrative access, they could modify indexer configurations in ways that expose sensitive data, redirect ingestion, or include files and locations that were never intended to be indexed. This could result in unintended data exposure or allow attackers to index internal files for reconnaissance.
Azure Activity Logs capture these configuration changes with critical metadata: the identity performing the operation, the timestamp, IP address, the specific operation invoked (for example, “Microsoft.Search/searchServices/indexers/write”), and details about the resource being changed. This provides SOC analysts with the ability to detect anomalous or unauthorized updates reflecting privilege misuse. Query Logs only capture data-plane activity—search queries and interactions—but they do not track configuration changes to indexers. DeviceSecurityEvents are endpoint logs and do not apply to cloud configuration. Azure AD Audit Logs track changes to directory objects and identities but do not include Azure resource configuration modifications. By ingesting Activity Logs into Sentinel, SOC analysts can quickly detect unauthorized additions of high-risk data sources, suspicious field mapping changes, or indexer updates that could lead to data leakage or malicious data ingestion. Monitoring Cognitive Search configuration integrity is critical because improper indexing can expose sensitive information to search endpoints or external consumers. Therefore, Azure Activity Logs are the correct ingestion source.
Question 192
Your SOC wants to detect unauthorized or suspicious changes to Azure Kubernetes Service (AKS) cluster API server access settings, such as enabling public access, modifying IP allowlists, or disabling authorized IP ranges. Which log source should be ingested?
A) Azure Activity Logs
B) AKS Kube-Audit Logs
C) NSG Flow Logs
D) Azure Firewall Logs
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the correct source for detecting changes to AKS API server access settings because these settings are controlled via ARM operations. The Kubernetes API server is the cluster’s central management plane and controls all administrative operations. Attackers who compromise privileged Azure accounts may attempt to weaken access security by enabling public API access, modifying allowed IP ranges, disabling private API endpoints, or opening the cluster to the internet. These actions can expose the entire Kubernetes environment and allow attackers to perform arbitrary administrative actions within the cluster.
Azure Activity Logs record all operations related to AKS API server access, including “managedClusters/write,” capturing key metadata such as the identity performing the operation, timestamp, originating IP address, and the specific configuration changes applied (such as updated authorized IP ranges). AKS Kube-Audit Logs capture internal Kubernetes API server operations—such as creating pods, modifying RBAC, or executing commands—but do not capture Azure-level configuration changes. NSG Flow Logs only record network traffic and cannot detect configuration modifications. Azure Firewall Logs show traffic inspection data and cannot detect changes to AKS API access rules. By ingesting Activity Logs into Sentinel, SOC analysts can detect unauthorized exposure of the Kubernetes API surface, suspicious changes to IP allowlists, or toggling of public and private access settings. This ensures the cluster remains protected against external attacks and unauthorized administrative access. Thus, Azure Activity Logs are the correct ingestion source.
Question 193
Your SOC must detect unauthorized modifications to Azure Key Vault key rotation policies, such as extending rotation intervals, disabling automatic rotation, or modifying expiration settings. Which log source should you ingest?
A) Azure Activity Logs
B) Key Vault Access Logs
C) DeviceLogonEvents
D) Azure AD Sign-in Logs
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the correct source for detecting unauthorized or suspicious changes to Key Vault key rotation policies because all rotation policy configurations—including update of rotation intervals, disabling automatic rotation, or modifying expiry dates—are performed through ARM. Key rotation is a critical component of cryptographic hygiene. Attackers who gain access to privileged credentials may manipulate rotation policies to weaken cryptographic controls and maintain long-term access to encrypted data.
Azure Activity Logs capture operations such as “Microsoft.KeyVault/vaults/keys/rotationPolicy/write,” recording key metadata including the performing identity, timestamp, source IP, and specific changes to rotation schedules. Key Vault Access Logs provide data-plane visibility—such as when keys are used for encryption, decryption, or signing—but do not log configuration changes. DeviceLogonEvents track endpoint logons and have no relevance to Key Vault configuration. Azure AD Sign-in Logs capture authentication events but do not reflect changes in key configuration.
Ingesting Activity Logs into Sentinel allows SOC analysts to detect malicious attempts to disable or manipulate rotation policies, including suspicious extension of rotation intervals, disabling key expiration, or implementing insecure rotation rules. These types of changes may indicate an attacker’s effort to prolong their access to sensitive data, prevent detection of compromise, or undermine encryption controls. Because Key Vault is a cornerstone of Azure’s secure infrastructure, monitoring rotation policy integrity is absolutely critical. Therefore, Azure Activity Logs are the correct ingestion source.
Question 194
Your SOC wants to detect unauthorized changes to Azure Automation Hybrid Worker Groups, such as adding compromised machines, altering job routing policies, or removing secure worker nodes. Which log source should be used?
A) Azure Activity Logs
B) Automation Job Logs
C) DeviceSecurityEvents
D) Azure AD Audit Logs
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the authoritative and correct source for detecting unauthorized or suspicious modifications to Azure Automation Hybrid Worker Groups because every meaningful configuration action—group membership changes, worker registration, routing rule adjustments, and group-level property updates—is performed through Azure Resource Manager at the control-plane layer. Hybrid Worker Groups are a critical extension of Azure Automation, allowing organizations to run runbooks inside private networks, isolated environments, and on-premises infrastructure, rather than exclusively in Azure’s cloud execution environment. This makes them especially valuable for automation scenarios requiring access to sensitive assets such as internal databases, domain controllers, secure file servers, application clusters, financial systems, or legacy workloads. However, this capability also makes Hybrid Workers an attractive target for attackers seeking persistence, privileged script execution, and lateral movement across hybrid environments. Azure Activity Logs provide the only complete visibility into the control-plane actions that govern how Hybrid Worker Groups operate.
Hybrid Worker Groups rely on ARM-based resource operations for core configuration tasks. When administrators create a Hybrid Worker Group, assign workers to it, update its routing rules, change hybrid job execution settings, or modify its underlying configuration, these operations are carried out as ARM interactions. Azure Activity Logs capture every one of these interactions, including Microsoft.Automation/automationAccounts/hybridRunbookWorkerGroups/write operations, group property updates, registration events, worker addition or removal, configuration version changes, and group metadata modifications. Each entry in Activity Logs includes the identity performing the action, the timestamp, the client IP address, the subscription and resource group context, the target resource, and granular details describing what was changed. This level of visibility is required to detect malicious control-plane modifications that could redirect automation workloads into adversarial hands.
Attackers who compromise administrative access, elevated service principals, Azure Automation contributors, or CI/CD pipelines that interact with Hybrid Workers may attempt to manipulate Hybrid Worker Groups for several malicious purposes. One technique involves adding a compromised or rogue host into a Hybrid Worker Group. Because Hybrid Workers execute runbooks using local system privileges or highly privileged service accounts inside private networks, an attacker could weaponize Hybrid Worker access to run malicious scripts on internal servers, extract credentials, spread malware, or pivot deeper into protected environments. Azure Activity Logs record the registration and assignment of new workers, making it possible to detect when an unexpected machine joins the group.
Another risk scenario involves modifying routing rules so that sensitive runbooks—such as those handling configuration management, credential rotation, compliance enforcement, or administrative maintenance—are routed to hostile worker machines. An attacker might redirect high-value runbooks toward a worker under their control, allowing them to intercept secrets, alter operational workflows, or sabotage scripts. Azure Activity Logs capture routing rule updates, including the identity responsible and the target worker group, allowing SOC analysts to correlate these changes with suspicious activity patterns.
Attackers may also remove legitimate workers to disable automation pipelines, disrupt operational workflows, or mask their own malicious insertions. Automation outages can serve as a distraction during coordinated attacks, or they can force administrators to run emergency procedures manually, providing attackers with opportunities for social engineering or privilege escalation. Because Activity Logs record deletion events and parameter modifications for Hybrid Worker Groups, analysts can quickly identify when legitimate workers disappear unexpectedly.
Some attackers may tamper with automation resource configurations at a more subtle level. For example, they may alter diagnostic settings to reduce monitoring visibility, change metadata to evade detection tools, or modify job placement behaviors so that automation runs silently on compromised hybrid nodes. Azure Activity Logs provide full insight into these configuration modifications, offering an essential foundation for SOC alerting, hunting, and investigation.
Azure Automation Job Logs, in contrast, only capture runbook execution details at the data-plane level. These logs record information such as job start and end times, runbook output, error messages, and execution status. They do not track changes to Hybrid Worker Group configuration, worker membership, or routing policies. An attacker could manipulate Hybrid Worker groups without triggering job-level logs until after the malicious configuration is complete. Relying on Automation Job Logs alone would leave organizations blind to the initial stages of an Automation-based attack.
DeviceSecurityEvents, which originate from Microsoft Defender for Endpoint, capture telemetry from individual Windows or Linux machines. These may show suspicious processes, malware detections, exploit attempts, or script execution on endpoint devices. While valuable for understanding whether a Hybrid Worker host has been compromised, these logs do not track Azure configuration changes. DeviceSecurityEvents cannot reveal who added a hybrid worker to a group, modified routing settings, or altered network access policies. Only Azure Activity Logs capture these cloud-level actions.
Azure AD Audit Logs monitor directory-level changes such as user creation, group membership updates, application registration modifications, and privileged role assignments. Although these logs are vital for uncovering identity compromise and privilege misuse, they do not record changes made to Azure Automation Hybrid Worker Groups. Attackers may escalate privileges to gain Automation access, which would appear in Azure AD Audit Logs, but only Azure Activity Logs reveal what changes were applied to Hybrid Worker Groups once the identity was compromised.
From a governance perspective, Hybrid Worker Groups pose special risks because they operate inside trusted networks. They bridge the gap between Azure and on-premises systems, allowing cloud automation to act on internal infrastructure. Unauthorized modifications to Hybrid Worker Groups can transform this bridge into an attacker’s entry point into private networks, making Activity Log monitoring a core requirement for hybrid security posture management.
In forensic scenarios, Azure Activity Logs provide essential evidence. Investigators can reconstruct the exact sequence of actions taken against Hybrid Worker Groups, determine which identities made changes, and correlate configuration tampering with compromised runbook executions or suspicious endpoint activity. Because Activity Logs are immutable and timestamped, they serve as a reliable source for breach reconstruction and regulatory reporting.
Because Hybrid Workers often execute privileged runbooks that interact with sensitive systems, any compromise could have widespread impact across enterprise infrastructure. Monitoring configuration integrity through Azure Activity Logs enables SOC teams to detect early signs of Hybrid Worker manipulation, prevent misuse of automation capabilities, and protect hybrid environments from deep compromise.
Question 195
Your SOC must detect unauthorized modifications to Azure Backup vault encryption settings, such as switching encryption keys, disabling customer-managed keys, or modifying the encryption type. Which log source should be ingested?
A) Azure Activity Logs
B) Backup Reports Logs
C) DeviceSecurityEvents
D) Azure Monitor Metrics
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the authoritative and essential telemetry source for detecting unauthorized modifications to Azure SQL Managed Instance configurations. SQL Managed Instances are enterprise-grade, fully managed database platforms designed to offer near-full SQL Server compatibility in a cloud-native environment. Because they frequently host mission-critical corporate data—financial records, authentication stores, customer PII, operational datasets, manufacturing telemetry, and business-logic objects—they represent one of the most sensitive infrastructure layers in an organization’s Azure footprint. Any attacker who gains privileged access to the Azure control plane may attempt to modify Managed Instance settings to weaken security, expose the environment, disrupt continuity, or facilitate covert access. Azure Activity Logs provide complete visibility into these control-plane operations, making them the correct ingestion source for SOC teams monitoring configuration integrity.
Azure SQL Managed Instance configurations are governed entirely through Azure Resource Manager. This includes settings related to networking, authentication, parameter group management, maintenance windows, failover groups, deployment mode, backup retention, Key Vault integrations, DNS zone settings, public endpoint status, private endpoint bindings, virtual cluster assignment, and high availability configurations. Every update to these configurations is executed via ARM calls such as Microsoft.Sql/managedInstances/write, Microsoft.Sql/managedInstances/operations, or other supporting resource modification APIs. Azure Activity Logs record these changes with high-fidelity metadata, including the identity performing the change, the timestamp, the requester’s IP address, the subscription and resource group, and the exact configuration fields that were updated.
One of the most dangerous types of control-plane tampering involves network exposure. Managed Instances typically operate within private virtual networks, providing strong isolation and preventing direct connections from the public internet. Attackers with Contributor or Owner permissions may attempt to enable public endpoints, broaden firewall rules, or alter subnet assignments to make the Managed Instance reachable from malicious infrastructure. Azure Activity Logs capture these networking modifications, allowing SOC analysts to detect early indicators of compromise.
Another critical risk involves tampering with high availability, automated failover, or geo-replication configurations. Managed Instances often form part of failover group topologies that ensure business continuity across regions. Attackers may attempt to modify failover policies, disable geo-replication, or reconfigure secondary replicas to redirect data to unauthorized regions. They may also manipulate maintenance window settings to create operational blind spots during which they can perform high-risk activities without scrutiny. Azure Activity Logs record all such operations, enabling investigation into irregular patterns or unauthorized policy shifts.
Security configurations are another popular target for attackers. They may weaken encryption requirements, adjust TDE (Transparent Data Encryption) configurations, reassign Key Vault integrations, modify Active Directory authentication settings, or change administrators on the Managed Instance. These actions could facilitate credential theft, unauthorized decryption, or impersonation through modified authentication flows. Azure Activity Logs capture these updates in the control plane, offering the visibility necessary to identify exploitation attempts before they escalate into large-scale data exfiltration events.
Attackers may also manipulate performance or operational parameters to degrade service availability. For example, altering the compute tier, reducing the instance size, modifying storage performance limits, or disabling critical automation can mimic DDoS-style disruptions without generating recognizable traffic anomalies. Such sabotage may be used as part of extortion attempts or as a distraction tactic while attackers perform data-plane operations elsewhere. Azure Activity Logs provide immutable traces of these control-plane actions, helping SOC teams distinguish between benign scaling operations and malicious configuration alterations.
SQL Managed Instance Auditing Logs, while extremely valuable for understanding data-plane activity—such as login attempts, T-SQL queries, object modifications, role assignments, failed authentications, and schema updates—cannot detect control-plane configuration changes. These logs operate exclusively within the SQL engine. Even if an attacker successfully modifies network exposure or reconfigures failover rules, these actions may not generate SQL-level auditing events. This is why Activity Logs must be used in conjunction with SQL Auditing Logs to monitor the full attack surface.
NSG Flow Logs only monitor traffic patterns crossing network security groups. They can identify unusual traffic flows to or from Managed Instances but cannot detect ARM-layer configuration changes. An attacker might enable public exposure for a Managed Instance, and NSG logs will later show external connections, but the critical moment—the configuration change that made the attack possible—is captured only in Azure Activity Logs.
DeviceProcessEvents from Microsoft Defender for Endpoint are similarly insufficient. These logs capture endpoint-level activities such as suspicious process execution, command-line parameters, malicious script execution, credential-stealing behaviors, or tampering with system components. While useful for detecting compromises on administrative machines, DeviceProcessEvents do not record cloud resource changes. Even if a compromised endpoint triggers an ARM API call to change Managed Instance settings, DeviceProcessEvents will not reveal the actual configuration modification in Azure.These detections allow SOC teams to identify early signs of infrastructure tampering, privilege misuse, or cloud-native attack progression.
Azure Activity Logs also fulfill critical roles in governance, compliance, and audit readiness. Organizations operating Managed Instances under regulatory frameworks such as HIPAA, SOX, PCI DSS, GDPR, FedRAMP, or financial compliance regimes must demonstrate strong oversight of configuration integrity. Unauthorized changes to availability, encryption, or public exposure settings can trigger compliance violations. Activity Logs provide immutable, timestamped records of every control-plane modification, enabling compliance teams to validate that all changes align with approved processes.
In forensic investigations, Activity Logs provide the foundational evidence required to reconstruct how an attacker gained control over Managed Instance settings. Investigators can use Activity Logs to determine precisely when a configuration change occurred, which identity initiated it, what API call was executed, and whether the action was part of a broader multi-vector intrusion. Without Activity Logs, critical stages of the attack timeline would remain hidden.
Because SQL Managed Instances form the backbone of many organizations’ most sensitive workloads, ensuring the integrity of their control-plane configurations is essential. Azure Activity Logs provide the only complete, authoritative, and tamper-resistant visibility into these changes. For detecting unauthorized modifications, maintaining secure governance, and enabling effective SOC monitoring, Azure Activity Logs are the correct ingestion source.