Respond to security incidents practice questions

Disable the user's account

Why wrong: Disabling the user's account is a containment action reserved for confirmed credential compromise or malicious insider activity. In this case, the only evidence is a link click, with no proof of malware execution, credential theft, or unauthorized access, so disabling the account would cause business disruption and potentially alert the adversary while doing nothing to contain the malicious domain itself.

Revoke the user's active sessions

Why wrong: Revoking the user's active sessions is intended for scenarios where authentication tokens or session cookies have been stolen, such as in a token theft or account takeover. Clicking a link does not compromise the user's existing session token; the malicious site could attempt a browser exploit, but that would not invalidate the authenticated session, and this action would still leave the malicious domain reachable by other users.

Reset the user's password

Why wrong: A password reset is warranted only when there is concrete evidence that the user's credentials were phished or otherwise stolen and used by an unauthorized party. Here, no credential submission, authentication anomaly, or suspicious account activity has been observed, so resetting the password would lock the user out without eliminating the threat posed by the malicious domain, which remains accessible to the entire environment.

Notify the user about the policy violation

Why wrong: Sending a notification to the user about the policy violation is a governance or remediation step, not a containment control. The user may be the attacker or have compromised credentials, so the notification does not stop ongoing exfiltration or encryption, and it could even tip the attacker off. Notification is only useful after active containment has secured the environment.

Initiate a legal hold on the user's data

Why wrong: Placing a legal hold (litigation hold) on the user's data preserves content in-place for eDiscovery and legal investigations, ensuring that evidence is not deleted or altered. It does not revoke access, block uploads, or halt active ransomware activity, and it does not affect real-time data movement. Thus it is an evidence-preservation step, not a contain-and-respond action.

Block the source IP address on the firewall

Why wrong: Blocking the source IP on the firewall is a reactive containment step that should be taken only after investigation confirms the IP is genuinely malicious. In Microsoft Sentinel, the incident may include alerts triggered by a shared NAT IP or a legitimate user repeatedly mistyping passwords, so an immediate block could cause service outages for many users. Furthermore, you need to check threat intelligence, verify the IP's reputation, and correlate it with other signals before initiating a firewall change, especially since the block should be executed through an automated playbook only under validated conditions.

Notify the users of the failed login attempts

Why wrong: Notifying users of failed login attempts is premature because the incident may involve an attacker's operations, and alerting users could compromise the investigation or trigger a destructive response from the adversary. Additionally, in a large enterprise, users may not be the ones initiating those attempts, and mass notification could create confusion or panic without actionable guidance. Communication of this type typically occurs only after the investigation has confirmed which accounts are impacted and a clear remediation and communication plan has been established, in line with incident response protocols.

Reset passwords for all affected accounts

Why wrong: Resetting passwords for all affected accounts before investigating is dangerous because it may lock out legitimate users and disrupt the ability to monitor the attacker's behavior. Without investigation, you don't know which accounts are truly compromised, nor whether the failed attempts came from a password spray targeting many users or from a single attacker using one account. Premature password resets could also alert the attacker that they are detected, causing them to change tactics or destroy evidence before you can complete the forensic analysis and determine the full attack path.

Disable the user's account

Why wrong: Disabling the user's account targets the identity that happened to log in to the device, not the malicious code or persistence mechanisms already running on that host. Attackers frequently maintain remote access through scheduled tasks, services, or injected processes that continue to operate even when the user cannot authenticate, so the device remains a threat. This action can also lock out a legitimate user unnecessarily and should be reserved for later if credential compromise is confirmed, not used as a containment measure.

Run a full antivirus scan on the device

Why wrong: A full antivirus scan is fundamentally a detection and remediation tool, not a containment action, because it does nothing to disconnect the compromised device from the network or interrupt the attacker's command-and-control channel. While the scan runs, ransomware can continue encrypting local files and propagating to network shares, and advanced malware often uses fileless or polymorphic techniques that evade signature-based scanning. Scanning is best performed after isolation to identify and clean up remnants, not during the initial response when the priority is stopping the threat.

Collect a memory dump from the device

