Security Operations And Management practice questions

Tactical threat intelligence

Why it fails: Tactical threat intelligence involves specific indicators of compromise (IOCs) such as IP addresses, domains, and file hashes. It is closer to what the analyst needs, but the term often refers to the collection and sharing of IOCs. However, the most direct and commonly used feed for IP reputation is a threat intelligence platform that aggregates tactical data. Among the options, tactical is not the best fit because it is a broader category, and the scenario asks for the first feed to consult for reputation.

Strategic threat intelligence

Why it fails: Strategic threat intelligence provides high-level, long-term insights about threat actors and geopolitical trends, not real-time IP reputation. It is used for executive decision-making and planning, not for immediate alert triage. In this scenario, the analyst needs actionable, technical data about a specific IP, so strategic intelligence would not provide the quick assessment required.

Operational threat intelligence

Why it fails: Operational threat intelligence focuses on details of specific attacks, including tools, techniques, and procedures (TTPs) used by threat actors. While it can help understand an attacker's methods, it does not typically provide a simple reputation score for an IP address. The analyst needs immediate, actionable data to decide whether to escalate, so operational intelligence is less suitable here.

Active Directory authentication logs

Why it fails: Active Directory logs record authentication events, such as logons and logoffs, but do not show what the user did after logging in. They are useful for detecting anomalous login patterns but insufficient for building a detailed timeline of file access, application usage, or data transfers. Thus, they are not the priority for this scenario.

VPN logs

Why it fails: VPN logs show remote access sessions, including login times and source IPs, but they do not capture user actions on endpoints or data transfers. While useful for establishing when a user connected, they lack the granularity needed to build a comprehensive timeline of activities like file access or exfiltration. Therefore, they are not the top priority for this correlation.

DLP alerts

Why it fails: DLP alerts indicate potential policy violations related to data movement, such as attempts to email sensitive files. They are valuable for identifying exfiltration attempts but only capture specific events, not the full sequence of user activity leading up to them. They are reactive and lack the breadth of EDR telemetry, so they should not be the primary source for timeline reconstruction.

Incident Responder

Why it fails: Incident Responders handle containment, eradication and recovery once an alert fires; they do not own correlation-rule tuning or platform health. The role is tempting because responders feed tuning feedback and often adjust rules ad hoc during investigations, but in a mature SOC that ownership sits with the SIEM Engineer or Detection Engineer.

Compliance Officer

Why it fails: A Compliance Officer maps controls to regulatory frameworks and evidences adherence; they do not author or tune correlation rules or monitor SIEM parser and index health. The role tempts because compliance depends on SIEM reporting, but rule tuning and platform health sit with the SOC engineering and analyst functions.

SOC Manager

Why it fails: The SOC Manager owns staffing, escalation paths, metrics and stakeholder reporting, delegating rule tuning and platform health to analysts and engineers. The role tempts because the manager is accountable for SOC performance, but hands-on correlation-rule maintenance and SIEM health checks are operational engineering duties, not managerial ones.

Event Parser Configuration

Why it fails: Event parser configuration extracts and normalises fields from raw log data; it does not control alert triggering frequency or timing. The threshold count and time window parameters define the five-events-in-60-seconds condition. Parsers are correctly adjusted when log fields are misread or unparsed, not for noise reduction thresholds.

Aggregation Key

Why it fails: The aggregation key groups events sharing a field value; it does not define the count or time window. The threshold count and time window parameters set the five-events-in-60-seconds rule. Aggregation keys are used to correlate related events, such as grouping by source IP, not to set trigger frequency.

Suppression Window

Why it fails: A suppression window silences duplicate alerts after one fires; it does not define how many events within a time period constitute a trigger. It is tempting because it reduces alert noise, and would be correct for preventing repeated notifications from a single recurring event rather than setting the detection frequency.

Reset all user passwords

Why it fails: Bulk password resets disrupt every account without first scoping which credentials were compromised, and they do not stop active sessions or malware already resident. Resetting passwords is tempting because credential compromise is common, but it is a targeted remediation step, not the opening containment action.

Perform full forensic imaging

Why it fails: Forensic imaging preserves evidence but does not stop the threat, so it cannot precede containment actions such as isolating affected hosts. It is tempting because imaging is a standard incident-response step, and it would be correct during the later investigation or eradication phase once containment is already achieved.

Update the firewall rule base

Why it fails: Firewall rules block specific network traffic, but containment begins by isolating the affected host or account so the threat cannot spread or persist. Updating the rule base is tempting because firewalls do restrict lateral movement, yet that step belongs later, once the compromised asset has been scoped and isolated.

Virtual SOC

Why it fails: A Virtual SOC is an outsourced monitoring arrangement, but it does not inherently preserve the organisation's internal control over detection and response decisions. It is tempting because it involves a third-party provider, yet the retained-control element in the stem points to a co-managed or hybrid model instead.

Internal SOC

