Visit here for our full Microsoft SC-200 exam dumps and practice test questions.

Question 121

Your SOC wants to detect suspicious or unauthorized modifications to Azure DevTest Labs configurations, such as changing VM policies, altering auto-shutdown settings, or modifying allowed VM images. Which log source should 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 correct ingestion source for detecting unauthorized or suspicious modifications to Azure DevTest Labs because they capture all control-plane administrative changes executed through ARM. DevTest Labs environments often contain controlled virtual machines, developer sandboxes, and test images that may hold sensitive data or act as gateways to larger environments. Attackers who compromise administrative credentials may attempt to modify policies such as VM auto-shutdown, allowed VM sizes, base images, user permissions, or custom artifact scripts. Activity Logs record each of these actions with metadata including the initiating identity, timestamp, operation name, subscription and resource group details, the target resource, and API version. DeviceProcessEvents only show local endpoint process executions and cannot record cloud configuration changes. Azure AD Sign-in Logs track authentication but provide no insight into DevTest Labs configurations. NSG Flow Logs show network flow patterns, not policy-level actions. By ingesting Activity Logs into Sentinel, SOC analysts gain visibility into suspicious configuration-related actions—such as enabling previously disallowed VM images, modifying auto-shutdown policies to keep malicious workloads running, or changing access settings to bypass lab guardrails. Because DevTest Labs can be misused for lateral movement, cryptomining, or unauthorized testing deployments, monitoring administrative operations is vital. Therefore, Azure Activity Logs are the correct choice.

Question 122

Your SOC must detect suspicious or unauthorized changes in Azure App Service Authentication settings, such as disabling authentication, switching identity providers, or weakening token validation settings. Which log source provides this visibility?

A) Azure Activity Logs

B) App Service HTTP Logs

C) DeviceSecurityEvents

D) Azure AD Audit Logs

Answer: A) Azure Activity Logs

Explanation

Azure Activity Logs are the correct source for monitoring configuration changes made to Azure App Service Authentication settings. App Service Authentication controls how users and applications authenticate, using identity providers such as Azure AD, Microsoft accounts, GitHub, or custom OpenID Connect providers. Attackers who compromise portal access may attempt to disable authentication entirely, change identity providers to malicious ones, weaken access token validation, or modify callback URLs to intercept authentication responses. Activity Logs record each of these control-plane changes, capturing the identity who performed the action, the timestamp, the resource affected, and the ARM operation invoked. App Service HTTP Logs only track incoming HTTP requests and cannot reflect administrative modifications. DeviceSecurityEvents capture local device-level security behavior but have no relationship to cloud authentication configuration. Azure AD Audit Logs track directory and identity-related operations, not App Service Authentication settings. By ingesting Activity Logs into Sentinel, SOC analysts can immediately detect malicious attempts to tamper with App Service Authentication, including unauthorized disabling of authentication or suspicious updates made during unusual hours. This allows for rapid response to cloud-native attacks where application access controls are the target. Therefore, Azure Activity Logs are the correct choice.

Question 123

Your SOC wants to detect suspicious or unauthorized changes to Azure Network Security Groups (NSGs), such as adding overly permissive rules, removing deny rules, or allowing inbound traffic from untrusted networks. Which log source must be ingested into Sentinel?

A) Azure Activity Logs

B) NSG Flow Logs

C) Azure AD Sign-in Logs

D) DeviceFileEvents

Answer: A) Azure Activity Logs

Explanation

Azure Activity Logs provide visibility into all NSG control-plane operations and are the correct source for detecting configuration tampering. NSG Flow Logs track actual network traffic flows, but they do not reveal which user changed a security rule or when a rule was modified. Attackers who compromise cloud identities frequently attempt to weaken network controls by adding permissive inbound rules, removing outbound restrictions, or modifying port-based restrictions to enable lateral movement, remote access, or malware communication. Azure Activity Logs record operations such as rule creation, deletion, or modification, along with identity, timestamp, requester IP, and ARM operation name. Azure AD Sign-in Logs only show authentication and do not track NSG changes. DeviceFileEvents monitor local file behavior and cannot detect cloud networking actions. Ingesting Activity Logs into Sentinel allows SOC analysts to detect unauthorized NSG modifications immediately—such as allowing inbound traffic on sensitive ports (22, 3389), adding 0.0.0.0/0 rules, or removing deny entries intended to block access from malicious networks. Because NSGs provide a critical layer of network segmentation and control in Azure, monitoring all configuration changes is vital. Thus, Azure Activity Logs are the correct answer.

