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

Question 61

Your SOC team needs to detect when an attacker uses Azure Automation Runbooks to execute malicious scripts or modify cloud resources stealthily. You want visibility into every runbook execution, job output, and script invocation. Which log source must be ingested into Microsoft Sentinel?

A) Azure Automation Job Logs

B) DeviceProcessEvents

C) Azure AD Sign-in Logs

D) Azure Firewall Logs

Answer: A) Azure Automation Job Logs

Explanation

Azure Automation Job Logs are the essential source of telemetry for monitoring activity related to Automation Runbooks. Attackers who gain access to Azure environments often seek to maintain persistence or execute malicious operations using automation features like Runbooks. These scripts can be used to deploy malware, exfiltrate data, alter security controls, or modify cloud configurations without triggering obvious endpoint or identity alerts. Azure Automation Job Logs record every runbook execution, including the identity that initiated it, the exact script executed, output logs, failure reasons, parameters used, and timestamps. This level of detail is critical because Runbooks can be triggered manually, scheduled, or even invoked by webhooks — all of which present opportunities for abuse. DeviceProcessEvents focuses on endpoint commands and cannot capture cloud-run script execution. Azure AD Sign-in Logs help identify identity authentication activity but don’t show script content or automation job results. Azure Firewall Logs track network traffic and cannot log Azure Automation behavior. Job logs allow SOC analysts to detect anomalies such as unexpected runbook executions outside business hours, modifications to automation accounts, or scripts executed by identities that normally do not manage automation. They help uncover persistence mechanisms attackers may create by adding scheduled tasks within Automation Accounts. By forwarding these logs to Sentinel, security teams can build analytics rules to detect suspicious patterns like frequent webhook-triggered runs, sudden creation of new Runbooks, or privilege escalation attempts inside scripts. For this reason, Azure Automation Job Logs are the correct and necessary source for monitoring runbook abuse.

Question 62

You need to detect unauthorized or anomalous changes to Kubernetes clusters running in Azure Kubernetes Service (AKS), such as modifying deployments, adjusting RBAC permissions, or altering network policies. Which log source should be connected to Sentinel?

A) Azure Kubernetes Service Diagnostic Logs

B) Azure Activity Logs

C) DeviceSecurityEvents

D) DeviceNetworkEvents

Answer: A) Azure Kubernetes Service Diagnostic Logs

Explanation

Azure Kubernetes Service (AKS) Diagnostic Logs are the primary source for monitoring Kubernetes cluster operations and are essential for detecting unauthorized or suspicious modifications to workloads, roles, or configurations. AKS clusters consist of multiple layers — infrastructure, Kubernetes API, nodes, pods, and networking — and attackers frequently attempt to compromise these components to escalate privileges, deploy malicious containers, or disable security controls. Diagnostic Logs capture Kubernetes API server activity such as creation or alteration of deployments, scaling events, updates to ConfigMaps, changes in RBAC policies, and modifications to network policies. These logs are critical because Kubernetes relies heavily on API calls for nearly all administrative actions, and unauthorized API access often signals a breach. Azure Activity Logs track Azure resource-level actions but do not capture Kubernetes API operations. DeviceSecurityEvents relate to Windows security events and cannot observe container activity. DeviceNetworkEvents capture endpoint-level network telemetry but do not monitor cluster management operations. AKS Diagnostic Logs include metadata such as the identity invoking the request, the Kubernetes resource affected, request parameters, IP origins, and timestamps — providing SOC teams with the needed visibility to detect threats like container escapes, privilege escalation attempts, or malicious workload deployments. Sentinel can correlate these logs with identity and network signals to detect broader attack patterns. Thus, AKS Diagnostic Logs are the correct source for cluster-level threat monitoring.

Question 63

You want to detect suspicious network traffic in Azure Virtual Networks, such as unauthorized communication between subnets, connections to malicious IP addresses, or unexpected protocol usage. Which Azure native solution should you integrate with Sentinel to gather this network flow data?

A) NSG Flow Logs

B) Azure AD Audit Logs

C) DeviceFileEvents

D) Key Vault Diagnostic Logs

Answer: A) NSG Flow Logs

Explanation