Why wrong: Collecting a memory dump is a forensic step meant to preserve volatile evidence—such as injected code or active network connections—for later analysis, and it does not halt an ongoing attack. Performing an uncontained live acquisition gives the attacker time to finish encryption or exfiltration and may even be detected by the malware, causing it to wipe or disrupt evidence. The correct sequence is to isolate the device first, then collect memory in a stable and safe environment, making this an after-containment activity.

The alert is a false positive due to user travel

Why wrong: A false positive from travel would explain only the location-based anomaly, not the simultaneous mass download of sensitive files. During legitimate travel, users may log in from a new IP or country but do not typically enumerate and download entire document libraries or databases, especially at non-standard times. Sentinel UEBA's 'impossible travel' detection also considers the time differential between two sign-ins, so if the account signed in at the home office and then in a distant country within minutes, even genuine travel cannot account for that. Therefore, the data-exfiltration signal disproves the simple travel false positive.

The user is an insider threat

Why wrong: While insider threat remains a theoretical possibility, the sudden deviation from the user's established behavior—particularly the anomalous geo-location—points more strongly to external credential compromise than to a malicious internal actor. A true insider would more likely operate from a known corporate network, using their own endpoint, and would not need to bypass normal access patterns with a different country source IP. UEBA's baseline includes not just what files the user accesses but also how, when, and from where, so an insider acting on their own account would rarely produce the same impossible-travel signal. Thus, without additional context like motive or a history of grievances, compromise is the higher-probability hypothesis.

The user is conducting a ransomware attack

Why wrong: A ransomware attack typically manifests as a cascade of file encryption operations—renaming files, writing encrypted versions, deleting shadow copies, and dropping a ransom note—not as a single-phase mass download of existing documents. Sentinel UEBA would generate this alert on data access and exfiltration patterns, and ransomware's destructive file modifications would appear as different event types, such as file content changes and deletion of volume shadow snapshots. Moreover, an attacker conducting ransomware would more likely use C2 activity and encryption, whereas this alert's focus on anomalous location and sensitive-data access is characteristic of a data thief using compromised credentials. Therefore, classifying the alert as ransomware is not supported by the described telemetry.

Run an automated playbook to contain the threat

Why wrong: Running an automated playbook to contain the threat immediately after Fusion generates an incident is premature because playbooks are designed to execute after an analyst has triaged the incident and confirmed its validity. Fusion correlates alerts and may produce false positives or incomplete attack narratives, so automating containment without human assessment could disrupt legitimate operations or trigger unrelated remediation. Proper order is triage, then investigate, and only then invoke playbooks for containment or other responses.

Close the incident as false positive

Why wrong: Closing the incident as a false positive without reviewing the accumulated evidence defeats the purpose of Fusion's correlation engine, which uses machine learning to identify genuine multi-stage threats. Even if the initial impression seems benign, the incident may contain underlying alerts or entities that warrant investigation. Closing without triage skips the validation step and could allow an actual attack to proceed undetected, violating standard incident response procedures.

Escalate the incident to senior management

Why wrong: Escalating a Fusion incident directly to senior management without first triaging it is inappropriate because escalation is a communication step that should follow a validated understanding of the incident's severity, impact, and business risk. Skipping triage means the escalation lacks necessary context, often causing unnecessary alarm or being ignored as noise. In a SOC workflow, initial escalation typically goes to a supervisor or incident commander after triage, not directly to senior management.

Create a Conditional Access policy to block the IP

Why wrong: A Conditional Access policy that blocks the attacker's source IP does not revoke the user's existing sessions or refresh tokens, so the attacker's already-authenticated activity continues until tokens expire. The policy only applies at the next interactive sign-in attempt, and might take several minutes to propagate; in an active incident that delay allows continued unauthorized access. If the blocked IP is a cloud VPN or proxy, it can be replaced quickly, and the real threat is the compromised identity, not the egress address.

Disable the user's account

Why wrong: Disabling the user's account is a valid containment action but it is unnecessarily disruptive: the user loses all access to Microsoft 365 and is unable to work while the investigation runs, even if the compromise was limited to a single device or app. It also does not by itself invalidate access tokens that were already issued, so the attacker might continue to use those tokens until they expire unless you also perform a session revocation. In contrast, a password reset plus session revocation is targeted, removes the attacker's credential, and minimizes impact on the legitimate user.

Block the source IP address on the firewall