Question 124

Your SOC needs to detect unauthorized modifications to Azure Kubernetes Service (AKS) RBAC, such as granting cluster-admin rights, creating privileged role bindings, or modifying Kubernetes API permissions. Which log source should be used?

A) AKS Diagnostic Logs (Kube-Audit Logs)

B) Azure AD Audit Logs

C) DeviceNetworkEvents

D) NSG Flow Logs

Answer: A) AKS Diagnostic Logs (Kube-Audit Logs)

Explanation

AKS Diagnostic Logs—specifically Kube-Audit Logs—are the correct source for detecting suspicious or unauthorized Kubernetes RBAC modifications. While Azure Activity Logs capture ARM-level operations, they do not show internal Kubernetes API actions such as creating RoleBindings, modifying ClusterRoles, granting elevated privileges, or altering service account permissions. Attackers who compromise AKS credentials or workloads may attempt to escalate privileges inside the cluster by granting admin rights, modifying RBAC rules, or altering pod security policies. Kube-Audit Logs capture Kubernetes API server activity, including who performed each action, the verb executed (create, update, delete), the resource affected (Role, ClusterRole, RoleBinding), request authentication context, user agent, and timestamp. Azure AD Audit Logs capture directory role assignments but do not reflect Kubernetes RBAC changes. DeviceNetworkEvents provide network flow logs, not Kubernetes API operations. NSG Flow Logs do not reveal internal Kubernetes behavior. By ingesting Kube-Audit Logs into Sentinel, SOC analysts can detect dangerous Kubernetes-level privilege escalations such as granting cluster-admin permissions or creating privileged service accounts. This visibility is essential for detecting attacks on cloud-native workloads. Therefore, AKS Kube-Audit Logs are the correct source.

Question 125

Your SOC wants to detect suspicious or unauthorized modifications to Azure Firewall Policy, such as altering rule collections, disabling TLS inspection, or changing filtering modes. Which log source provides the required control-plane visibility?

A) Azure Activity Logs

B) Azure Firewall Flow Logs

C) Azure Firewall Threat Intelligence Logs

D) DeviceSecurityEvents

Answer: A) Azure Activity Logs

Explanation

Azure Activity Logs are the authoritative source for detecting control-plane modifications to Azure Firewall Policies. Firewall Policies centralize and enforce rules that govern inbound and outbound network traffic across multiple firewalls. Attackers who gain privileged access may modify firewall rules to allow malicious IPs, disable TLS inspection, weaken filtering, or alter DNAT configurations. Activity Logs capture these administrative actions, recording details such as the identity performing the operation, resource path, timestamp, client IP address, and the ARM API invoked (e.g., “Microsoft.Network/firewallPolicies/ruleCollectionGroups/write”). Azure Firewall Flow Logs capture data-plane traffic behavior but cannot detect policy changes. Azure Firewall Threat Intelligence Logs provide alerts on malicious destinations but not configuration changes. DeviceSecurityEvents monitor endpoint security, unrelated to Azure network policies. Ingesting Activity Logs into Sentinel allows SOC teams to detect unauthorized changes such as adding overly permissive rules, deleting essential filtering rules, or modifying threat intelligence settings. Because Firewall Policies determine security boundaries for critical workloads, monitoring configuration integrity is essential. Thus, Azure Activity Logs are the correct choice.

Question 126

Your SOC wants to detect unauthorized modifications to Azure Private Endpoint configurations, such as granting access to untrusted networks, altering DNS integration settings, or attaching private endpoints to sensitive services without approval. Which log source should be ingested into Sentinel?

A) Azure Activity Logs

B) DeviceNetworkEvents

C) Azure AD Audit Logs

D) NSG Flow Logs

Answer: A) Azure Activity Logs

Explanation

Azure Activity Logs are the correct source for detecting control-plane modifications to Azure Private Endpoints. Private Endpoints provide secure, private access to services like Storage, SQL, Cosmos DB, and Key Vault by placing them behind a private IP address within a virtual network. Attackers who compromise privileged identities may attempt to attach private endpoints to resources in their control, misconfigure routing, or modify DNS records to reroute traffic. Azure Activity Logs capture all operations performed on Private Endpoint resources, including creating, deleting, or modifying endpoint configurations. These logs provide essential details such as the identity executing the action, timestamp, operation type, resource ID, originating IP address, and API call invoked. DeviceNetworkEvents capture only endpoint-level network flows and cannot track Azure resource changes. Azure AD Audit Logs record directory-level identity changes but do not include Private Endpoint operations. NSG Flow Logs provide insight into allowed/denied network flows but cannot detect configuration changes. By ingesting Activity Logs into Sentinel, SOC teams can detect suspicious or unauthorized Private Endpoint manipulations, such as adding unexpected VNet associations, altering private DNS zone links, or enabling endpoints on sensitive services like Key Vault or SQL without proper authorization. Because Private Endpoints significantly impact network access boundaries, monitoring their configuration is critical. Thus, Azure Activity Logs are the correct choice.