Network Security Group (NSG) Flow Logs provide detailed Layer 4 network flow information for Azure Virtual Networks, making them essential for detecting suspicious or unauthorized traffic patterns. These logs show inbound and outbound traffic allowed or denied by NSG rules, including source and destination IP addresses, ports, protocols, and traffic direction. Attackers often attempt lateral movement by scanning internal subnets, accessing sensitive services, or communicating with command-and-control servers from compromised cloud workloads. NSG Flow Logs allow SOC teams to detect such patterns by identifying unusual traffic flows, unexpected inter-subnet communication, and connections to known malicious IP ranges. Azure AD Audit Logs record directory changes but offer no network visibility. DeviceFileEvents capture local file system operations, not cloud network traffic. Key Vault Diagnostic Logs monitor secret access, not network communications. NSG Flow Logs are processed via Azure Network Watcher, making them available for ingestion into Sentinel as analyzable network flow data. With Sentinel analytics rules, organizations can detect behaviors like port scanning, suspicious east-west traffic, or external communication anomalies. For this reason, NSG Flow Logs are the correct choice.

Question 64

Your SOC team wants to detect when an attacker attempts to exploit Azure Functions by injecting malicious code, triggering unauthorized executions, or pushing unauthorized function updates. Which log source provides full visibility into function execution activity and deployment changes?

A) Azure Functions Platform Logs

B) DeviceProcessEvents

C) Azure Firewall Logs

D) DeviceLogonEvents

Answer: A) Azure Functions Platform Logs

Explanation

Azure Functions Platform Logs provide deep operational visibility into function execution, invocations, failures, and deployment changes. When attackers target Azure serverless infrastructure, they may attempt to upload malicious scripts, trigger unauthorized executions, inject harmful payloads through HTTP triggers, or modify environment configurations. Platform Logs record function trigger events, input/output bindings, execution duration, runtime errors, deployment actions, and changes to function code or configurations. These signals are vital for detecting cloud-native threats. DeviceProcessEvents track endpoint processes but offer no insight into serverless function activity. Azure Firewall Logs capture network traffic but cannot monitor function invocation or code execution. DeviceLogonEvents track authentication events on endpoints but do not relate to cloud functions. Attackers may create malicious function apps as persistence mechanisms or abuse existing ones to move laterally inside Azure. Platform Logs allow SOC analysts to detect anomalies such as repeated unauthorized triggers, unusual deployment changes, unexpected execution patterns, or abnormal scaling activity. When ingested into Sentinel, they support analytics rules for detecting malicious serverless activity. Thus, Azure Functions Platform Logs are the correct answer.

Question 65

A compromised identity is attempting to retrieve secrets from Azure Key Vault using programmatic access through automation scripts. You want to detect unusual secret retrieval patterns, including rapid access attempts, use of unfamiliar service principals, and access from suspicious IPs. Which log source provides this information?

A) Key Vault Access Logs

B) Azure AD Sign-in Logs

C) DeviceNetworkEvents

D) DeviceFileEvents

Answer: A) Key Vault Access Logs

Explanation

Key Vault Access Logs are the authoritative source for monitoring all secret, key, and certificate retrieval attempts from Azure Key Vault. These logs capture every operation performed through the Key Vault API, including GetSecret, ListSecrets, GetKey, Decrypt, Sign, and more. Attackers often target Key Vault after compromising service principals or user accounts because it stores highly sensitive secrets that can grant access to databases, applications, storage accounts, and privileged resources. Key Vault Access Logs provide granular details such as the identity (user or service principal) making the request, the requestor’s IP address, timestamp, operation performed, and whether the access was allowed or denied. Azure AD Sign-in Logs provide authentication activity but not per-secret access details. DeviceNetworkEvents track network connections but cannot reveal what Key Vault operations took place. DeviceFileEvents record file system modifications on endpoints, not cloud secret retrievals. By ingesting Key Vault Access Logs into Sentinel, SOC teams can build analytics to detect high-frequency secret access, unusual identities retrieving secrets, attempts originating from foreign IPs, or programmatic access executed outside normal patterns. For these reasons, Key Vault Access Logs are the correct detection source.

Question 66

Your SOC team needs to detect unauthorized privilege escalations inside Azure Kubernetes Service (AKS), such as when an attacker grants themselves cluster-admin privileges or modifies Kubernetes RoleBindings to escalate access. You must ingest logs that track Kubernetes API server activities. Which log source should be integrated with Sentinel?

A) AKS Diagnostic Logs

B) DeviceSecurityEvents

C) Azure AD Sign-in Logs

D) Azure Firewall Threat Intelligence Logs

Answer: A) AKS Diagnostic Logs

Explanation