Why it fails: An Internal SOC keeps monitoring staffed and operated in-house, so nothing is outsourced to a third party. It is tempting because the organisation retains full control, which the stem mentions, but the outsourcing requirement is unmet; the correct model combines external monitoring with retained control.

Hybrid Cloud SOC

Why it fails: Hybrid Cloud SOC describes monitoring spanning on-premises and cloud infrastructure, not an outsourcing arrangement with retained internal control. It is tempting because it blends internal and external elements, but the axis of difference is deployment location, not who operates the monitoring service.

MTTR

Why it fails: MTTR measures total time from detection to full resolution, aggregating every phase, so it cannot isolate the detection-to-assignment gap. It is tempting because it is the headline SOC efficiency metric, but it would be the right choice when reporting overall incident recovery performance.

False Positive Rate

Why it fails: False positive rate measures the proportion of alerts that are benign, indicating detection quality, not the elapsed time between alert generation and analyst assignment. It is tempting because noisy alerts can slow triage, but it would be correct when tuning detection rules to reduce alert fatigue.

Dwell Time

Why it fails: Dwell time measures how long an attacker remains undetected inside the environment, a threat-hunting metric unrelated to analyst queueing. It is tempting because it sounds like a delay measurement, but it would be correct when assessing detection coverage gaps rather than escalation workflow bottlenecks.

Level 5

Why it fails: Level 5 requires continuous process optimisation driven by quantitative feedback and innovation, which the stem never describes. It is tempting as the aspirational target of a maturity assessment, but documented standard processes without automation sit far below the optimising level.

Level 2

Why it fails: Level 2 requires processes managed at the project level with defined, planned and monitored execution, not organisation-wide documented standards. It is tempting because it is the next step above ad hoc, but the stem's documented standard processes already satisfy the defined level.

Level 1

Why it fails: Level 1 describes performed-but-ad-hoc activity with no documented standard processes, whereas the stem states processes are documented and standardised. It is tempting because the missing automation suggests immaturity, but documentation of standard processes already lifts the SOC above the initial level.

Tier 3

Why it fails: Tier 3 covers advanced threat hunting, malware analysis and forensic investigation, not basic alert filtering. It is tempting because Tier 3 analysts do examine incidents, but only after Tier 1 triage and Tier 2 escalation have already occurred.

SOC Manager

Why it fails: The SOC Manager owns staffing, processes and reporting rather than handling alerts, so no triage occurs in that role. It is tempting because managers do oversee the queue and escalate resourcing, but Tier 1 analysts perform the initial filtering and classification.

Tier 2

Why it fails: Tier 2 handles deeper investigation and escalation of incidents already triaged, not the first-pass filtering. It is tempting because Tier 2 analysts review alerts, yet the stem asks for initial triage, which Tier 1 performs before escalation.

Purchasing a new SIEM license

Why it fails: A new SIEM licence adds tooling capacity, but Follow-the-Sun depends on documented handover procedures and shared case visibility across regions. Licensing does not create the operational continuity the model requires. Purchasing a SIEM licence would be correct when the constraint is ingestion volume or feature limits, not shift coverage.

Moving all logs to the cloud

Why it fails: Follow-the-Sun continuity depends on handing off live investigations between regions, which requires shared, real-time visibility of alerts and cases. Centralising logs in the cloud may support that, but log storage alone does not deliver the handover process. Cloud log aggregation is correct when the goal is retention or correlation, not shift handover.

Increasing the number of Tier 3 analysts

Why it fails: Follow-the-Sun success rests on consistent processes and handover between regional teams, not on headcount of senior analysts. Adding Tier 3 staff increases escalation capacity but does nothing to transfer context across time zones. More Tier 3 analysts would be the right answer if the problem were escalation backlog, not round-the-clock coverage.

Hardening server images

Why it fails: Hardening server images is a vulnerability-management and systems-engineering task, applying CIS benchmarks and patch baselines to builds. It is tempting because threat intelligence informs which vulnerabilities matter, but the analyst consumes and distributes that intelligence rather than implementing host configuration changes.

Managing SOC budget

Why it fails: Budget management is a SOC managerial function covering tooling spend, staffing and licences. It is tempting because intelligence platforms carry subscription costs the analyst may influence, but the role itself produces finished intelligence on adversaries, not financial planning or resource allocation.

Writing compliance reports

Why it fails: Compliance reporting documents control adherence for auditors and regulators, producing no adversary context for detection or hunting. It is tempting because Threat Intelligence outputs do feed risk and audit narratives, so the artefact overlaps, but the analyst's core duty is collecting, enriching and disseminating threat data.

Timestamp

Why it fails: Timestamps order events but do not identify a person, so they cannot link one user's activity across platforms. They are essential for sequencing and time-window correlation, which is a different requirement from attributing activity to a single identity.

Device Name

Why it fails: Device Name identifies a host, not a person, so it cannot link one user's sessions across multiple endpoints. It is tempting because host-based correlation is valid when tracking lateral movement or malware propagation from a single compromised machine, where the device itself is the pivot rather than the account.