Question 127

Your SOC team wants to detect unauthorized or suspicious updates to Azure API Management gateway certificates, such as replacing client certificates, modifying TLS settings, or injecting compromised certificates. Which log source should be integrated into Sentinel?

A) APIM Diagnostic Logs

B) Azure AD Sign-in Logs

C) DeviceFileEvents

D) NSG Flow Logs

Answer: A) APIM Diagnostic Logs

Explanation

APIM Diagnostic Logs are the correct source for detecting unauthorized or suspicious certificate updates in Azure API Management. Certificates are central to secure communication between APIM gateway components and backend services. Attackers who gain administrative privileges may attempt to replace certificates with compromised ones to intercept traffic, break encryption, or impersonate services. APIM Diagnostic Logs capture detailed control-plane operations including certificate updates, key rotations, TLS setting changes, gateway configuration modifications, and trust store updates. These logs include important metadata such as the identity performing the action, timestamp, certificate thumbprint, resource path, and ARM API details. Azure AD Sign-in Logs record authentication attempts but cannot detect certificate updates. DeviceFileEvents only monitor local files and have no awareness of cloud certificate changes. NSG Flow Logs capture data-plane network traffic, not administrative certificate actions. When APIM Diagnostic Logs are ingested into Sentinel, SOC teams can detect certificate tampering attempts, unauthorized replacements, unexpected key rotations, and changes to TLS versions or cipher suites. This monitoring is crucial because a compromised certificate within APIM could allow attackers to intercept API calls or weaken encryption. Therefore, APIM Diagnostic Logs are the correct ingestion choice.

Question 128

Your SOC needs to detect suspicious activity related to Azure Batch accounts, such as unauthorized pool creation, deletion of compute nodes, or malicious job submissions. Which log source should be ingested into Sentinel?

A) Azure Activity Logs

B) Azure Batch Diagnostic Logs

C) DeviceProcessEvents

D) Azure AD Audit Logs

Answer: B) Azure Batch Diagnostic Logs

Explanation

Azure Batch Diagnostic Logs are the correct source for monitoring suspicious activities within Azure Batch environments. Batch accounts are used to run large-scale compute workloads, and attackers may attempt to abuse them by creating malicious jobs, deleting or modifying compute pools, or injecting tasks intended for cryptomining or lateral movement. Batch Diagnostic Logs capture relevant telemetry such as pool creation and deletion events, compute node lifecycle changes, job submissions, job failures, task execution details, and authentication patterns. Azure Activity Logs capture high-level resource changes but cannot monitor internal Batch workflows or task executions. DeviceProcessEvents detect only local Windows process events. Azure AD Audit Logs show directory-level changes but not Batch account activity. Batch Diagnostic Logs reveal detailed insights into job behaviors, including suspicious job payloads, repetitive failures, unknown task scripts, or unexpected scaling operations. When ingested into Sentinel, analysts can detect malicious job submissions, compromised compute nodes, or unauthorized pool adjustments. Because Batch accounts can run arbitrary code and process sensitive data, monitoring them through Diagnostic Logs is essential. Thus, Azure Batch Diagnostic Logs are the correct answer.

Question 129

Your SOC wants to monitor Azure Functions for suspicious activity, such as malicious function edits, unauthorized deployments, injection of harmful code, or unusual execution patterns. Which log source provides the necessary control-plane and runtime visibility?

A) Azure Functions Diagnostic Logs

B) DeviceSecurityEvents

C) Azure AD Sign-in Logs

D) NSG Flow Logs

Answer: A) Azure Functions Diagnostic Logs

Explanation