AKS Diagnostic Logs provide the most comprehensive visibility into Kubernetes API server activity, which is essential for detecting privilege escalation attempts within AKS clusters. Kubernetes relies heavily on API calls to manage nearly every aspect of the cluster, including RoleBindings, ClusterRoleBindings, deployments, secrets, pods, and service accounts. When attackers compromise a pod, exploit a misconfigured workload, or steal Kubernetes credentials, they commonly attempt to modify RBAC policies to escalate privileges. AKS Diagnostic Logs capture every such action, including who initiated the request, which API method was invoked, what resource was modified, and whether the action succeeded. This telemetry is crucial for SOC teams because privilege escalation in Kubernetes can lead to severe impacts such as full cluster control, access to sensitive secrets, lateral movement to other services, or the deployment of malicious containers. DeviceSecurityEvents provide Windows endpoint security logs and cannot observe Kubernetes activity. Azure AD Sign-in Logs capture cloud identity authentication but not Kubernetes API calls. Azure Firewall Threat Intelligence logs show malicious IP traffic but do not record cluster administrative operations. AKS Diagnostic Logs include details about API verbs like “create,” “patch,” “update,” and “delete,” enabling detection of dangerous actions such as unauthorized creation of cluster-admin roles or escalation of service account permissions. In Sentinel, these logs can power analytics rules that alert when unusual identities modify RBAC roles or when API calls occur outside expected patterns, such as off-hours or from unexpected source IPs. Because Kubernetes API activity is the source of truth for administrative changes within AKS, AKS Diagnostic Logs are the correct choice for detecting privilege escalations.

Question 67

Your organization wants to ensure that only secure, compliant devices can access Microsoft 365 applications. Devices with high-risk scores, malware infections, or missing security configurations should be blocked automatically. Which Microsoft integration provides this dynamic access control?

A) Conditional Access + Defender for Endpoint

B) Azure Firewall Policies

C) Microsoft Sentinel UEBA

D) Azure Monitor Alerts

Answer: A) Conditional Access + Defender for Endpoint

Explanation

The integration of Azure AD Conditional Access with Microsoft Defender for Endpoint provides dynamic, risk-based device access control that aligns perfectly with Zero Trust principles. Defender for Endpoint continuously evaluates device posture, including security configurations, OS vulnerabilities, malware presence, exploit attempts, and behavioral anomalies. It assigns each device a risk level (low, medium, high). Conditional Access policies can use this risk level as a condition to determine whether a device is allowed to access Microsoft 365 applications such as Outlook, Teams, SharePoint, and OneDrive. This integration allows organizations to block risky or compromised devices automatically, enforce MFA when device risk increases, or grant access only to fully compliant devices. Azure Firewall Policies control network traffic but cannot assess device security posture. Microsoft Sentinel UEBA helps detect behavioral anomalies but does not apply real-time access restrictions. Azure Monitor Alerts notify teams of events but cannot enforce access control policies. With Conditional Access + Defender for Endpoint, organizations gain continuous evaluation of device trustworthiness. For example, if Defender detects malware on a device and marks it as high-risk, Conditional Access can immediately block the device from accessing any critical applications—regardless of whether the attacker has valid credentials. This prevents credential theft–based attacks and lateral movement from infected devices. The seamless integration ensures that only secure devices interact with corporate cloud services, making it the correct solution for dynamic device-based access control.

Question 68

A threat actor is attempting to delete Azure Storage containers to disrupt business operations. You need visibility into operations such as DeleteContainer, DeleteBlob, and modifications to Storage access policies. Which log source should be ingested into Sentinel?

A) Storage Account Diagnostic Logs

B) Azure AD Audit Logs

C) DeviceFileEvents

D) DeviceNetworkEvents

Answer: A) Storage Account Diagnostic Logs

Explanation

Storage Account Diagnostic Logs provide detailed telemetry for all operations performed against Azure Storage containers, including blob deletions, container removals, modifications to access control policies, and permission changes. Attackers who gain access to Azure Storage resources may attempt to delete data, remove access, modify Shared Access Signatures (SAS), or exfiltrate sensitive information. Because Azure Storage is widely used for backups, application data, logs, and file distribution, unauthorized deletions can cause major operational or security incidents. Storage Diagnostic Logs capture vital details including the action performed (such as DeleteContainer, DeleteBlob, PutBlob), the identity making the request, timestamps, IP address, authentication type, and response code. Azure AD Audit Logs track directory-level changes, not Storage account operations. DeviceFileEvents show local file system modifications, not cloud-based storage actions. DeviceNetworkEvents capture network communications but cannot identify individual blob operations. By ingesting Storage diagnostics into Sentinel, SOC teams can detect patterns such as repeated deletion attempts, unusual access from untrusted locations, sudden use of SAS tokens, or large volumes of destructive operations. These logs can be correlated with identity signals, network anomalies, or endpoint behaviors to identify deeper attacks. Because Storage Account Diagnostic Logs provide the only complete visibility into Storage operations, they are the correct answer.

