Select Two (Multi-Select) Questions

The analyst's mood

Why it fails: An analyst's mood is subjective and unrelated to incident impact, so it cannot inform severity, which derives from business impact, data or system criticality, and scope of compromise. It is tempting because analyst judgement matters in triage, and would be correct when assessing confidence in an alert rather than its severity.

The day of the week

Why it fails: Incident severity derives from technical impact, scope and data sensitivity, not calendar position; a Sunday breach is no less severe than a Tuesday one. It is tempting because staffing and on-call coverage genuinely vary by day, so rota planning may reference the weekday, but that affects response logistics rather than the severity rating itself.

The email is sent during business hours

Why it fails: Business-hours delivery is normal for legitimate corporate mail, so timing alone does not indicate phishing. It is tempting because attackers often schedule sends to blend in, but that makes it weak corroboration rather than a reliable indicator; analysts should instead flag mismatched sender domains or urgent credential requests.

The email has a subject line

Why it fails: Nearly all email, legitimate or malicious, carries a subject line, so its presence discriminates nothing. It is tempting because phishing subjects often use urgency or odd phrasing, but the indicator is that content, not the mere existence of a subject; analysts should examine sender authentication and embedded links instead.

The email is from the CEO

Why it fails: CEO emails are common, check headers instead.

The number of coffee machines in the SOC

Why it fails: Coffee machines are office amenities with no bearing on attacker persistence or detection latency. The option tempts as a flippant nod to SOC culture, but dwell time depends on monitoring coverage, alert triage, and threat-hunting maturity. Physical appliances would only matter for facilities or power planning.

The speed of the network

Why it fails: Network speed affects how quickly data traverses links, not how long an attacker remains undetected inside the environment. Dwell time is driven by detection capability, visibility, and response processes. Fast networks would matter for throughput or latency questions, not for measuring intrusion persistence.

Upgrade the VM's OS image

Why it fails: Upgrading the OS image patches the guest but leaves the rogue instance running, reachable and still under attacker control. Image upgrades address vulnerability remediation on sanctioned systems; containment of an unauthorised VM demands isolation or termination, not a version change.

Increase the VM's CPU quota

Why it fails: Raising CPU quota grants the rogue VM more compute resources, worsening the exposure rather than containing it. Quota adjustments belong to legitimate capacity planning for approved workloads, so this would only be the right action when a sanctioned instance is genuinely starved of vCPU.

Delete the VM immediately

Why it fails: Deleting destroys evidence before it can be analyzed.

Automating the deletion of all logs after 24 hours.

Why it fails: Purging logs after 24 hours destroys the historical baseline that use case tuning and threat hunting rely on, so it undermines the development process rather than forming part of it. Short retention is a legitimate choice only where regulation or storage constraints explicitly demand it.

Disabling all firewall logging to save disk space.

Why it fails: Firewall logs are a primary SIEM correlation source; disabling them removes the telemetry use cases depend on, so detections cannot fire. It is tempting when storage costs or licence ingestion volumes bite, and the legitimate fix is filtering noisy events or tuning retention, not eliminating the source entirely.

Assigning the development task to the marketing team.

Why it fails: Marketing staff lack the security monitoring, log source and detection engineering expertise that use case development demands, so requirements and tuning would be misdirected. It is tempting because cross-team collaboration and business context do matter, but that means consulting stakeholders on risk priorities, not handing the build to a non-security function.

A user-mode process with a single thread that is currently in a wait state

Why it fails: A single waiting thread is entirely normal for many idle or background processes and carries no injection significance. Wait states occur constantly during normal scheduling. Without evidence of anomalous memory permissions or orphaned thread start addresses, this observation does not indicate that malicious code was injected.

A signed Microsoft DLL loaded at its expected base address

Why it fails: A legitimately signed system DLL loaded at its expected location is normal behavior and provides no evidence of injection. Attackers may target such modules for hollowing, but the mere presence of a correctly loaded signed DLL is expected on every Windows host and therefore is not an indicator by itself.

A process with a high handle count and many open Registry keys

Why it fails: High handle counts and numerous open Registry keys can reflect normal application behavior, such as services or browsers, and are not specific to code injection. While unusual handle patterns may warrant a look, they do not directly demonstrate that foreign code was written into a process, so they are weak and non-specific for this purpose.

A sudden increase in outbound DNS queries to a newly registered domain

Why it fails: This is a network-based IoC observed in DNS logs or network traffic, not a host artifact. While it can indicate compromise, the question asks for host-based IoCs, and DNS query volume is collected from network sensors or DNS servers rather than the endpoint's local state.

A spike in SMTP traffic from an internal mail server to an external IP

Why it fails: This is a network-based IoC observed in mail flow or firewall logs, not on the endpoint itself. It may suggest a compromised mail server, but it does not represent a host-based artifact such as a malicious file or registry change on a specific workstation.

Anomalous TLS certificate presented by an external server during a connection

Why it fails: This is a network-based IoC derived from inspecting TLS traffic or certificates, not a host artifact. While it can indicate malicious infrastructure, it is observed on the network and does not directly describe endpoint state such as files, registry, or processes.