Why wrong: Firewall IP blocking operates at the network layer and is completely unaware of Entra ID authentication: if the attacker's credentials are valid, they can authenticate from any host, IP, or VPN endpoint. Attackers routinely cycle through proxies, cloud VPSes, or residential IP pools, and the blocked address is simply one egress path among many. Even if the block is applied to a firewall or a protection layer like Microsoft Sentinel, it does nothing to revoke the stolen password, tokens, or the attacker's foothold, so this action cannot be the primary response.

Wait until the device is online and then collect manually

Why wrong: Merely waiting and collecting manually relies on ad-hoc actions like RDP or external utilities, which are slow and inconsistent. Manual collection is error-prone because it depends on the responder to remember every artifact, and it does not automatically preserve a verifiable audit trail. In contrast, live response is a purpose-built, scriptable, and permission-controlled tool, so waiting without leveraging it sacrifices efficiency and forensic rigor.

Run a remotely scheduled antivirus scan

Why wrong: A remotely scheduled antivirus scan is designed to detect and remediate malware, not to capture forensic artifacts for investigation. Scanning actively touches the filesystem, may quarantine or delete malicious files, and can modify metadata such as last-access timestamps, compromising evidentiary integrity. Forensic collection requires passive, preservation-focused methods like live response's 'collect' command, which copy artifacts non-destructively rather than alter system state.

Collect the data from the device's cloud store

Why wrong: Microsoft Defender for Endpoint's cloud store contains only a limited set of telemetry and uploaded alerts, not a complete record of local forensic artifacts. Critical evidence such as full memory dumps, registry hives, or event logs that were never forwarded remain unavailable in the cloud. The cloud store is useful for correlated detections, but it cannot substitute for directly collecting endpoint data via a live response session once the device is online.

Isolate all affected devices from the network

Why wrong: Isolating all affected devices from the network is a strong containment step, but it is disproportionately disruptive in this scenario. If the phishing campaign's only identified artifact is a known malicious file, blocking its hash in Microsoft Defender for Endpoint will prevent the file from running on any device, achieving the same containment goal without severing the user's access to email, intranet, or cloud resources. Isolation also interferes with remote investigation and remediation tasks, since the device may lose connectivity to the APIs needed for EDR telemetry. It is better reserved for situations where the endpoint's behavior is actively malicious and cannot be stopped by a file-level indicator.

Block the sender's IP address on the email gateway

Why wrong: Blocking the sender's IP on the email gateway is ineffective here because the phishing message has already been delivered to the user's mailbox, and the actual threat is the attached file, not the envelope. Attackers routinely forge sender addresses or relay through compromised or cloud-based infrastructure, making a single IP a transient and unreliable indicator. In Microsoft Sentinel, the relevant indicator of compromise is the file hash confirmed by Defender for Endpoint; applying an IP block only prevents future mail from that specific sender while leaving the already-delivered malicious file active. This action does nothing to stop existing copies of the document from executing on recipients' devices.

Disable the user accounts of those who opened the document

Why wrong: Disabling the user accounts of those who opened the document is unnecessary and overly broad in this context because the attack does not compromise credentials or authenticate with the user's identity. Blocking the file hash already neutralizes the payload, so there is no ongoing threat from that mailbox or account; disabling the account would interfere with business operations without adding security value. Account disablement might only be justified if there were signs of credential harvesting or if the document attempted to steal authentication tokens. Without evidence of privilege misuse, the correct remediation is to block the file and run an antivirus scan on the affected devices.

The block duration is set to one day, which is too short

Why wrong: A block duration of one day does not cause a playbook failure. The duration parameter simply controls how long the IP remains on the block list after the action completes; it is validated as a valid time span. While one day might be operationally insufficient for containing a persistent threat, it does not affect whether the playbook runs successfully. The root cause of the failure is not the duration but the incorrect IP extraction.

The playbook actions array has only one action, which is insufficient

Why wrong: Having only one action in the actions array is not a problem. Microsoft Sentinel playbooks, built on Azure Logic Apps, can be as simple as a single connector action, such as an IP-blocking action, and will execute successfully as long as the inputs are valid. The playbook's effectiveness is determined by what that action does and the data it receives, not by the number of actions. Therefore, insufficient action count is not the reason for the failure.