Azure Functions Diagnostic Logs provide full visibility into both configuration-related changes and runtime behaviors of serverless functions, making them the correct source for detecting suspicious activities. Attackers may modify function code, inject malicious scripts, alter triggers (HTTP, Event Hub, Timer), or upload harmful binaries. They may also use functions for data exfiltration or persistence through malicious scheduled executions. Functions Diagnostic Logs capture function execution details, deployment events, errors, configuration changes, identity context, trigger activity, and backend binding usage. DeviceSecurityEvents only capture endpoint security events and cannot detect Function App activity. Azure AD Sign-in Logs show authentication attempts but not function-level modifications or executions. NSG Flow Logs provide network flow information but lack insight into serverless application behavior. Monitoring Function App changes is critical because serverless workflows can be exploited to run unauthorized code across cloud workloads, perform hidden scheduled tasks, or manipulate data pipelines. In Sentinel, ingestion of Functions Diagnostic Logs allows detection of unusual execution spikes, unauthorized deployment patterns, or unexpected trigger activations. Because Functions are highly dynamic and often access sensitive resources, these logs are essential. Thus, Azure Functions Diagnostic Logs are the correct choice.

Question 130

Your SOC must detect suspicious or unauthorized changes to Azure Virtual Network DNS servers, such as altering custom DNS configurations or replacing DNS IPs to misroute traffic. Which log source should be ingested?

A) Azure Activity Logs

B) DeviceNetworkEvents

C) Azure AD Audit Logs

D) DeviceFileEvents

Answer: A) Azure Activity Logs

Explanation

Azure Activity Logs are the correct and authoritative source for detecting unauthorized modifications to Azure Virtual Network DNS server configurations. Attackers who compromise cloud administrative accounts may alter custom DNS settings to hijack name resolution, redirect traffic to malicious servers, intercept internal communication, or disrupt service discovery. Azure Activity Logs capture all ARM-based operations related to DNS server settings, including updating custom DNS IPs, switching from Azure-provided DNS to custom DNS, or modifying DHCP options. These logs include crucial metadata such as the identity performing the operation, timestamp, source IP address, subscription and resource group, and the specific API invoked. DeviceNetworkEvents capture endpoint network traffic but cannot monitor cloud network configuration changes. Azure AD Audit Logs track directory actions but do not capture VNet DNS modifications. DeviceFileEvents log local filesystem changes and are irrelevant to cloud DNS configurations. By ingesting Activity Logs into Sentinel, SOC analysts can build detections for suspicious DNS server modifications, helping prevent DNS poisoning attacks, command-and-control redirection, or stealthy network manipulation. Because DNS sits at the core of network resolution and connectivity, monitoring its configuration is critical. Thus, Azure Activity Logs are the correct choice.

Question 131

Your SOC must detect unauthorized or suspicious modifications to Azure Route Tables, such as altering next-hop addresses, adding routes that redirect traffic to malicious appliances, or removing security-critical routes. Which log source should be ingested into Sentinel?

A) Azure Activity Logs

B) NSG Flow Logs

C) Azure Firewall Logs

D) Azure AD Sign-in Logs

Answer: A) Azure Activity Logs

Explanation

Azure Activity Logs are the correct log source for detecting suspicious modifications made to Azure Route Tables because they capture all ARM-based operations involving route creation, modification, and deletion. Route Tables define how traffic traverses Azure virtual networks, and attackers who gain administrative credentials often target routing configurations to intercept, redirect, or drop traffic. A malicious actor might insert a next-hop IP address pointing to their own VM, steer traffic toward a compromised firewall, or delete security-critical routes that block outbound connectivity. Azure Activity Logs provide rich metadata for each routing change, including who performed the operation, the timestamp, IP address of the initiator, the ARM operation name, and the exact resource affected. NSG Flow Logs reveal actual traffic flow but do not log configuration changes that manipulate routing. Azure Firewall Logs track traffic inspection events but cannot detect modifications to Route Tables. Azure AD Sign-in Logs show authentication but no resource-level actions. By ingesting Activity Logs into Sentinel, SOC analysts can identify unauthorized route manipulation, including diversion of traffic to unknown appliances, deletion of essential routes, or attempts to override default system routes. Monitoring these logs is critical because routing changes can facilitate command-and-control channels, internal reconnaissance, or stealthy data exfiltration. Therefore, Azure Activity Logs are the correct answer.

Question 132

Your SOC team must detect suspicious activity involving Azure SignalR Service, such as unauthorized connection attempts, abnormal message broadcasts, or unexpected access from unfamiliar identities. Which log source should be connected to Sentinel?

A) Azure SignalR Diagnostic Logs

B) DeviceLogonEvents

C) Azure AD Audit Logs

D) DeviceProcessEvents

Answer: A) Azure SignalR Diagnostic Logs

Explanation