Question 69

Your SOC team needs to detect suspicious Azure AD role assignments performed through automated scripts or PowerShell modules such as MSOnline or AzureAD. You must monitor directory role changes, privilege escalations, and administrative activity. Which log source provides this visibility?

A) Azure AD Audit Logs

B) Azure Activity Logs

C) Microsoft Defender for Endpoint

D) DeviceProcessEvents

Answer: A) Azure AD Audit Logs

Explanation

Azure AD Audit Logs capture all directory-level changes including user updates, group membership changes, application registration modifications, and most importantly, role assignments. Attackers often use PowerShell modules such as MSOnline or AzureAD to escalate privileges by adding accounts to high-level roles like Global Administrator, Exchange Administrator, or Privileged Role Administrator. These role modifications are immediately recorded in Azure AD Audit Logs. Azure Activity Logs track Azure resource changes but not directory role assignments. Defender for Endpoint provides endpoint detection and does not log cloud directory changes. DeviceProcessEvents can detect script execution on endpoints but cannot identify the resulting cloud privilege changes. Azure AD Audit Logs include information such as the initiator of the change, target identity, new role assigned, time of operation, IP address, device information, and whether the action succeeded or failed. These logs allow SOC analysts to detect unauthorized privilege escalations, suspicious administrative actions, or anomalous automation scripts invoking identity changes. Therefore, Azure AD Audit Logs are the correct source for monitoring Azure AD role assignment activities.

Question 70

You want to detect when attackers attempt to exploit Azure Virtual Machines by modifying VM extensions, injecting malicious scripts, or running unauthorized startup tasks. You need to track extension updates, guest agent operations, and script executions triggered from the Azure control plane. Which log source should be connected to Sentinel?

A) Azure Activity Logs

B) DeviceSecurityEvents

C) Azure AD Sign-in Logs

D) DeviceFileEvents

Answer: A) Azure Activity Logs

Explanation

Azure Activity Logs provide visibility into all operations executed through Azure Resource Manager (ARM), including VM extension installations, updates, removals, and modifications. Attackers who gain access to Azure often attempt to modify VM extensions because they provide a privileged mechanism to execute scripts on virtual machines, deploy configuration changes, or introduce malicious payloads. Extensions such as Custom Script Extension, Azure Diagnostics, or Desired State Configuration can all be abused for lateral movement, persistence, or data exfiltration. Activity Logs record actions such as updating VM agents, modifying extensions, triggering scripts, and altering VM configurations. DeviceSecurityEvents only track endpoint-level Windows security events and cannot detect Azure-triggered operations. Azure AD Sign-in Logs track authentication but do not capture VM extension actions. DeviceFileEvents log file modifications on endpoints, not Azure control plane actions. Azure Activity Logs capture critical metadata including the identity initiating the action, timestamp, subscription, resource group, VM affected, IP address of the request, and operation result. This makes them essential for detecting suspicious VM extension operations. SOC teams can create Sentinel rules to alert on unusual extension modifications, script executions at odd hours, or actions initiated by identities that normally do not manage VMs. Because of this deep control-plane visibility, Azure Activity Logs are the correct answer.

Question 71

A security analyst needs to detect when Azure Service Principals gain elevated permissions through OAuth consent grants. This includes detecting when new high-privileged Graph API permissions are suddenly authorized for an app. Which log source must you ingest into Sentinel?

A) Azure AD Audit Logs

B) Azure Activity Logs

C) DeviceNetworkEvents

D) Microsoft Defender for Endpoint Alerts

Answer: A) Azure AD Audit Logs

Explanation