A service account being added to the Domain Admins group.

Why it fails: Adding a service account to Domain Admins is a privilege escalation technique, but it is not part of Kerberoasting. Kerberoasting aims to crack service account passwords offline; it does not require group membership changes. Alerting on this would detect a different attack and fail to identify Kerberoasting activity, leading to missed detections.

Event ID 4771 for Kerberos pre-authentication failures from a single source.

Why it fails: Event ID 4771 indicates failed Kerberos pre-authentication, often associated with password spraying or brute-force attempts. Kerberoasting does not cause pre-authentication failures; it succeeds after valid authentication. Therefore, this event is not relevant to detecting Kerberoasting and would misdirect the analyst toward credential-guessing attacks instead.

Event ID 4624 logon type 3 (network) from a workstation to a domain controller.

Why it fails: Network logons to domain controllers are common in normal operations, such as file shares and authentication. While unusual sources might warrant investigation, this event alone is not specific to Kerberoasting. The attack occurs after authentication, during ticket requests, so focusing on logon events would generate excessive false positives and miss the core behavior.

The color of the hardware chassis

Why it fails: Chassis colour has no bearing on retention; the drivers are regulatory mandates, data classification, and storage cost. It is tempting because physical asset attributes matter for inventory and maintenance planning, so it would be a legitimate consideration in a hardware lifecycle or procurement decision.

The time of day the backup is scheduled

Why it fails: Backup scheduling affects operational windows, not how long logs must be kept; retention is set by compliance requirements, investigation needs, and storage capacity. It is tempting because timing genuinely matters when planning backup jobs to avoid contention, which is a separate operational decision.

System memory dumps

Why it fails: Memory dumps capture volatile running state for malware and credential analysis, not the durable configuration that survives reboot, so they do not evidence persistence mechanisms. They are tempting because injected code can reside in memory, and would be correct when hunting fileless malware active in a live session.

Event log files

Why it fails: Event logs record activity such as logons and service installs, but persistence is established by durable artefacts like Run keys, scheduled tasks and services, which logs merely reference. They are tempting because they reveal attacker behaviour, and would be correct for building a timeline of actions rather than identifying persistence.

Run an antivirus scan on the reporting user's workstation.

Why it fails: Running an antivirus scan on the reporting user's workstation is a containment or remediation step for that specific user, but it does not help identify other users who received the same email. The goal is to determine scope across the organization, not just address the initial report.

Interview the reporting user to ask who else might have received the email.

Why it fails: Interviewing the reporting user can provide anecdotal information, but it is not a reliable method to determine the full scope. Users may not know all recipients, and relying on memory is inefficient. Technical logs provide more accurate and comprehensive data for scoping.

Reset the password for the reporting user's account.

Why it fails: Resetting the password for the reporting user is a remediation action that may be needed if compromise is suspected, but it does not help identify other users who received the phishing email. It addresses only one potential victim and does not contribute to scoping the incident.

The SIEM is too colorful.

Why it fails: UI aesthetics are not a challenge.

The SIEM is too small to fit in a rack.

Why it fails: Physical rack dimensions are irrelevant to correlation rule development; the challenges are logical, such as rule overlap, false positives and tuning. It tempts candidates because SIEM appliances are hardware, so sizing appears plausible, but capacity planning concerns log ingestion volume and EPS, not rack units.

Number of emails sent to stakeholders

Why it fails: Counting stakeholder emails measures communication volume, not incident response efficiency; it ignores containment time, mean time to resolve and detection accuracy. It is tempting because stakeholder notification is a genuine incident-handling activity, and email counts would suit auditing communication coverage or compliance reporting rather than evaluating how quickly and effectively a team resolves incidents.

Average salary of analysts

Why it fails: Average salary of analysts measures staffing cost, not incident response performance; it cannot quantify detection speed, containment time or resolution effectiveness. It is tempting because cost-per-analyst informs budget planning and headcount decisions, where it would legitimately support workforce forecasting. Here, the question demands operational efficiency metrics such as MTTD and MTTR.

Building security badge access logs

Why it fails: Badge access logs record physical entry events, not incident response activity, so they cannot measure team efficiency. They are tempting because physical access auditing supports facility security investigations, where correlating badge data with intrusions would be the correct choice.

Adding the attacker on social media

Why it fails: Contacting the attacker on social media is an investigation or attribution activity, not containment or removal of malicious code. Eradication focuses on eliminating malware, disabling compromised accounts and closing the initial access vector; engaging the adversary risks tipping them off and has no place in remediation.

Deleting the entire server

Why it fails: Wiping the entire server destroys forensic evidence and may remove unaffected services unnecessarily. Eradication means removing malware, patching the exploited vulnerability and resetting compromised credentials; rebuilding is reserved for cases where the host cannot be trusted after full forensic capture.

HKLM\System\CurrentControlSet\Control\Nls\Language

Why it fails: This key stores language and locale configuration for the National Language Support subsystem, which malware does not abuse for persistence. It is a legitimate configuration location, whereas persistence hunting targets autostart keys such as Run, RunOnce and Services.