Azure SignalR Diagnostic Logs are the correct log source for monitoring suspicious or unauthorized activity related to Azure SignalR Service, because they capture detailed operational telemetry about client connections, message broadcasts, negotiation requests, and service-level errors. Attackers may attempt to exploit SignalR endpoints to impersonate clients, intercept real-time data streams, inject malicious messages, or flood the service with connection attempts to disrupt communications. SignalR Diagnostic Logs record information such as authenticated identity, connection IDs, client IP addresses, negotiation flows, message delivery events, failures, and unusual usage patterns. DeviceLogonEvents relate only to Windows authentication events and cannot detect cloud SignalR operations. Azure AD Audit Logs track directory-level changes but do not monitor message broadcasts or SignalR client behavior. DeviceProcessEvents capture local process execution and have no relevance to SignalR traffic. By ingesting SignalR Diagnostic Logs into Sentinel, analysts can detect anomalies such as unusually high broadcast volumes, unauthorized client IDs, excessive reconnection attempts, or failed negotiations that may indicate exploitation attempts. These logs also enable correlation with identity logs to identify compromised users abusing real-time channels for data exfiltration or command distribution. Because SignalR often underpins real-time business applications, monitoring its telemetry is critical. Thus, Azure SignalR Diagnostic Logs are the correct answer.

Question 133

Your SOC wants to detect unauthorized or suspicious actions performed within Azure API for FHIR, such as unauthorized data export, manipulation of protected health information, or unauthorized access by compromised service principals. Which log source should be ingested?

A) Azure API for FHIR Diagnostic Logs

B) Azure AD Sign-in Logs

C) DeviceSecurityEvents

D) NSG Flow Logs

Answer: A) Azure API for FHIR Diagnostic Logs

Explanation

Azure API for FHIR Diagnostic Logs are the authoritative and essential telemetry source for monitoring all activity within Azure API for FHIR, a managed healthcare data service designed for regulated environments handling protected health information. Because FHIR APIs expose sensitive medical data in standardized formats such as Patient, Observation, Encounter, Condition, Immunization, and MedicationRequest resources, they represent a high-value target for attackers seeking to steal, modify, or manipulate healthcare records. Diagnostic Logs provide the detailed insights required to detect these threats, making them the correct ingestion source for security monitoring.

Azure API for FHIR Diagnostic Logs track both data-plane and operational activity. On the data plane, they capture FHIR-specific API interactions including Read, Write, Update, Delete, Patch, Search, and Bundle operations. This allows security teams to observe exactly which FHIR resources are being accessed, the methods used, and the parameters supplied with the requests. Because attackers may attempt to exfiltrate PHI by executing broad queries or performing unauthorized searches, these logs help identify abnormal patterns such as large-scale data retrievals, repeated scans of sensitive patient records, or automated enumeration of medical data.

Each log entry includes critical metadata such as the user or client identity, calling application, service principal or managed identity, timestamp, request URI, IP address, response code, and FHIR resource type accessed. This metadata gives SOC analysts deep visibility into who performed an operation and whether the activity aligned with legitimate clinical workflows or administrative tasks. For example, if a service principal that normally accesses only MedicationRequest resources suddenly issues thousands of Patient resource reads, Diagnostic Logs will capture and highlight this anomaly.

Attackers may also attempt to modify clinical data by altering Observations, Conditions, or MedicationRequests. Such tampering poses serious risks to patient safety and regulatory compliance. Diagnostic Logs capture Write and Update interactions, allowing analysts to detect unauthorized modifications or malicious attempts to alter medical records. Because each FHIR update includes resource context, analysts can determine not only that a record was modified but also what was changed.

Bulk export operations represent another critical risk. Azure API for FHIR supports the FHIR Bulk Data specification, enabling large-scale data extractions for analytics. If attackers obtain privileged access or compromise a client application, they may initiate bulk exports to steal massive volumes of PHI. Diagnostic Logs provide visibility into export jobs, their parameters, identity triggers, and response outcomes, enabling rapid detection of misuse.

Other log sources do not provide this essential visibility. Azure AD Sign-in Logs capture authentication events, such as successful or failed logins and conditional access decisions, but they do not track FHIR-level operations. DeviceSecurityEvents record endpoint-based security telemetry and offer no insight into cloud-hosted healthcare APIs. NSG Flow Logs reveal only network flow patterns and lack the application-layer semantics required to detect which FHIR resources were accessed or modified.