Azure AD Audit Logs are the correct data source for identifying privilege escalation attacks involving OAuth applications and service principals. Attackers frequently exploit OAuth consent to obtain long-lasting access to Microsoft 365 and Azure resources. By authorizing dangerous permissions such as Mail.ReadWrite, Directory.ReadWrite.All, or Files.Read.All, an attacker can gain persistent, elevated access without needing passwords or MFA. Azure AD Audit Logs capture detailed records of app permission grants, including the identity granting the permissions, the service principal receiving them, timestamps, IP address, permission scope, and whether the permission was delegated or application-level. This visibility is essential because OAuth attacks bypass traditional authentication security controls, allowing attackers to impersonate users, download sensitive data, or modify directory objects. Azure Activity Logs track resource-based events but do not record OAuth permission changes. DeviceNetworkEvents only show network communications and cannot monitor cloud directory permissions. Defender for Endpoint Alerts provide endpoint security detections but cannot observe cloud-wide OAuth modifications. Audit Logs allow SOC teams to detect abnormal patterns such as sudden permission escalation for previously low-risk apps, app consent performed by non-admin users, or new Graph API permissions associated with known malware campaigns. Monitoring OAuth permissions is crucial because once an attacker gains them, they can operate silently using API calls with no traditional login activity. Therefore, Azure AD Audit Logs are the essential source for detecting suspicious OAuth consent grants.

Question 72

Your SOC team wants to detect when attackers perform brute-force password attacks against Azure AD accounts using legacy protocols like IMAP, POP3, and SMTP AUTH. These attacks often bypass MFA. Which log source should you ingest to detect these attempts?

A) Azure AD Sign-in Logs

B) DeviceLogonEvents

C) NSG Flow Logs

D) DeviceProcessEvents

Answer: A) Azure AD Sign-in Logs

Explanation

Azure AD Sign-in Logs are the authoritative and indispensable source for detecting brute-force and password-spray attacks against Azure AD accounts, especially those conducted through legacy authentication protocols. Identity-based attacks remain one of the most common methods threat actors use to compromise cloud environments, and legacy protocols such as IMAP, POP, and SMTP AUTH represent some of the weakest points of entry. These older protocols do not support modern authentication, token-based access, or multi-factor authentication enforcement, which makes them uniquely attractive to attackers attempting password spraying or brute-force attacks. Because they accept simple username and password authentication without second-factor challenges, attackers frequently target these endpoints in hopes that users are still enabled for legacy access.

Azure AD Sign-in Logs capture every authentication attempt made against Azure AD, including those made using legacy authentication. This includes both successful and failed attempts, giving SOC teams complete visibility into how accounts are being targeted, which protocols are used, and which credential pairs are being tested. The logs contain critical metadata such as the authentication protocol, client application, user agent string, resource being accessed, IP address of the requesting client, geographic location, device information, conditional access evaluation results, correlation IDs, and failure reasons. These fields allow threat hunters to identify brute-force patterns like rapid-fire failures, repeated attempts from suspicious IP addresses, password spraying across multiple accounts, or unusual login patterns originating from legacy clients not normally used by the organization.

Legacy authentication brute-force campaigns often occur quietly, bypassing the protections provided by modern authentication and MFA. Because legacy protocols rely exclusively on passwords, they are a preferred entry point for attackers attempting to compromise accounts with weak or reused credentials. Azure AD Sign-in Logs play a decisive role in exposing these attempts. For example, the logs can reveal whether attackers are repeatedly using IMAP4 to target multiple accounts with low-frequency password spraying—a technique designed to evade lockout thresholds and detection systems. They can also reveal whether sudden spikes in SMTP AUTH failures correlate with suspicious authentication attempts from known malicious IP clusters or Tor exit nodes.

In contrast, DeviceLogonEvents only track authentication events occurring on Windows endpoints joined to a Defender for Endpoint deployment. These events are useful for investigating on-premises login attempts or lateral movement within a corporate network, but they do not capture cloud-based authentication attempts against Azure AD. A brute-force attack coming from the internet directly into Azure AD would never appear in DeviceLogonEvents, because the authentication happens in the cloud service—not on an endpoint.

NSG Flow Logs provide visibility into network traffic patterns inside Azure virtual networks. They can show which IP addresses communicated with which ports and protocols, but they contain no identity-aware context. Flow logs cannot distinguish whether traffic is part of a brute-force login attempt, a normal API call, or a benign network probe. They also cannot detect whether the traffic represents an authentication attempt at all, because network flows lack semantic information about login operations. Even if an attacker tries to brute-force passwords against Azure AD endpoints, the NSG Flow Logs cannot correlate these attempts to a specific identity or authentication protocol.