The playbook is using the wrong trigger type; it should be on incident creation

Why wrong: The trigger type is actually correct for this alert-based playbook. Alert-triggered playbooks in Sentinel use the 'When a response to an Azure Sentinel alert is triggered' trigger, which fires immediately when an incident is created from an alert. The incident creation trigger is used for incident-centric automation, not for directly processing alert entities in the same context. Since the playbook is designed to act on individual alert data, the alert trigger is appropriate, and the mistake lies elsewhere in field extraction.

The table name 'SecurityAlert' is incorrect; it should be 'Alert'

Why wrong: `SecurityAlert` is a legitimate table in Log Analytics workspaces that have Microsoft Sentinel enabled; it stores the normalized alert records generated by analytics rules and connected security products. If the table name were invalid, Kusto would return a 'table not found' semantic error and the query would fail, rather than producing a blank result set. Some environments expose `Alert` from other data sources, but that does not make the `SecurityAlert` reference incorrect for this Sentinel query.

The user does not have permission to access the SecurityAlert table

Why wrong: If the user lacked permission to read the SecurityAlert table, the query would terminate with an authorization failure (e.g., Log Analytics 'Access denied' or no table access), not an empty table. Sentinel applies workspace-based Access Control (RBAC) per table; a denial prevents any rows from being returned because the layer denies the operator before scanning. Since the query returns no rows rather than an error, the user's role and workspace permissions are sufficient to query the table.

The time filter of 1 day is too restrictive; need to increase range

Why wrong: Changing the `ago(1d)` filter to a larger window (e.g., 7d or 30d) would modify the search scope, possibly revealing older ransomware-named alerts, but it does not fix an incorrect query or prove the one-day window is wrong. For a specific query intended to check the last 24 hours, the 1-day range is a standard and valid time boundary; a zero result in that window simply means no new matching alerts were created. If the goal was to investigate a longer period, the query should be intentionally rewritten, but that is a different investigation scope, not a mitigation for an error.

The action type 'Block' is incorrect; it should be 'Alert'

Why wrong: 'Block' is indeed a legitimate action type in Microsoft Defender for Cloud Apps policies; you can choose to block access to unsanctioned apps as a governance action. The problem is not the action type itself, but the policy mode being set to 'Monitor', which means the Block action will never be executed—the policy will only generate alerts. Therefore, this statement is incorrect because Block is a valid choice, and the real issue lies elsewhere, specifically in the enforcement mode.

The policy requires a 'Device' filter to apply to all users

Why wrong: A 'Device' filter is not necessary for a cloud app policy that applies to all users. In Defender for Cloud Apps, you can scope a policy by user, group, IP address, or app tags, and if you want it to affect everyone, you simply leave filters empty or use 'All users'. Device filters are more relevant to conditional access or session control policies, not to a straightforward app blocking policy. Hence, this is not a requirement for the policy to work, and it is not the reason the policy fails to block.

The filter uses 'Unsanctioned' tag, but apps are tagged 'Sanctioned'

Why wrong: The filter using the 'Unsanctioned' tag is actually correct if the apps you intend to target are unsanctioned—that is exactly what the tag is designed for. The statement claims the apps are tagged 'Sanctioned', which would contradict the filter, but if the admin is trying to block unsanctioned apps, the filter is appropriate. The mere presence of the 'Unsanctioned' filter is not the problem; the problem is the policy mode. Thus, this option is incorrect because the filter is valid for the intended scope.

Disable the user's account immediately

Why wrong: Disabling the user's account immediately is not appropriate because the account may be legitimate and the exfiltration might be the result of a compromised mailbox or a misconfigured rule, not a malicious insider. Locking the account prematurely can alert the attacker, interrupt business continuity, and destroy the ability to observe the attacker's live activity, which could be crucial for identifying the full scope of the incident and the attack vector.

Delete all sent items from the user's mailbox

Why wrong: Deleting all sent items from the user's mailbox is a destructive action that removes the primary forensic artifacts needed to understand the exfiltration, including recipient addresses, timestamps, subject lines, and the exact content sent. Such deletion constitutes spoliation of evidence, breaks the chain of custody, and can severely hamper legal or disciplinary actions, making it the opposite of a proper incident response step.