By ingesting Azure API for FHIR Diagnostic Logs into Microsoft Sentinel, organizations can build analytics rules that detect unauthorized data access, suspicious search patterns, anomalous usage spikes, unexpected interactions by service principals, or signs of automated scraping. Sentinel correlates FHIR events with identity anomalies, network behaviors, and other cloud signals to identify multi-stage attacks targeting healthcare systems.

Because PHI is governed by strict regulations such as HIPAA, HITECH, and GDPR, monitoring FHIR activity at the API level is not only a security best practice but also a compliance requirement. Azure API for FHIR Diagnostic Logs deliver the depth, context, and governance visibility needed to protect sensitive health data, making them the correct ingestion source.

Question 134

Your SOC team must detect unauthorized or suspicious modifications to Azure SQL Elastic Pool configurations, such as changing DTU limits, altering resource governance rules, or modifying pool membership. Which log source provides visibility into these changes?

A) Azure Activity Logs

B) Azure SQL Auditing Logs

C) DeviceNetworkEvents

D) Azure AD Audit Logs

Answer: A) Azure Activity Logs

Explanation

Azure Activity Logs are the authoritative, comprehensive, and indispensable source for detecting control-plane modifications to Azure SQL Elastic Pools. Elastic Pools are a core component of Azure SQL Database architecture, enabling organizations to manage compute and storage resources across multiple databases within a shared resource environment. Because Elastic Pools balance resources at scale, they directly influence application performance, cost efficiency, and governance controls. Attackers who gain administrative access to Azure SQL resources may attempt to modify Elastic Pool configurations for malicious purposes, including performance degradation, resource starvation, privilege abuse, or hiding evidence of unauthorized activities. Azure Activity Logs provide complete visibility into these modifications and therefore serve as the correct and essential log source for monitoring Elastic Pool governance.

Azure SQL Elastic Pools operate entirely through Azure Resource Manager (ARM), meaning all control-plane changes occur via ARM’s management plane. These include operations such as adjusting vCore counts, changing DTU limits, modifying eDTU settings, updating min/max resource thresholds, altering pool size, adjusting auto-scale configurations, and adding or removing databases from the pool. Any attacker who compromises a privileged identity—such as SQL Server Contributor, Owner, Contributor, or a service principal with administrative permissions—can manipulate these configurations, potentially disrupting mission-critical workloads or enabling stealthy lateral movement across databases. Azure Activity Logs capture each of these control-plane operations, recording precisely what was changed, by whom, when, and through which API call.

The granularity of the data recorded in Activity Logs is vital for security teams. Each entry contains metadata including the identity performing the action, whether it was a human administrator, a compromised service principal, or an automation process; the timestamp; the client IP address; the subscription and resource group where the pool resides; the resource ID; and the exact ARM operation invoked. For Elastic Pools, this includes operations such as Microsoft.Sql/servers/elasticPools/write, elasticPools/update, elasticPools/databases/write, and other related configuration modifications. SOC teams can use this telemetry to detect unauthorized changes that deviate from normal operational patterns, approved maintenance windows, or standard automated behavior.

Elastic Pool configuration changes can be highly destructive when executed maliciously. Attackers who modify resource thresholds can cause databases to become starved of compute, leading to performance degradation that resembles normal workload spikes but is intentionally engineered to disrupt operations. An attacker might reduce the pool’s vCore capacity or lower the DTU limits to bottleneck business-critical applications. They might raise the minimum per-database resource allocation to exhaust the pool’s shared capacity, potentially impacting all databases simultaneously.

Alternatively, attackers may increase pool resources to create financial harm through sudden cost inflation. Elastic Pools are billed based on allocated compute; unauthorized resource scaling can drive up cloud costs significantly, creating a financial attack against the organization. Azure Activity Logs capture every scaling operation and expose anomalous adjustments that do not align with approved cost governance policies.

Elastic Pool membership changes also pose a significant risk. An attacker could add unauthorized databases to a pool to obscure suspicious activity within a shared resource environment or remove legitimate databases to isolate them from normal operational monitoring. They may manipulate the placement of sensitive databases to interfere with governance, cause performance bottlenecks, or bypass operational safeguards. Azure Activity Logs record every add or remove operation applied to the Elastic Pool, enabling SOC analysts to investigate membership anomalies and correlate them with suspicious identities or compromised automation accounts.