Source IP

Why it fails: Source IP identifies a device or network location, not a person; NAT, DHCP leases and shared hosts break attribution when one user moves between machines. It is tempting because IP correlation works well for tracing a single compromised endpoint's traffic, but the stem requires following one user across platforms, which needs a user identity field.

Identifying the source

Why it fails: Identifying the source belongs to detection and analysis, where scoping determines which hosts and accounts are compromised. Eradication removes the root cause — malware, persistence mechanisms, vulnerable software — from affected systems. Source identification is the tempting answer because it precedes eradication, but it produces no removal action itself.

Blocking traffic

Why it fails: Blocking traffic is containment: it stops the spread or limits attacker access while investigation continues. Eradication instead removes the malicious artefacts and closes the vulnerability that permitted the intrusion. Blocking is tempting because it feels decisive, yet it leaves the implant or backdoor in place, so the attacker can return once the block is lifted.

Restoring backups

Why it fails: Restoring backups is recovery, returning systems to normal operation after the threat has been removed. Eradication eliminates the root cause first; restoring beforehand can reinstate compromised data or the very vulnerability exploited. Recovery is tempting because it visibly resolves the outage, but it does not address the attacker's foothold.

SOC Manager and IT Support

Why it fails: IT Support handles endpoint, account and infrastructure tickets, not threat detection. The SOC Manager needs proximity to detection and response roles to direct incident handling, not to break-fix queues. Seating them together suits an IT service desk escalation model, where the manager owns ticket throughput rather than security monitoring.

Tier 1 Analyst and Compliance Officer

Why it fails: Tier 1 triage and compliance auditing operate on different cadences: compliance reviews policies and evidence retrospectively, not live alerts. Proximity yields no shared real-time intelligence. Compliance Officers sit with governance or legal functions; co-locating them with Tier 1 would be chosen only where regulatory reporting directly consumes triage data.

SOC Manager and HR

Why it fails: HR manages personnel matters, recruitment and employee relations, none of which consume live security telemetry. The SOC Manager requires adjacency to analysts and incident responders for escalation decisions. Pairing with HR would fit a disciplinary or workforce-planning context, not real-time intelligence sharing during active incidents.

Physical security building permits

Why it fails: Building permits govern facility access and construction compliance, not incident detection, containment or recovery. Physical security controls belong in a broader security programme; an incident response plan instead needs roles, escalation paths, communication procedures and containment, eradication and recovery steps.

List of office vacation days

Why it fails: Office vacation days are an HR scheduling matter with no bearing on detecting, containing or recovering from incidents. It is tempting because analyst availability affects response, but staffing is handled through on-call rosters; the plan itself requires defined roles, escalation criteria and response procedures.

Number of social media followers

Why it fails: Social media followers have no causal link to SOC cost avoidance or alert-handling savings, so they cannot enter an ROI calculation. Follower counts belong to marketing or brand-awareness metrics, where audience reach genuinely drives campaign valuation.

Office space square footage

Why it fails: Office square footage is a fixed facilities cost, not a driver of SOC detection, response or loss reduction, so it cannot anchor ROI. It would be relevant when costing physical expansion or lease decisions, not security-operations return.

Number of coffee machines in the SOC

Why it fails: Coffee machines are an amenities expense with no measurable relationship to SOC incident costs or analyst productivity outputs, so they cannot feed an ROI formula. Such counts belong to workplace-satisfaction surveys, where staff-perk provision is genuinely assessed.

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.

Removing the SOC Tier 1 analysts

Why it fails: Removing Tier 1 analysts eliminates the triage layer that filters false positives, so unfiltered alerts reach higher tiers and fatigue rises. It is tempting as a headcount saving, and reducing Tier 1 would be correct only where automation has already absorbed their triage function.

Increasing the volume of log ingestion

Why it fails: Ingesting more logs increases alert volume and noise, worsening fatigue rather than improving quality. It is tempting because broader telemetry feels like better visibility, and higher ingestion would be correct when detection coverage has genuine blind spots, not when the goal is reducing analyst alert load.

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.

Business Continuity Plan (BCP)

Why it fails: A BCP focuses on maintaining critical business functions during and after a major disruption. It is not concerned with the tactical, internal escalation steps for a security incident. The manager's requirement is for an operational security procedure, not a business continuity strategy.

Incident Response Plan (IRP)

Why it fails: The IRP is a high-level document that defines the overall approach, roles, and phases for handling incidents. While it may reference escalation paths, the detailed step-by-step notification sequence and specific responsibilities for each tier are typically captured in a more granular operational document, not the overarching plan itself.

Service Level Agreement (SLA)

Why it fails: An SLA is a contract that defines the expected level of service, such as response times. It does not describe internal workflows or the sequence of notifications between team members. Updating an SLA would not address the manager's need to document the escalation process.