HKLM\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes

Why it fails: FontSubstitutes maps font names for rendering and is not an autostart mechanism, so nothing here executes at logon or boot. It is a benign configuration key; persistence hunting instead covers keys that launch code, such as Run and Winlogon.

NetFlow records showing outbound traffic volume from the endpoint

Why it fails: NetFlow captures network flow metadata, not endpoint process behavior. Credential dumping can occur entirely locally without generating distinctive network traffic, and outbound volume alone cannot distinguish dumping from normal activity. While NetFlow is valuable for detecting data exfiltration after credential theft, it does not provide the process-level visibility needed to reliably detect the dumping action itself.

DHCP logs showing IP address leases for the endpoint

Why it fails: DHCP logs map IP addresses to MAC addresses and lease times, which can help identify a host during investigation but offer no visibility into credential dumping behavior. They do not record process execution, memory access, or authentication events. Relying on DHCP logs for this use case would produce no meaningful detection signal and would not contribute to reducing false positives for credential dumping.

Email gateway logs showing inbound messages with attachments

Why it fails: Email gateway logs are relevant to initial access via phishing but not to credential dumping, which occurs after an attacker has code execution on a host. They cannot observe LSASS access or process creation on the endpoint. Including email logs in this use case would add noise without improving detection fidelity for the specific behavior of dumping credentials from memory.

Immediately block the suspicious IP address at the perimeter firewall.

Why it fails: Blocking the IP is a containment action, not an evidence-gathering step. While it may stop ongoing exfiltration, it could also alert the attacker and destroy valuable evidence. The question asks for actions to determine if the alert is a true positive; blocking prematurely without confirmation could disrupt business or tip off the adversary. Evidence gathering should precede containment unless there is an immediate, severe risk.

Review the user's recent email activity for signs of phishing.

Why it fails: While phishing could be an initial vector, it does not directly confirm whether the outbound traffic is malicious. Email review might provide context but is not the most immediate action to validate the alert. The suspicious IP and outbound traffic are network-level indicators; endpoint and firewall data are more directly relevant to determining if data exfiltration occurred. Email analysis is secondary and may not yield timely evidence.

Run a full antivirus scan on the affected endpoint.

Why it fails: A full antivirus scan may detect known malware but is not targeted for investigating specific outbound traffic. It could take hours and may not provide immediate context about the connection. Advanced threats often evade signature-based detection. The goal is to correlate the specific alert with endpoint and network data, not to perform a broad scan that might miss the actual exfiltration mechanism.

Resource Provisioning

Why it fails: Resource provisioning is a deployment and scaling activity, not an incident response component; cloud-native response instead relies on identity isolation, snapshotting and log preservation. It is tempting because provisioning is central to cloud operations, and would be correct when designing auto-scaling or infrastructure-as-code pipelines rather than a response plan.

Budget Optimization

Why it fails: Budget optimisation addresses cost governance, not containment, eradication or recovery of a cloud incident. It is tempting because cloud-native plans do reference cost controls, and would be correct when the scenario asks about FinOps or spend management rather than incident response components.

Hardware Refresh

Why it fails: Hardware refresh concerns physical infrastructure, which cloud-native response plans do not manage; the cloud provider handles host replacement. It is tempting because on-premises incident response often includes hardware replacement after compromise, making it the correct choice only for traditional data-centre environments, not cloud-native plans.

The color of the hard drive casing

Why it fails: Hard drive casing colour has no bearing on evidence integrity or custody transfer, so recording it documents nothing about who handled the drive, when, or how it was secured. It is tempting because physical descriptions can help identify exhibits, but that is asset labelling, not the chronological custody record the scenario requires.

The CPU manufacturer

Why it fails: CPU manufacturer describes server hardware specification, not the movement or control of evidence, so it cannot evidence an unbroken custody chain. It is tempting because hardware inventories are routinely logged during incident response, but that serves asset management, not documenting who seized, transferred, and stored the forensic image.

The system temperature at the time

Why it fails: Ambient temperature has no bearing on evidence integrity or transfer, so it is irrelevant to chain-of-custody records. Documenting environmental conditions would matter for physical evidence storage or media degradation studies, not for logging who handled a server image and when.

Ignore the alert without closure

Why it fails: Leaving an alert unclosed breaks the triage workflow, so the false-positive determination is never recorded and detection tuning never occurs. It is tempting when analysts are overwhelmed by volume, but proper handling requires documenting the classification and closing the alert, feeding the result back into rule refinement.

Delete the original event log

Why it fails: Deleting the original event log destroys the audit evidence needed to justify the false-positive classification and to tune the rule. It is tempting as apparent cleanup, but retention and integrity requirements mean analysts document and close the alert, adjusting detection logic instead of erasing the underlying event.

Request a new SIEM license

Why it fails: Licensing governs ingestion volume and retention, not alert triage, so it cannot resolve a false positive. It is tempting because SIEM cost and data limits are real operational concerns, but procuring licences is a capacity-planning task, whereas reviewing a false positive requires tuning the detection rule or correlation logic.