Azure SQL Auditing Logs provide detailed visibility into SQL data-plane activity such as T-SQL queries, login attempts, schema changes, and data modifications. While essential for detecting SQL-level threats such as injection, unauthorized queries, or privilege escalation inside the database engine, SQL Auditing Logs do not record control-plane configuration changes made via ARM. They cannot detect adjustments to Elastic Pool settings, performance policies, resource thresholds, or membership modifications. Only Azure Activity Logs provide control-plane and governance visibility.

DeviceNetworkEvents, generated by Defender for Endpoint, capture network connections from machines but offer no insight into Azure SQL resource modifications. Even if a compromised endpoint is used to alter an Elastic Pool, DeviceNetworkEvents would only show outbound API calls, not the content of those calls or the resource updates performed.

Azure AD Audit Logs track directory-level events, such as user creation, application registration, role assignment, and group modifications. Although they are valuable for detecting identity compromise, they cannot expose modifications to Azure SQL resources or Elastic Pool configurations. Attackers may authenticate successfully using stolen credentials, but only Azure Activity Logs reveal which database resource configurations they changed afterward.

Because Elastic Pool governance plays a central role in SQL performance, operational stability, and cost security, changes to these configurations are high-impact and must be monitored continuously. Ingesting Azure Activity Logs into Microsoft Sentinel enables SOC teams to build analytics rules that detect anomalies such as:

Unexpected increases or decreases in Elastic Pool compute capacity.
• Unauthorized updates to pool settings made outside maintenance windows.
• Sudden addition or removal of databases from the pool.
• Attempts to change vCore or DTU limits to create financial damage or performance sabotage.
• Configuration changes performed by identities that do not normally interact with SQL resources.
• Modifications originating from unknown or foreign IP ranges.
• Manipulation of auto-scale settings to bypass operational guardrails.
• Repeated scaling operations indicative of brute-force privilege abuse or misconfiguration attacks.

Sentinel can correlate these Activity Log events with other signals, such as suspicious Azure AD sign-ins, anomalous Key Vault activity, Storage Account misuse, or unusual VM behavior, allowing analysts to uncover multi-stage attacks that target database governance. For example, an attacker may compromise an identity, modify an Elastic Pool’s performance settings, exfiltrate data using SQL queries, and then restore configurations to hide their tracks. Activity Logs provide the forensic evidence required to trace such behavior.

Activity Logs also support compliance and post-incident forensics. Organizations must often demonstrate that changes to database resources follow proper governance procedures. Azure Activity Logs provide immutable records of who altered Elastic Pool configurations and when. During an incident investigation, these logs serve as foundational evidence for determining the timing, intent, and scope of malicious or unauthorized changes.

Elastic Pools play a pivotal role in scaling database workloads reliably, efficiently, and securely. Any modification to their configuration can have cascading effects across multiple databases, impacting critical applications, financial systems, or operational analytics pipelines. Azure Activity Logs ensure that every administrative action involving Elastic Pools is captured with the precision required for effective monitoring, detection, investigation, and governance enforcement.

Because they offer authoritative, complete, and tamper-resistant visibility into all control-plane actions performed against Azure SQL Elastic Pools, Azure Activity Logs are the correct and essential source for detecting suspicious modifications and ensuring the security and stability of SQL resources.

Question 135

Your SOC wants to detect suspicious activity within Azure Cognitive Services, such as unauthorized API key regeneration, anomalous model usage, or unexpected calls to vision, speech, or language services from new identities. Which log source should be used?

A) Azure Cognitive Services Diagnostic Logs

B) Azure AD Sign-in Logs

C) DeviceEvents

D) NSG Flow Logs

Answer: A) Azure Cognitive Services Diagnostic Logs

Explanation

Azure Cognitive Services Diagnostic Logs are the authoritative and indispensable source for monitoring suspicious, unauthorized, or anomalous behavior involving Azure Cognitive Services resources. Cognitive Services enable organizations to integrate advanced AI capabilities—such as text analytics, image recognition, speech processing, sentiment analysis, translation, anomaly detection, and decision intelligence—into their applications. Because these services often process sensitive, proprietary, or regulated data, they represent a high-value target for attackers seeking to exploit AI workloads, access processed content, steal API keys, or manipulate service configurations. Azure Cognitive Services Diagnostic Logs provide the comprehensive visibility required to detect these threats, making them the correct and essential log source for security monitoring.