Run a full antivirus scan on the user's device

Why wrong: Running a full antivirus scan on the user's device is not directly relevant to email data exfiltration, as the exfiltration occurred through the email channel and the evidence resides in the mailbox and email gateway logs. While malware could be a vector, the immediate priority is to stop the data flow and preserve forensic evidence; a scan might also alter file access times or make system changes that could interfere with later forensic analysis.

Pause the incident for 24 hours before taking action

Why wrong: Pausing an incident for 24 hours is incorrect because it violates the principle of timely response to high-severity alerts; Sentinel incidents are expected to be triaged and acted upon quickly to prevent lateral movement and reduce dwell time. A deliberate delay of 24 hours could allow an attacker to escalate privileges, exfiltrate data, or destroy evidence, and it conflicts with typical SOC SLAs and NIST incident response guidance. There is no standard Sentinel runbook that instructs analysts to 'sleep' on an active incident, so this option is wrong.

Create a new Azure resource for logging

Why wrong: Creating a new Azure resource for logging is not a valid incident response step in Microsoft Sentinel, because the platform already captures relevant logs from existing data sources—such as Azure Activity, Microsoft 365 Defender, and third-party connectors—and you would not add a new resource mid-incident to gather evidence. Doing so would take time, potentially require network changes, and could even generate misleading telemetry that isn't correlated with the incident. Standard response steps focus on investigation, notification, and containment, not provisioning infrastructure, so this is incorrect.

The incident severity must be set to High or Critical

Why wrong: Incident severity is merely a condition that can be used in an automation rule, not a mandatory prerequisite. Automation rules can be configured to run on any severity, including Low or Medium, and severity itself is a dynamic property that might be changed by the rule. Therefore, restricting this to High or Critical is unnecessary and would incorrectly limit the rule's applicability.

The user must be signed in to the Azure portal

Why wrong: The execution of playbooks in Microsoft Sentinel is fully asynchronous and occurs in the background via Azure Logic Apps, independent of any interactive user session. The automation rule engine invokes the Logic App using its own identity or a managed identity, and there is no requirement for a user to be actively signed in to the Azure portal. Requiring an interactive sign-in would break the automation's ability to run unattended.

Use Microsoft Defender XDR to check the user's device timeline for suspicious activity.

Why wrong: The Microsoft Defender XDR device timeline is an endpoint-centric view that records process, file, and network activity on a specific device, not authentication events that originate from an external IP. A suspicious sign-in may involve the user's credentials but occur before any device becomes involved, so the timeline could be empty or irrelevant. Additionally, device timeline lacks identity-level details like authentication result, MFA state, or conditional access evaluation, making it unsuitable for confirming a sign-in anomaly.

Run a KQL query in Microsoft Sentinel to check Microsoft Defender for Cloud Apps alerts for the user.

Why wrong: Microsoft Defender for Cloud Apps alerts are generated from behavioral heuristics and app-visibility policies, meaning they only exist if a custom or built-in policy triggered for the user. They do not contain raw sign-in success/failure records or the full set of authentication properties such as the exact timestamp, IP address, and MFA status. Checking these alerts might surface correlated activity but cannot be relied on to establish whether the specific suspicious sign-in was successful.

Check the firewall logs in Azure Firewall for outbound connections from the user's IP.

Why wrong: Azure Firewall logs record network-level allow or deny decisions for flows passing through the firewall, such as source and destination IPs and ports, but they contain no application-layer identity information. A sign-in event is an authentication against Microsoft Entra ID over TLS, so the firewall sees only encrypted connection metadata and cannot determine whether the sign-in succeeded or failed. Therefore, firewall logs are useless for validating a credential-based alert.

Enable Safe Attachments for the organization.

Why wrong: Safe Attachments handles malicious attachments, not phishing content.

Configure impersonation protection for the user's domain.

Why wrong: Impersonation protection is for CEO fraud, not general phishing emails.

Create a mail flow rule to block the sender's domain.

Why wrong: Mail flow rules are transport rules; anti-phishing settings are in the policy.

DeviceNetworkEvents | where RemoteUrl contains 'malicious' | project DeviceName, RemoteIP, Timestamp

