Visit here for our full Microsoft SC-200 exam dumps and practice test questions.
Question 151
Your SOC needs to detect suspicious or unauthorized modifications to Azure Front Door Rules Engine configurations, such as altering URL rewrite rules, modifying header transformations, or adding malicious redirect rules. Which log source should be ingested into Sentinel?
A) Azure Activity Logs
B) Azure Front Door Access Logs
C) Azure AD Sign-in Logs
D) DeviceProcessEvents
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the correct source for detecting unauthorized modifications to Azure Front Door Rules Engine configurations because they capture control-plane operations executed via ARM. The Rules Engine determines how Front Door manipulates HTTP requests—rewriting URLs, modifying headers, performing redirects, enforcing security rules, and controlling traffic routing. Attackers who compromise administrative access may attempt to alter these rules to redirect users to malicious domains, weaken security measures, bypass application firewalls, or inject harmful headers. Azure Activity Logs store vital metadata including the identity performing the change, the specific API call used, timestamp, operation success or failure, subscription details, and the affected rule configuration. Access Logs only show data-plane HTTP request and response activity but provide no visibility into administrative configuration changes. Azure AD Sign-in Logs track authentication events, but not configuration modifications. DeviceProcessEvents relate to endpoint-level process activity and are irrelevant to cloud-based Front Door settings. By ingesting Activity Logs into Sentinel, SOC teams can detect unauthorized rewrites, suspicious redirect rules pointing to unknown domains, unusual modifications to security headers, or disabling of routing constraints. Because Front Door functions as a global entry point for many critical applications, monitoring configuration integrity is essential to preventing large-scale compromise. Thus, Azure Activity Logs are the correct choice.
Question 152
Your SOC team wants to detect suspicious operations in Azure Bastion that involve modifying Bastion host settings, changing VNet associations, or enabling public IP exposure. Which log source should be connected to Sentinel?
A) Azure Activity Logs
B) Azure Bastion Session Logs
C) DeviceSecurityEvents
D) Azure AD Audit Logs
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the correct ingestion point for detecting control-plane configuration changes to Azure Bastion. While Bastion Session Logs provide insight into remote desktop sessions (RDP/SSH) through Bastion, they do not capture administrative modifications to Bastion host configurations. Attackers who gain administrative access may attempt to modify Bastion settings to expose management endpoints, change associated virtual networks, alter private/public IP settings, or integrate Bastion with untrusted subnets. Azure Activity Logs capture operations such as “Microsoft.Network/bastionHosts/write,” along with the performing identity, timestamp, origin IP address, and affected resource. Azure Bastion Session Logs are data-plane and only show session activity. DeviceSecurityEvents track local endpoint behavior and are unrelated to cloud Bastion configuration changes. Azure AD Audit Logs track identity directory actions and cannot detect resource-level modifications. Monitoring Activity Logs in Sentinel allows SOC analysts to detect unauthorized Bastion modifications, including attaching Bastion to sensitive networks without approval, enabling internet exposure, or deleting key configurations. Because Bastion provides privileged remote access, safeguarding its configuration is vital. Thus, Azure Activity Logs are the correct choice.
Question 153
Your SOC must detect unauthorized or suspicious modifications to Azure Event Hub Capture settings, such as redirecting captured logs to unauthorized Storage accounts, lowering retention periods, or disabling capture entirely. Which log source should be ingested?
A) Azure Activity Logs
B) Event Hub Diagnostic Logs
C) Storage Analytics Logs
D) Azure AD Sign-in Logs
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the correct source for detecting control-plane configuration changes to Event Hub Capture settings. Capture automatically stores event stream data into Storage or Data Lake locations for retention, auditing, and downstream processing. Attackers may modify Capture settings to redirect logs to attacker-owned Storage accounts, disable Capture to hide malicious activity, or reduce retention to destroy forensic data. Azure Activity Logs capture every ARM-level change related to Event Hub properties, including Capture enable/disable operations, Storage account destination changes, and retention policy updates. Event Hub Diagnostic Logs capture data-plane activity such as message send/receive interactions but do not include configuration changes. Storage Analytics Logs provide data-plane insights but cannot detect modifications from Event Hub. Azure AD Sign-in Logs show authentication behavior only. In Sentinel, ingesting Azure Activity Logs allows analysts to detect attempts to tamper with Capture by observing unusual Storage account assignments, sudden disabling of long-term data retention, and suspicious edits performed off-hours. Because Event Hub Capture plays a critical role in logging pipelines and compliance workflows, monitoring these configurations is essential. Therefore, Azure Activity Logs are the correct answer.
Question 154
Your SOC needs to detect unauthorized or suspicious changes to Azure SQL Failover Group configurations, such as changing failover policies, adding untrusted secondary servers, or modifying read-write endpoints. Which log source should you integrate?
A) Azure Activity Logs
B) SQL Auditing Logs
C) Azure AD Audit Logs
D) NSG Flow Logs
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the authoritative log source for detecting control-plane changes to Azure SQL Failover Group configurations. Failover Groups define high-availability and disaster recovery behavior for SQL databases across regions. Attackers who compromise administrative credentials may try to modify failover modes, attach unauthorized secondary servers, switch endpoint URLs, or misconfigure read-write failover rules to secretly redirect database traffic. Azure Activity Logs capture ARM-level modifications such as “failoverGroups/write,” recording critical information including the identity performing the action, timestamp, originating IP, API version, and operation status. SQL Auditing Logs detect data-plane activity (queries, logins, schema operations) but do not record Failover Group configuration changes. Azure AD Audit Logs monitor directory changes, not SQL server configuration. NSG Flow Logs show network activity but not control-plane modifications. In Sentinel, analysts can create detections for unauthorized failover policy changes or suspicious additions of new servers to Failover Groups, which may indicate tampering or data redirection attempts. Maintaining strict oversight of failover configurations is essential for ensuring business continuity and preventing covert data hijacking. Thus, Azure Activity Logs are the correct ingestion choice.
Question 155
Your SOC needs to detect suspicious or unauthorized modifications to Azure Key Vault Access Policies, such as adding privileged identities, removing restrictions, or granting unexpected permissions like “get”, “list”, or “recover”. Which log source should be connected to Sentinel?
A) Azure Activity Logs
B) Key Vault Access Logs
C) DeviceSecurityEvents
D) Azure AD Sign-in Logs
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs provide the required visibility for detecting unauthorized or suspicious modifications to Key Vault Access Policies. Access Policies determine which identities can retrieve secrets, manage certificates, or perform key operations. Attackers who compromise privileged accounts may attempt to add malicious service principals, grant themselves “get” or “list” permissions, or loosen restrictions to facilitate secret theft. Azure Activity Logs record every change to Key Vault Access Policies, including operations like “Microsoft.KeyVault/vaults/accessPolicies/write,” along with the performing identity, timestamp, API call details, requester IP, and scope of the updated permissions. Key Vault Access Logs track data-plane operations—such as reading secrets or using keys—rather than access policy configuration changes. DeviceSecurityEvents only capture endpoint-level behavior, and Azure AD Sign-in Logs focus on authentication activity, not access policy modifications. Ingesting Activity Logs into Sentinel allows SOC analysts to detect the creation of suspicious privileged access grants, unauthorized removal of least-privilege restrictions, or off-hours updates to sensitive Key Vault permissions. Key Vault often stores credentials, certificates, keys, and other sensitive information, so strict visibility into access policy governance is crucial. Thus, Azure Activity Logs are the correct answer.
Question 156
Your SOC wants to detect suspicious or unauthorized modifications to Azure VPN Gateway connections, such as changing shared keys, altering routing configurations, or adding new on-premises endpoints. Which log source should be ingested into Sentinel?
A) Azure Activity Logs
B) Azure VPN Gateway Diagnostic Logs
C) DeviceNetworkEvents
D) Azure AD Audit Logs
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the correct source for detecting unauthorized or suspicious modifications to Azure VPN Gateway configurations because all VPN connection properties—including shared keys, routing settings, on-premises endpoint definitions, and BGP parameters—are controlled through ARM operations. Attackers who compromise privileged cloud identities may attempt to change VPN shared keys to intercept traffic, add rogue on-premises endpoints, or modify routing configurations to divert traffic through malicious nodes. Azure Activity Logs capture every control-plane modification with details such as the performing identity, API call invoked (“Microsoft.Network/vpnConnections/write”), timestamp, requester IP address, and status of the operation. VPN Gateway Diagnostic Logs provide data-plane information such as tunnel health and IPsec negotiation, but they do not record modifications to connection settings. DeviceNetworkEvents only capture network traffic from local endpoints, not cloud VPN configuration changes. Azure AD Audit Logs track directory operations but cannot detect VPN Gateway modifications. When ingested into Sentinel, Activity Logs allow SOC teams to build alerts for suspicious VPN connection changes—such as newly added IP addresses, unexpected key regeneration, or routing modifications that could facilitate interception or data exfiltration. Securing VPN Gateways is essential for hybrid environments where core corporate traffic flows through these tunnels. Therefore, Azure Activity Logs are the correct ingestion source.
Question 157
Your SOC team wants to detect suspicious changes to Azure Resource Locks, such as removing “Delete” or “ReadOnly” locks placed on critical resources. These actions could allow attackers to alter or delete protected infrastructure. Which log source must be integrated into Sentinel?
A) Azure Activity Logs
B) Azure AD Audit Logs
C) DeviceProcessEvents
D) NSG Flow Logs
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the authoritative source for detecting modifications to Azure Resource Locks. Resource Locks (Delete and ReadOnly) act as guardrails that prevent accidental or malicious changes to critical resources. Attackers who gain privilege in an Azure environment may first attempt to remove these locks to enable destructive or unauthorized actions—such as deleting VMs, modifying Key Vault settings, or altering Storage accounts. Because Resource Locks are managed entirely through ARM operations, Azure Activity Logs capture all relevant events, including creation, modification, and deletion of locks. The logs include metadata such as identity performing the operation, timestamp, initiating IP, subscription details, and the specific action such as “Microsoft.Authorization/locks/delete” or “write.” Azure AD Audit Logs track directory-level role changes but not resource-level protections. DeviceProcessEvents are endpoint-related and irrelevant to cloud operations. NSG Flow Logs track network flows but cannot detect administrative lock modifications. By ingesting Activity Logs into Sentinel, SOC analysts can detect actions that remove critical safeguards, allowing unauthorized tampering with sensitive infrastructure. Resource Locks are often used to protect mission-critical resources, disaster recovery components, or highly sensitive security configurations. Thus, monitoring these changes through Azure Activity Logs is essential.
Question 158
Your SOC wants to detect unauthorized changes to Azure SQL Server Auditing settings, such as disabling auditing, altering audit log destinations, or modifying retention periods. Which log source should be ingested?
A) Azure Activity Logs
B) SQL Server Auditing Logs
C) DeviceSecurityEvents
D) Azure AD Sign-in Logs
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the correct log source for detecting changes to SQL Server Auditing settings because all configuration updates—including enabling/disabling auditing, modifying log destinations, and adjusting retention settings—occur through ARM-level operations. Attackers aiming to cover their tracks may disable auditing, redirect logs to attacker-owned storage accounts, or reduce retention periods to remove historical evidence. Azure Activity Logs capture these sensitive administrative actions with details such as the performing identity, timestamp, executing IP address, and the ARM operation (e.g., “Microsoft.Sql/servers/auditingSettings/write”). SQL Server Auditing Logs contain data-plane audit entries (queries, login events, schema changes), but not configuration modifications. DeviceSecurityEvents capture local machine behavior, and Azure AD Sign-in Logs monitor authentication activity only. Ingesting Activity Logs into Sentinel allows SOC analysts to detect attempts to disable auditing or redirect audit logs. Because SQL auditing is critical for security, compliance, and forensic investigations, monitoring audit configuration integrity through Activity Logs is essential. Thus, Azure Activity Logs are the correct ingestion source.
Question 159
Your SOC needs to detect unauthorized or suspicious modifications to Azure Event Grid system topics, including changes to event subscriptions, updating endpoints, or disabling critical event delivery paths. Which log source should be used?
A) Azure Activity Logs
B) Event Grid Diagnostic Logs
C) NSG Flow Logs
D) Azure AD Sign-in Logs
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the correct source for detecting changes to Event Grid system topic configurations because these topics—created automatically by Azure services—can only be modified through ARM operations. Attackers who compromise administrative accounts may attempt to alter system topic subscriptions, redirect event delivery to malicious endpoints, update webhook URLs, or disable important event routing paths to suppress alerts from services like Key Vault, Storage, or Resource Manager. Azure Activity Logs capture subscription updates, endpoint modifications, and policy changes with details including the performing identity, timestamp, operation name, and originating IP. Event Grid Diagnostic Logs capture data-plane delivery events but not subscription modifications or system topic governance actions. NSG Flow Logs track network traffic but cannot detect event routing changes. Azure AD Sign-in Logs reflect authentication events but not Event Grid configuration updates. By ingesting Activity Logs into Sentinel, analysts can detect unauthorized tampering with critical event delivery systems, ensuring visibility into potential attack paths involving alert suppression or event redirection. Because system topics are integral to Azure’s event-driven architecture, monitoring their configuration integrity is essential. Thus, Azure Activity Logs are the correct choice.
Question 160
Your SOC team needs to detect suspicious or unauthorized changes to Azure Web App Diagnostic Settings, such as disabling logging, redirecting logs to unauthorized destinations, or reducing retention. Which log source should be ingested?
A) Azure Activity Logs
B) App Service Diagnostic Logs
C) Azure Firewall Logs
D) DeviceFileEvents
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the correct and authoritative source for detecting control-plane changes to Azure Web App Diagnostic Settings. These settings determine where and how diagnostic data—such as application logs, HTTP logs, metrics, and container logs—is collected and stored. Attackers aiming to hide malicious behavior may attempt to disable logging, shorten retention periods, or redirect logs to compromised Storage accounts. Since Diagnostic Settings are configured via ARM, Activity Logs capture all relevant modifications including the performing identity, timestamp, initiating IP, and the exact API call invoked. App Service Diagnostic Logs show application-level behavior but not configuration changes. Azure Firewall Logs track network traffic and cannot detect logging configuration tampering. DeviceFileEvents show local endpoint file changes only. Ingesting Activity Logs into Sentinel allows SOC analysts to detect unauthorized changes that may compromise observability—such as disabling log streams or redirecting diagnostic data to unauthorized locations. Maintaining logging integrity is essential for detection, auditing, and forensics. Therefore, Azure Activity Logs serve as the correct log source.
Question 161
Your SOC must detect unauthorized changes to Azure Disk Encryption settings, such as disabling encryption, switching encryption types, or replacing key providers. Which log source should be ingested into Sentinel?
A) Azure Activity Logs
B) Disk Access Logs
C) Azure AD Audit Logs
D) NSG Flow Logs
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the correct and authoritative source for detecting configuration changes to Azure Disk Encryption settings because all disk encryption modifications occur at the Azure Resource Manager (ARM) control-plane layer. Attackers who gain privileged access may attempt to weaken disk protection by disabling encryption, switching from customer-managed keys (CMK) to platform-managed keys (PMK), or replacing Key Vault references with malicious or untrusted key sources. These changes can significantly compromise data confidentiality and expose sensitive information stored in virtual machine disks. Azure Activity Logs capture every relevant operation such as “Microsoft.Compute/disks/write,” “Microsoft.Compute/disks/beginGetAccess,” and changes to encryptionSet references. Each log entry includes metadata such as the identity performing the change, timestamp, API version used, the IP address of the requester, and the associated resource details. Disk Access Logs only apply when using private endpoints for disk access—they do not capture encryption modifications. Azure AD Audit Logs capture identity directory operations but do not capture ARM-based disk encryption changes. NSG Flow Logs show network traffic patterns and are unrelated to disk configuration. Ingesting Activity Logs into Sentinel allows SOC analysts to quickly identify unauthorized attempts to alter encryption settings, detect privilege escalation attempts targeting disk-level security, and correlate suspicious actions with identity anomalies or lateral movement behaviors. Because disk encryption protects data at rest—one of the most fundamental security controls—monitoring all related configuration changes is essential. Therefore, Azure Activity Logs are the correct ingestion source.
Question 162
Your SOC wants to detect unauthorized or suspicious modifications to Azure Web Application configuration settings, such as altering app settings, injecting malicious connection strings, or changing authentication parameters. Which log source should you ingest?
A) Azure Activity Logs
B) App Service HTTP Logs
C) DeviceSecurityEvents
D) Azure AD Sign-in Logs
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the correct log source for detecting unauthorized modifications to App Service configuration settings. These configuration settings—including application settings, environment variables, connection strings, authentication parameters, and runtime stack configurations—are managed through ARM operations. Attackers who compromise administrative access may attempt to inject malicious environment variables, replace safe database connection strings with attacker-controlled endpoints, or modify authentication settings to bypass or weaken application defenses. Azure Activity Logs record all modifications to “Microsoft.Web/sites/config” with full metadata such as performing identity, timestamp, operation name, IP address of the requester, and the scope of the change. App Service HTTP Logs provide data-plane HTTP request and response logs only—they do not log administrative configuration changes. DeviceSecurityEvents record local endpoint activity. Azure AD Sign-in Logs capture authentication attempts but cannot reflect application configuration updates. By ingesting Activity Logs into Sentinel, SOC teams can detect attempts to tamper with Web App configurations, especially changes that introduce persistence, backdoor access, or data exfiltration mechanisms. Maintaining the integrity of configuration settings is crucial because even minor changes can impact application behavior, security posture, or integration with other systems. Therefore, Azure Activity Logs are the correct ingestion source.
Question 163
Your SOC must detect suspicious or unauthorized changes to Azure Key Vault networking settings, such as enabling public network access, adding malicious IP addresses, or disabling private endpoints. Which log source should you use?
A) Azure Activity Logs
B) Key Vault Access Logs
C) DeviceLogonEvents
D) Azure Firewall Logs
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the authoritative and essential log source for detecting control-plane modifications to Azure Key Vault networking configurations. Key Vault is one of the most sensitive services in the entire Azure ecosystem because it stores cryptographic keys, certificates, application secrets, tokens, Storage Account keys, SQL connection credentials, OAuth secrets, service principal credentials, and other critical security assets. These items directly protect applications, databases, virtual machines, Kubernetes clusters, and automated workloads across an organization’s cloud estate. For attackers, gaining access to Key Vault is equivalent to gaining access to the organization’s digital identity and encryption backbone. As a result, one of the first steps a threat actor often takes after compromising privileged access is attempting to weaken Key Vault networking protections. Azure Activity Logs provide complete visibility into these attempts, making them the correct and indispensable ingestion source for monitoring such events.
Azure Key Vault networking configurations are managed entirely through the Azure Resource Manager (ARM) control plane. This includes operations such as modifying firewall IP allowlists, enabling or disabling private endpoints, changing virtual network integration settings, toggling public network access, altering bypass rules for trusted Azure services, and updating network access control lists (ACLs). When any such modification is made—whether through the Azure Portal, Azure CLI, PowerShell, REST API, Terraform, or DevOps automation pipelines—the action is executed through ARM. Each ARM operation generates an entry in Azure Activity Logs, recording detailed metadata about the request, including the identity performing the change, client IP address, timestamp, subscription and resource group, operation name, and the exact network configuration altered.
Attackers frequently target Key Vault’s network perimeter. For example, an adversary who gains Contributor or Owner access might disable private endpoint-only access, immediately exposing Key Vault to the public internet. They may add their own IP addresses to the allowlist or broaden the IP range to include large external blocks. They may remove strict network ACLs or use bypass rules to make traffic appear trusted. Each of these modifications represents a critical security breach, because once Key Vault is reachable by the attacker, they can attempt to retrieve secrets, harvest certificates, or export encryption keys. Azure Activity Logs identify these configuration updates so SOC analysts can detect, investigate, and respond before data theft occurs.
Key Vault Access Logs, although essential for monitoring data-plane operations, do not track configuration changes. Access Logs record events such as secret retrieval, key operations, certificate issuance, version listing, and failed secret access attempts. While these logs help identify misuse or suspicious behavior inside Key Vault’s runtime layer, they cannot identify control-plane actions such as enabling public access or detaching private endpoints. An attacker may first weaken network restrictions, then quietly extract secrets. Without Activity Logs, the initial and most crucial part of the attack chain would go unnoticed.
DeviceLogonEvents are limited to on-premises or Windows endpoint user login activity. They offer no visibility into Azure-native configuration changes. Even if an attacker uses a compromised workstation to modify Key Vault network settings, DeviceLogonEvents would only show a local login or process execution. They cannot reveal the ARM action, the identity that performed it in Azure, or which Key Vault properties were modified.
Azure Firewall Logs provide layer-4 and layer-7 network traffic visibility and are extremely valuable for detecting malicious outbound connections or blocked intrusion attempts. However, they cannot detect when a Key Vault’s firewall settings are altered, when public access is enabled, or when private endpoints are removed. Azure Firewall Logs show traffic but do not track the configuration governing that traffic. Only Azure Activity Logs can provide this essential context.
Azure Activity Logs capture the precise ARM operations used to modify Key Vault networking, including calls such as Microsoft.KeyVault/vaults/networkAcls/write. These entries include the actor responsible—whether it is a human admin, compromised service principal, automation account, or malicious script—and the exact nature of the network change. SOC teams can use this data to detect suspicious events such as:
Azure Activity Logs also support compliance, forensic investigations, and cloud governance requirements. Regulatory frameworks such as HIPAA, PCI DSS, ISO 27001, SOC 2, and GDPR mandate strict control over sensitive encryption keys and secret-management systems. These frameworks require organizations to maintain auditable records of configuration changes to systems protecting sensitive data. Activity Logs provide immutable evidence showing every network configuration action applied to a Key Vault, who performed it, and under what context. This allows security and compliance teams to demonstrate strong governance during audits and accountability reviews.
In forensic investigations, Activity Logs allow analysts to reconstruct a complete timeline of Key Vault exposure. For example, if secrets are leaked or compromised, investigators can determine whether the attacker first changed firewall rules or public access configurations, detect the exact moment the access boundary was opened, identify the identity used, and correlate this event with subsequent suspicious secret-access patterns.
Activity Logs further support cloud automation and Zero Trust governance frameworks. Tools such as Microsoft Defender for Cloud or Azure Policy rely on Activity Log data to detect misconfigurations or apply governance rules that prevent insecure Key Vault networking policies from persisting. If Activity Logs are not ingested into Sentinel or other monitoring systems, organizations lose their ability to detect and prevent such misconfigurations quickly.
Because Key Vault protects the most sensitive secrets within an organization, monitoring and securing its network perimeter is one of the highest-value defensive actions SOC teams can take. Azure Activity Logs provide complete, authoritative, and tamper-resistant insight into the control-plane operations that define Key Vault’s network accessibility. They reveal when attackers—or misconfigured automation—attempt to weaken network boundaries that protect mission-critical credentials.
For all these reasons, Azure Activity Logs are the correct and essential ingestion source for monitoring Azure Key Vault networking configuration changes.
Question 164
Your SOC team needs to detect unauthorized or suspicious changes to Azure Redis Cache configurations, such as updating firewall rules, enabling non-SSL ports, or modifying clustering settings. Which log source should be ingested?
A) Azure Activity Logs
B) Redis Cache Diagnostic Logs
C) DeviceProcessEvents
D) Azure AD Audit Logs
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the authoritative and complete source for detecting unauthorized or suspicious modifications to Azure Cache for Redis configurations. Redis is frequently used as a high-performance, in-memory data store that powers authentication workflows, session management, caching layers for APIs, microservices communication, real-time analytics, and application-side state management. Because Redis often holds security-critical assets such as session tokens, authentication cookies, user profile fragments, application secrets cached in memory, and high-throughput operational data, attackers view Redis as a strategic entry point. Any unauthorized configuration change—especially those made through Azure Resource Manager (ARM)—can dramatically weaken the security posture of the cache. Azure Activity Logs offer the only complete visibility into these control-plane operations, making them the correct ingestion source for detecting Redis configuration tampering.
Azure Cache for Redis configuration settings are controlled entirely through ARM. This includes enabling or disabling SSL ports, configuring allowed client IP addresses through firewall rules, modifying TLS versions, changing clustering behavior, altering shard allocations, enabling or disabling data persistence, updating Redis version settings, adjusting private endpoint configurations, and modifying diagnostic logging configurations. Whenever a change is made—whether through the Azure Portal, Azure CLI, PowerShell, REST APIs, Bicep, or Terraform—the action generates an ARM event captured in Azure Activity Logs. Because attackers who gain privileged access often attempt to operate stealthily by altering ARM-managed security settings, Activity Logs are indispensable for detection.
One of the highest-risk attack scenarios involves disabling or weakening TLS/SSL enforcement on Redis. By default, Azure Redis uses encrypted channels to prevent attackers from intercepting or modifying data-in-transit. An attacker with Contributor or Owner rights might attempt to enable the non-SSL endpoint, allowing traffic to flow in cleartext. This exposes sensitive cached information to potential interception or manipulation. Activity Logs capture these changes as Microsoft.Cache/Redis/write operations, recording exactly when SSL port configurations are altered and by which identity.
Firewall rule modifications present another major risk. Redis supports IP-based access controls that restrict which clients can connect. Attackers may expand firewall rules by adding foreign IP ranges, enabling access from malicious infrastructure, or removing previously restricted IPs. These actions weaken the network boundary around Redis, providing attackers with stable access paths. Azure Activity Logs record each modification with details such as the requester’s IP address, timestamp, target resource name, and subscription. SOC analysts rely on this data to detect unauthorized expansions that undermine security.
Clustering and sharding configurations also impact Redis availability and data distribution. Attackers might attempt to alter shard counts, resource allocations, or clustering topology to introduce instability or hide malicious persistence. For example, by modifying the cluster configuration, a threat actor could redirect certain types of cached data to shards they can access, or cause workload disruptions as a distraction before pivoting deeper into the environment. Activity Logs surface these actions, helping security teams identify configuration changes inconsistent with normal operations.
Diagnostic settings are equally important. Redis supports diagnostic logs and metrics that help teams monitor performance, usage patterns, and anomalous behavior. Attackers may disable or weaken diagnostic settings to reduce monitoring visibility. Azure Activity Logs capture modifications to diagnostic settings, allowing SOC teams to detect attempts to turn off logging or reduce the fidelity of monitoring data.
Redis data-plane activities, such as GET, SET, PING, HGETALL, or AUTH operations, do not appear in Azure Activity Logs because they are runtime operations. These events are instead recorded in Redis Diagnostic Logs. However, Diagnostic Logs are not designed to capture control-plane changes like firewall rule updates or SSL configuration alterations. Relying on Redis Diagnostic Logs alone would blind an organization to the most dangerous security modifications—those that affect who can connect, how securely they communicate, and what interfaces are exposed.
DeviceProcessEvents are limited to endpoint telemetry from Defender for Endpoint and relate to local process behavior, such as PowerShell scripts, command execution, suspicious binaries, or malicious process activity. These logs are valuable when investigating compromised developer machines or administrative workstations but provide no visibility into cloud-hosted Redis configuration changes. Even if an attacker uses a compromised endpoint to modify Redis configurations, DeviceProcessEvents would only show local execution steps, not the resulting ARM-based modification.
Azure AD Audit Logs, while indispensable for tracking identity-related events such as role assignments, privilege elevations, and service principal modifications, cannot detect Redis configuration changes. They reveal who gained access, but not how that access was used at the resource configuration level. To determine whether an attacker used the compromised identity to weaken Redis network guardrails or modify TLS settings, Azure Activity Logs must be consulted.
Azure Activity Logs also play a key role in compliance and regulatory oversight. Many organizations using Redis handle sensitive data regulated under PCI DSS, HIPAA, GDPR, SOX, or other frameworks. Unauthorized weakening of security boundaries—such as enabling non-encrypted ports or exposing Redis to public IPs—can trigger compliance violations. Activity Logs provide immutable, timestamped records of all control-plane configuration changes, supporting audit readiness and compliance reporting.
From a forensics standpoint, Activity Logs are indispensable for reconstructing attack timelines. When investigators analyze a Redis-related breach, they must determine whether attackers altered firewall rules, changed TLS settings, or modified clustering before conducting data exfiltration. Activity Logs provide the exact sequence of these changes, enabling forensic teams to establish root cause, scope of compromise, and potential impact.
Redis configuration integrity is especially important because Redis is often used to store ephemeral but sensitive data that may not be protected elsewhere. Tokens, credentials, cache fragments, session data, and application state stored in Redis can reveal sensitive details about users or application behavior. If an attacker weakens network protections or bypasses SSL requirements, they can extract this data with minimal resistance.
Azure Activity Logs ensure full visibility into the configuration actions that allow or prevent such attacks. They remain the correct ingestion source because they provide complete, authoritative, and unambiguous records of all ARM-based Redis configuration modifications.
Question 165
Your SOC needs to detect unauthorized modifications to Azure Web App deployment slots, including swapping slots unexpectedly, modifying slot settings, or deploying malicious code into staging environments. Which log source is required?
A) Azure Activity Logs
B) App Service Deployment Logs
C) NSG Flow Logs
D) DeviceSecurityEvents
Answer: A) Azure Activity Logs
Explanation
Azure Activity Logs are the authoritative and correct log source for detecting control-plane configuration changes to Azure App Service deployment slots. Deployment slots are powerful operational tools that allow organizations to maintain multiple runtime environments—such as staging, testing, and production—within a single App Service. Because slot operations such as creating a slot, swapping slots, modifying slot settings, and updating slot configuration occur entirely through Azure Resource Manager (ARM), Azure Activity Logs provide the only complete and reliable visibility into these changes. For modern application architectures, deployment slots carry significant security implications, and attackers frequently attempt to abuse them when compromising cloud identities or CI/CD pipelines. Therefore, monitoring slot-related operations through Azure Activity Logs is essential for protecting production workloads, ensuring deployment integrity, and enabling timely detection of unauthorized code promotions.
Deployment slots support blue-green deployment patterns, A/B testing, staged rollouts, and production-ready validation. They allow applications to run in a staging slot where updates can be tested, verified, and validated before being promoted to the production slot via a slot swap. Because the swap seamlessly exchanges routing and configuration between slots, attackers who gain administrative access may exploit this to push malicious code or altered configurations into production with minimal visibility. Azure Activity Logs capture each of these swap operations through API calls such as Microsoft.Web/sites/slotsswap/action. These logs reveal the identity initiating the swap, the precise timestamp, the source IP address, the resource ID of the App Service, and the result of the operation.
Slot creation and deletion events are equally important to monitor. Attackers may create a new slot unnoticed, deploy malicious artifacts into it, and later promote that slot into production. Slot creation is logged under Microsoft.Web/sites/slots/write operations, which appear in Azure Activity Logs with rich metadata describing who created the slot, where the request was initiated, and which configuration settings were included. Activity Logs also capture modifications to slot-specific configurations such as app settings, connection strings, authentication requirements, managed identities, virtual networking integrations, custom domain assignments, and TLS/SSL bindings. Because slot settings can override or inherit production configurations depending on the slot type, a malicious alteration could go undetected until after a swap. Activity Logs ensure that SOC teams can track every configuration change that affects slot behavior.
App Service Deployment Logs, which track code deployment events within a slot, provide limited visibility into the actual content deployed or whether the deployment was triggered manually or by CI/CD pipelines. While useful for understanding code deployment patterns, these logs cannot detect slot swaps, slot-level configuration changes, firewall adjustments, or ARM-based modifications. Deployment Logs operate inside the runtime environment of a slot and are part of the data plane, not the control plane. Threat actors who manipulate slot configurations or perform swaps entirely through ARM would remain undetected if relying solely on App Service Deployment Logs.
NSG Flow Logs, which capture network ingress and egress traffic at the network security group layer, cannot detect App Service control-plane operations. Even though they help identify suspicious traffic patterns or anomalous connections, they offer no insight into internal App Service operations such as slot swaps, swap failures, slot renames, or slot-specific configuration updates. Attackers who alter App Service functionality through ARM will not generate network traffic patterns detectable by NSG Flow Logs.
DeviceSecurityEvents provide telemetry associated with endpoint activity monitored by Microsoft Defender for Endpoint, such as process launches, malicious script execution, and operating system tampering. Although valuable for detecting compromised developer machines or administrative endpoints, these logs cannot observe cloud-native slot operations. Even if a compromised workstation triggers a slot operation via Azure CLI or PowerShell, DeviceSecurityEvents would only show a local process executing commands—without recording the ARM operation itself. Azure Activity Logs remain the only authoritative source for these cloud-level actions.
The security implications of deployment slots cannot be overstated. Attackers often exploit deployment systems because swaps are operationally trusted and can promote code into production rapidly. For example, an attacker could deploy a malicious web shell, backdoor, cryptomining script, or credential harvesting mechanism into a staging slot. After ensuring it runs properly, they could perform a slot swap to instantly push the payload into production. Because slot swaps preserve operational characteristics such as TLS bindings and scale settings, this technique allows attackers to establish stealthy persistence. Azure Activity Logs provide the necessary forensic trail to detect such abuse by logging the exact moment a swap occurs and the identity responsible.
Slot-specific configuration changes are equally important to track. Threat actors may tamper with connection strings or authentication settings in staging slots, knowing that a later swap will bring those compromised configurations into production. They might modify managed identities, enabling additional permissions that persist after a swap. They may change diagnostic settings, limit logging visibility, or disable monitoring plugins to conceal future activity. Activity Logs capture these modifications, including what property was updated and which API method was used.
These detections can help prevent attacks where the adversary attempts to use deployment slots as a vector for persistence, lateral movement, or stealthy code injection.
Deployment slots also pose compliance and governance risks. Many organizations enforce strict controls around production deployments, requiring change-control documentation, approvals, and traceable audit records. Slot swaps that bypass these processes could violate internal policies or external regulatory requirements. Azure Activity Logs serve as an immutable, audit-ready record of all control-plane slot operations, enabling compliance teams to verify that deployment processes are being followed correctly.
In incident response scenarios, Azure Activity Logs allow investigators to reconstruct deployment slot histories. If a compromise occurs, investigators can examine Activity Logs to identify whether unauthorized swaps or slot-level configuration changes preceded the incident. These logs provide precise timestamps and identity details that help clarify whether code promotion was malicious, accidental, or legitimate.
Because deployment slots are deeply integrated into the operational and security posture of App Services, monitoring their control-plane operations is essential for maintaining deployment integrity and defending against sophisticated cloud-native attacks. Azure Activity Logs provide consistent, authoritative, and detailed insight into every change, ensuring SOC teams can detect unauthorized activity before it impacts production environments.