DeviceProcessEvents capture endpoint process execution details such as command-line arguments, binary hashes, parent processes, and execution paths. While extremely valuable for malware detection, persistence hunting, and lateral movement analysis, DeviceProcessEvents cannot detect authentication events happening against Azure AD. Cloud authentication does not manifest as a local device process unless the attacker is using a script or tool on a managed endpoint. Even then, the process logs will only show that a process executed—not whether the authentication succeeded or failed. The authoritative authentication telemetry only exists within Azure AD Sign-in Logs.

Azure AD Sign-in Logs also provide unique insights into conditional access outcomes. For instance, if the organization has enforced policies to block legacy authentication, the logs will show failure reasons tied to conditional access. If legacy protocols unexpectedly succeed or begin passing through specific regions, this may signal configuration drift, misconfigured Conditional Access, or exploitation of a loophole. Additionally, risk-based details, such as unfamiliar sign-in properties or atypical connection patterns, help SOC analysts determine whether the brute-force campaign targets specific high-privilege accounts or uses anonymous cloud infrastructure to evade geolocation-based blocking.

One of the most powerful aspects of Sign-in Logs is their ability to highlight high-volume, low-frequency password sprays—one of the most common techniques used by advanced attackers. Password sprays avoid account lockouts by attempting only a few passwords per account. Azure AD Sign-in Logs reveal these patterns because they track each attempt separately and provide indicators such as client application and protocol. Repeated IMAP7 or POP3 failures distributed across multiple accounts often indicate a coordinated password-spray attack.

In Microsoft Sentinel, ingestion of Azure AD Sign-in Logs enables the creation of analytics rules that detect early-stage identity attacks. Analysts can construct detection logic for:

Password spraying using IMAP, POP, or SMTP AUTH
• High-volume authentication failures from a single IP address
• Repeated attempts targeting multiple accounts during off-hours
• Legacy authentication usage in organizations that have migrated to modern auth
• Authentication attempts from known malicious IP ranges or TOR networks
• Attempts bypassing MFA through unsupported protocols

Sentinel can also correlate identity events with other signals such as Azure AD Audit Logs, Azure Activity Logs, Defender for Cloud alerts, and endpoint detections to detect multi-stage attack campaigns. For example, an attacker may begin with a password spray against legacy protocols, gain access to a weak account, escalate privileges using Azure AD role assignments, and then deploy malicious activity via ARM. Sign-in Logs provide the first critical insights in this multi-step attack sequence.

Legacy authentication remains one of the biggest security gaps for many organizations. Attackers capitalize on outdated protocols precisely because they bypass MFA and conditional access, making them a stealthy yet effective attack vector. Without Azure AD Sign-in Logs, these attempts would go unnoticed, enabling attackers to compromise accounts silently and gain initial footholds in the environment.

For detecting brute-force attacks, password spraying, legacy protocol misuse, and suspicious identity behavior, Azure AD Sign-in Logs are unquestionably the correct and authoritative log source.

Question 73

Your organization wants to detect suspicious use of Azure Managed Identities, including unusual token requests or identities accessing resources they typically do not interact with. Which log source should be ingested to detect these anomalies?

A) Azure AD Sign-in Logs

B) Azure Firewall Threat Intelligence Logs

C) DeviceSecurityEvents

D) DeviceFileEvents

Answer: A) Azure AD Sign-in Logs

Explanation

Azure AD Sign-in Logs are the authoritative source for monitoring authentication behavior across all Azure identities, including Managed Identities. Managed Identities are widely used by virtual machines, function apps, automation accounts, and containerized workloads to authenticate to Azure resources without storing secrets, keys, or certificates. While this removes the risk of credential leakage through mismanagement, it does not eliminate the risk of compromise. If an attacker gains access to a workload or extracts cached tokens from memory, they can silently impersonate a Managed Identity and move laterally through the environment. Azure AD Sign-in Logs provide the visibility required to detect such misuse.

These logs record every authentication event involving Managed Identities. The telemetry includes detailed information such as the client ID of the identity, the resource or API being accessed, token issuance time, authentication protocol, IP address of the calling workload, user agent, request origin, and outcome of Conditional Access evaluation. Because Managed Identities authenticate through Azure AD just like user accounts and service principals, their authentication footprints appear consistently in Sign-in Logs. This level of detail is essential for identifying deviations from expected access patterns.

One of the most powerful detection use cases for Sign-in Logs involves behavioral anomalies. A Managed Identity may normally authenticate only to a single Key Vault to retrieve secrets required for a VM’s application runtime. If that identity suddenly attempts to access unrelated storage accounts, service buses, or cognitive services APIs, this is a strong indicator of compromise. Similarly, if authentication attempts begin originating from an unfamiliar region or from an unexpected Azure service, the logs will surface these anomalies immediately. SOC teams can then pivot on this data to investigate lateral movement, token theft, or privilege escalation attempts.