Why wrong: This query returns only network connection records where the remote URL string contains 'malicious'; it does not include process creation telemetry, so it cannot identify the parent process that spawned the ransomware or the command line that executed it. Network events may show outbound beaconing to a command-and-control server after infection, but they are not the initial infection vector and miss the local execution chain entirely. Relying on a URL substring filter is also fragile because ransomware often uses IP addresses, legitimately hosted domains, or encrypted DNS, making this approach blind to the actual detonation point.

DeviceFileEvents | where FileName contains 'ransomware.exe' | project DeviceName, ActionType, Timestamp

Why wrong: DeviceFileEvents captures file-system actions such as creation, modification, or deletion, but the schema for this table does not include the parent-process relationship that is essential for tracing a ransomware infection. Seeing a file named 'ransomware.exe' does not prove that it was ever executed, nor does it reveal whether it was dropped by a macro, a PowerShell script, a remote SMB copy, or an exploit delivery. The ActionType column only indicates the file operation that occurred, not the initiating process executable or its command-line arguments, so the true infection path remains hidden and the query cannot support root-cause analysis.

DeviceEvents | where ActionType == 'RansomwareDetection' | project DeviceName, Timestamp

Why wrong: Filtering DeviceEvents by ActionType == 'RansomwareDetection' returns detection alerts that security products have already correlated, but these are not raw process telemetry. Such events may confirm that ransomware was detected on the device, yet they do not expose the parent process, the child process command line, or other forensic details needed to identify the attack's entry point and scope. Because this query projects only DeviceName and Timestamp, any process-lineage or threat-intel columns are discarded, leaving the team without actionable information about the process tree that led to the ransomware execution.

Only the first alert creates an incident; subsequent alerts are ignored.

Why wrong: This is incorrect because alert grouping in the rule is enabled, and the lookback duration defines how far back existing incidents are searched to group new alerts. When a subsequent alert fires within that window and matches the grouping criteria, it is attached to the already-created incident, not ignored. Thus, subsequent alerts are not dropped; they are aggregated into the same incident, maintaining a complete context.

Each alert creates a separate incident.

Why wrong: This option contradicts the configured alert grouping behavior, which consolidates matching alerts. With grouping enabled and entity-based matching, all alerts that have identical entity values are merged into a single incident instead of spawning separate ones. Separate incidents per alert would only occur if the rule had grouping disabled, which is not the case here.

Alerts are suppressed for 5 minutes after the first alert.

Why wrong: This is a misunderstanding of incident suppression versus grouping. The rule's suppression configuration is disabled, so there is no 5-minute quiet period after an alert fires; each qualifying alert is processed according to the grouping rules. Suppression would only be relevant if a duration was set in the rule's 'Suppression' section, which it is not, so alerts continue to be evaluated and grouped normally.

UEBA is enabled, which conflicts with Defender for Cloud data ingestion.

Why wrong: UEBA in Microsoft Sentinel is an analytics feature that uses entity behavior and baseline profiling to detect anomalies, and it does not modify or block the ingestion pipelines of any data connectors. The Defender for Cloud connector (Azure Security Center) delivers alerts through the Log Analytics workspace independently, and enabling UEBA simply adds data on top of existing ingested logs. Therefore, UEBA and Defender for Cloud data ingestion can coexist without conflict, making this option incorrect.

The workspace location (eastus) does not support Defender for Cloud connector.

Why wrong: Microsoft Sentinel is supported in the eastus region, and the Defender for Cloud (Azure Security Center) connector is available in all Azure public regions where Sentinel is offered. Workspace location does not affect the capability to connect Defender for Cloud; the connector relies on the Azure Security Center service itself, which is a regional PaaS service with broad regional coverage. Thus, the eastus location fully supports this connector, so this option is not the reason for the missing Defender for Cloud alerts.

The workspace name 'sentinel-workspace' is reserved for internal use.

Why wrong: Log Analytics workspace names in Azure are arbitrary user-defined strings, and there is no reserved name like 'sentinel-workspace' that would restrict its use. The name only needs to be globally unique within the resource group and follow Azure naming conventions; it has no bearing on connector configuration or data ingestion behavior. Since 'sentinel-workspace' is a valid and unrestricted name, this option is not a plausible cause for the missing Defender for Cloud alerts.