Cognitive Services rely heavily on API-based interactions. Every operation—whether it is analyzing text, detecting faces, transcribing speech, generating predictions, or evaluating models—is performed through authenticated API requests. Attackers who gain access to a Cognitive Services key, compromise a privileged identity, or exploit misconfigured access controls can make unauthorized API calls at scale. These calls can lead to data exposure, service abuse, or cost spikes resulting from high-volume usage. Diagnostic Logs capture API request details including request origin IP address, operation names, endpoints called, user or key identity, client application, response codes, request metadata, and authentication methods used. This granular telemetry enables SOC analysts to detect when an attacker is abusing cognitive resources for malicious purposes.

A particularly important scenario involves the misuse or theft of API keys. Cognitive Services use either key-based authentication or Azure AD-based tokens, and key-based authentication remains common due to its simplicity. However, keys can be easily leaked in application code repositories, logging pipelines, configuration files, unsecured storage locations, or compromised development environments. If attackers obtain a Cognitive Services key, they can use it to run arbitrary operations, extract insights, or abuse expensive services such as Face API, Language Understanding, or Speech-to-Text engines. Diagnostic Logs capture all request-level metadata associated with key-based access, allowing SOC teams to identify anomalous patterns such as high-frequency requests, access from new geographies, or operations invoked by identities that do not normally use the service.

Another high-risk scenario involves configuration tampering. Attackers with elevated permissions may attempt to regenerate API keys for persistence, disable security settings, alter endpoint configurations, or modify quotas. Key regeneration is especially critical because it allows an attacker to invalidate existing keys used by legitimate applications and replace them with ones under their control. Azure Cognitive Services Diagnostic Logs record key regeneration events, revealing both the identity performing the action and the timing. This gives SOC analysts immediate insight into control-plane activity that could indicate compromise.

Azure AD Sign-in Logs, while essential for identity monitoring and detecting account compromise, cannot observe Cognitive Services operations. They track authentication events, but they do not show whether an authenticated identity used a Cognitive Services resource improperly. Even if an attacker successfully signs in using a stolen credential, Sign-in Logs do not reveal which Cognitive Services endpoints were accessed or what actions were performed. Only Diagnostic Logs expose request-level details that map directly to Cognitive Services workloads.

DeviceEvents, which include DeviceProcessEvents and DeviceSecurityEvents, provide visibility into endpoint behavior such as process execution, malware detections, exploit attempts, registry modifications, or command-line usage. These logs are invaluable for detecting local compromise but offer no visibility into cloud-native API interactions. Cognitive Services operations occur entirely at the cloud service layer, making endpoint telemetry ineffective for monitoring service-level misuse.

NSG Flow Logs capture network traffic flows within Azure VNets, documenting source IPs, destination IPs, ports, and connection states. While useful for detecting anomalous traffic or DDoS-like bursts, Flow Logs cannot interpret application-layer operations, including Cognitive Services requests. They cannot determine whether an inbound or outbound connection corresponds to a Text Analytics sentiment analysis call, a Face API identification request, or a Speech-to-Text transcription operation. Without semantic context, Flow Logs cannot identify unauthorized AI operations or key misuse.

Model evaluation and training operations within Cognitive Services are also sensitive. Attackers may submit malicious inputs intended to poison machine learning models, extract model decision boundaries, or degrade accuracy through adversarial examples. Diagnostic Logs capture these evaluation calls, allowing SOC teams to detect anomalies such as unusual payload structures or repeated attempts to exploit model weaknesses.

Cognitive Services often process data that is highly regulated or proprietary. For example, text analytics may analyze confidential emails, contracts, or documents; OCR services may extract content from sensitive scans; Speech-to-Text may process customer calls; and Face API may handle biometric data. Unauthorized access to these services can lead to compliance violations, data breaches, or misuse of personally identifiable information. Diagnostic Logs serve as the accountability mechanism showing exactly who accessed what service and under what context.

Furthermore, these logs play a critical role in cost governance. Cognitive Services operations can accumulate costs rapidly, especially high-compute tasks like document OCR or speech processing. Attackers exploiting stolen keys may generate massive consumption spikes. Diagnostic Logs allow teams to catch early indicators of usage anomalies before they result in significant financial damage.

For regulated industries, these logs offer compliance and audit-readiness benefits. They provide verifiable traces of data access and model interactions, supporting audit requirements around transparency, accountability, and explainability in AI workflows.

Because Cognitive Services process sensitive data and expose a broad attack surface through powerful API capabilities, organizations must ensure robust monitoring. Azure Cognitive Services Diagnostic Logs provide the deep, actionable telemetry needed to detect unauthorized access, API abuse, configuration tampering, cost-based attacks, and identity misuse. For these reasons, they are the correct and essential log source for securing Azure Cognitive Services workloads.