DeviceSecurityEvents and DeviceFileEvents provide valuable endpoint-level telemetry, but they operate exclusively at the operating system level. They cannot observe cloud authentication flows or determine whether an Azure identity was used to access sensitive resources. Even if an attacker compromises a VM, endpoint events alone cannot reveal which Managed Identity tokens were abused or which cloud resources were targeted.

Azure Firewall Logs capture network flows and packet-level insights but lack identity context. Firewalls cannot inspect OAuth tokens or correlate outbound API calls with specific Managed Identities. They may show an HTTPS request to a storage endpoint, but they cannot determine which identity authenticated, what token was issued, or what role assignments were used. As a result, firewall logs cannot replace Sign-in Logs for identity-based threat detection.

By ingesting Azure AD Sign-in Logs into Microsoft Sentinel, organizations gain the ability to create analytics rules that detect unauthorized Managed Identity usage, unexpected API calls, excessive token requests, or access to high-value resources outside approved workflows. Sentinel can correlate these identity anomalies with Azure Activity Logs, network telemetry, or Defender for Cloud alerts, creating a complete picture of multi-stage attacks where workloads are compromised and their identities abused.

Managed Identities are powerful because they integrate seamlessly into automation and cloud-native workflows. However, their privilege levels often exceed those of traditional user accounts, making them high-value targets for attackers. Azure AD Sign-in Logs provide the detailed authentication insights necessary to detect misuse early, making them the correct and essential choice for monitoring Managed Identity activity.

Question 74

A threat actor is trying to compromise Azure SQL Databases by performing SQL injection attempts, enumerating tables, or issuing high-risk queries. You want to detect these database-level threats. Which native Azure feature should be integrated with Sentinel?

A) Advanced Threat Protection for Azure SQL

B) DeviceNetworkEvents

C) Azure AD Audit Logs

D) Microsoft Defender for Endpoint

Answer: A) Advanced Threat Protection for Azure SQL

Explanation

Advanced Threat Protection (ATP) for Azure SQL—now part of Microsoft Defender for SQL—provides dedicated security monitoring for threats that specifically target SQL databases in the cloud. Unlike general-purpose security solutions, ATP is built to understand SQL workloads, interpret query behavior, analyze database audit logs, and identify malicious or anomalous patterns that would otherwise go undetected. Databases often store the most sensitive information in an organization, making them frequent targets for attackers seeking to steal data, escalate privileges, or disrupt business operations. ATP helps protect against these risks by offering continuous behavioral analysis and threat intelligence–driven detection.

ATP monitors every interaction with the database, including login attempts, SQL statements, access patterns, administrative actions, schema modifications, and data manipulation queries. By analyzing these signals, it detects suspicious activities such as SQL injection attempts, unusual query execution sequences, privilege misuse, lateral movement into the database, or large-scale data exfiltration patterns. For example, if an attacker exploits a vulnerable web application and injects malicious SQL commands, ATP can identify the anomaly by examining query structures, comparing them to normal application behavior, and recognizing exploitation techniques such as tautologies, error-based injections, or union-based extraction commands.

Additionally, ATP evaluates login behavior to detect authentication anomalies. Access from unusual geographic locations, sudden logins from previously unseen IP ranges, and attempts to authenticate using disabled accounts or expired credentials are indicators of potential compromise. If an attacker gains access to valid database credentials through phishing or exploitation of a misconfigured service principal, ATP can detect suspicious follow-up queries, privilege escalations, or attempts to read large volumes of sensitive data in a short period.

DeviceNetworkEvents, by comparison, provides only high-level network telemetry from Defender for Endpoint. While useful for detecting suspicious outbound traffic or C2 communications, it cannot interpret SQL commands, analyze database-specific attack vectors, or detect injection attempts. Network logs lack the semantic understanding required to evaluate query behavior, making them unsuitable for database threat detection.

Azure AD Audit Logs capture directory events such as user creation, role changes, and application registrations. While these logs contribute valuable context for identity-related anomalies, they do not include database-level operations or SQL query details. A threat actor who compromises credentials may authenticate successfully and then run malicious database queries, none of which would appear in Azure AD Audit Logs.

Defender for Endpoint focuses on device-based attacks, endpoint processes, malware execution, and exploit detections across Windows, macOS, and Linux devices. It has no visibility into cloud database workloads. Even if a compromised machine initiates SQL attacks, Defender for Endpoint can only observe the endpoint behavior, not the SQL operations executed against Azure SQL.

ATP, on the other hand, generates high-fidelity, context-rich alerts that allow SOC teams to quickly understand the nature of the threat. Alerts include the exact SQL query executed, the table or schema targeted, the user or application identity involved, the client IP address, and correlations to known attack techniques. When these alerts are ingested into Microsoft Sentinel, analysts can correlate SQL abuse with identity compromise, suspicious network flows, or unusual application behavior, enabling a complete view of multi-stage attacks.

Because ATP is specifically designed to detect SQL injection, abnormal query patterns, unauthorized data access, and privilege escalation within Azure SQL environments, it is the correct and essential solution for database threat detection.

Question 75

Your SOC team wants to detect when an Azure virtual machine begins communicating with known malicious domains or IP addresses, especially command-and-control servers. You want Azure-native threat intelligence integrated directly into network analysis. Which service should you use?

A) Azure Firewall Threat Intelligence

B) DeviceFileEvents

C) Azure AD Sign-in Logs

D) Microsoft Defender for Endpoint

Answer: A) Azure Firewall Threat Intelligence

Explanation

Azure Firewall Threat Intelligence provides a powerful, built-in security capability designed to detect and block outbound connections from Azure virtual networks to known malicious IP addresses, suspicious domains, botnet infrastructure, ransomware command-and-control servers, and high-risk URLs. This feature leverages Microsoft’s global threat intelligence feeds, which aggregate signals from trillions of daily data points across Microsoft Defender, Azure infrastructure, Windows telemetry, partner ecosystems, and global threat research. As a result, Azure Firewall Threat Intelligence provides immediate, continuously updated protection without requiring organizations to manually maintain blocklists or threat indicators.

When enabled, Azure Firewall Threat Intelligence inspects outbound traffic generated by virtual machines, containers, application services, and other workloads running inside the VNet. If a workload attempts to communicate with a destination that Microsoft has classified as malicious or suspicious, the firewall can either block the request outright or simply alert the SOC depending on configuration. This makes it a critical defense against compromised virtual machines attempting to reach attacker-controlled domains, whether for exfiltrating data, downloading malware, registering with C2 servers, or participating in lateral movement operations.

DeviceFileEvents provides visibility only into local file system activity on Defender for Endpoint–protected machines. While valuable for detecting file modifications, malware writes, or data staging operations, it has no ability to observe outbound network flows from cloud VMs or container workloads. Network-level threats—such as C2 communications—occur outside the file system, making DeviceFileEvents insufficient for detecting these behaviors.

Azure AD Sign-in Logs are focused exclusively on identity authentication, capturing events related to user sign-ins, service principal token requests, and conditional access outcomes. These logs cannot detect malicious outbound connections made by a compromised VM. Identity logs and network-layer logs address completely different security domains, with the latter being essential for identifying C2 or botnet communications.

Microsoft Defender for Endpoint can detect malicious outbound network behavior, but only if the endpoint is onboarded and running the Defender sensor. In many Azure environments, especially those hosting Linux VMs, containers, appliances, or third-party workloads, Defender agents may not be installed. Azure Firewall Threat Intelligence provides network-boundary protection for all workloads in the virtual network, regardless of whether an agent exists. This makes it an essential layer in cloud environments where agent-based coverage is incomplete or impractical.

Integrating Azure Firewall Threat Intelligence logs with Microsoft Sentinel enhances real-time threat detection. The firewall generates alerts such as attempted connections to known malware distribution sites, botnet IP addresses, or phishing command servers. Sentinel can correlate these alerts with identity signals, VM behavior, or Defender for Endpoint detections to determine whether a workload has been compromised. This correlation helps SOC teams quickly isolate affected VMs, block outbound traffic, revoke credentials, or trigger automated remediation workflows.

Because command-and-control traffic is one of the earliest indicators of compromise—and often precedes ransomware deployment or data theft—blocking it at the network perimeter drastically reduces attacker dwell time. Azure Firewall Threat Intelligence acts as a wide-coverage security layer for all workloads inside Azure VNets, providing protection even when endpoint tools are missing or misconfigured.

For these reasons, Azure Firewall Threat Intelligence is the correct and most effective solution for detecting malicious outbound traffic and protecting cloud workloads against sophisticated network-based threats.