Data Analysis practice questions

$75,000

Why it fails: Incorrect math.

$100,000

Why it fails: This is the original ALE.

$25,000

Why it fails: Incorrect calculation of probability reduction.

Consolidate the contradictory evidence into the supporting evidence category.

Why it fails: Mixing evidence types obscures the diagnostic value.

Discard the hypothesis immediately if any contradictory evidence exists.

Why it fails: ACH requires analyzing the diagnostic value of the evidence, not immediate dismissal.

Increase the weight of supporting evidence to balance the matrix.

Why it fails: Weighting supporting evidence leads to confirmation bias.

Identify the primary adversary.

Why it fails: This is part of the process, but not the starting point.

Gather all relevant evidence logs.

Why it fails: Evidence gathering occurs after defining the scope and hypotheses.

Clearly define the problem or research question to be answered.

Why it fails: Without a clear objective, the ACH process lacks focus.

Threat Vector Analysis

Why it fails: Vector analysis identifies paths, it does not necessarily reduce them.

Risk Likelihood Assessment

Why it fails: This measures probability, not surface area.

Threat Actor Attribution

Why it fails: Attribution focuses on the who, not the how/surface.

Reconnaissance

Why it fails: Recon is the gathering of information prior to the attack.

Weaponization

Why it fails: Weaponization is the creation of the malware/payload.

Installation

Why it fails: Installation follows exploitation.

Employee performance ratings.

Why it fails: Irrelevant to threat impact.

Total cost of the organization's office space.

Why it fails: Irrelevant to breach impact.

Domain generation algorithm (DGA) with a domain flux

Why it fails: Domain flux involves rapidly changing DNS records for a single domain to multiple IP addresses, often using a DGA to generate subdomains. In this scenario, the queries are for different second-level domains, not subdomains of a single domain. The pattern of many NXDOMAIN responses and one successful resolution is more consistent with a DGA that generates many domains and the attacker registers only one for command and control.

Fast flux DNS

Why it fails: Fast flux DNS involves rapidly changing the IP addresses associated with a single domain name, often using a network of compromised hosts as proxies. The scenario describes queries for multiple different domain names, not a single domain with changing IPs. Fast flux would show a single domain resolving to many IPs in quick succession, whereas here we see many domains with mostly NXDOMAIN responses, indicating a different technique.

DNS tunneling

Why it fails: DNS tunneling involves encoding data within DNS queries and responses to exfiltrate information or establish a covert channel. While it uses DNS, the scenario does not show data being encoded in the queries; the domain names appear random but are not carrying payloads. The pattern of many NXDOMAIN responses and one successful resolution is not typical of DNS tunneling, which would involve more consistent traffic to a specific domain with encoded data.

Apply the Mode of the frequency dataset.

Why it fails: The mode identifies the most frequent timestamp value, which says nothing about how far the outliers deviate from the distribution. It is tempting because frequency data invites counting, but the mode describes central tendency, not significance. A z-score or IQR-based test measures deviation from the expected distribution.

Perform a simple Median split.

Why it fails: A median split divides the dataset into two halves, discarding the magnitude of deviation each outlier carries. It is tempting for comparing groups, but it cannot quantify whether an extreme timestamp is statistically significant. A z-score or interquartile-range calculation tests the outlier against the distribution.

Use the Range calculation.

Why it fails: Range only reports the span between maximum and minimum values, so a single extreme timestamp inflates it without indicating whether the deviation is statistically meaningful. It is tempting as a quick spread measure, but it ignores distribution shape. A z-score or interquartile-range test quantifies outlier significance against the distribution.

To reduce the storage space required for logs.

Why it fails: Normalisation standardises field names, formats and timestamps across sources so events can be correlated; it can incidentally aid compression, but storage reduction is not its function and often increases volume through added metadata. It would be tempting when log retention costs dominate, where archiving, filtering or tiered storage would be the actual remedy.

To increase the ingestion speed of the SIEM.

Why it fails: Normalisation parses and rewrites each event into a common schema, which adds processing overhead rather than accelerating ingestion. Ingestion speed is addressed through collector sizing, batching or licensing throughput. It would be tempting when SIEM pipelines lag behind source volume, but tuning parsers or brokers, not normalisation, resolves that bottleneck.

To encrypt the logs for regulatory compliance.

Why it fails: Normalisation converts disparate log formats into a common schema so events can be correlated and queried consistently; encryption protects data at rest or in transit and does nothing to reconcile field names or timestamps. It would be tempting where regulatory mandates require log confidentiality, but that is a separate control applied after parsing, not the purpose of normalisation.

Elevation of Privilege

Why it fails: Elevation of Privilege covers gaining rights beyond those granted; logging tokens exposes credentials but does not itself grant higher privileges. It would be the correct category where an attacker exploits a flaw to obtain administrator access they were never authorised to hold.

Tampering

Why it fails: Tampering means unauthorised modification of data or code; writing tokens to a debug log is exposure, not alteration. Tampering would be the correct category where an attacker changes stored records, configuration or messages in transit to corrupt or subvert system behaviour.

Repudiation

Why it fails: Repudiation concerns denying that an action occurred, requiring non-repudiable audit evidence; plain-text token logging is an information disclosure issue instead. Repudiation would be the correct category where the system lacks logging or integrity controls proving who performed an action.

The hypothesis is the most likely scenario.

Why it fails: In ACH, the lowest-scoring hypothesis is the least likely, since diagnostic evidence contradicts it rather than supporting it. The option is tempting because people assume a score ranks likelihood directly, but the matrix scores inconsistency, so the highest-scoring hypothesis is the most likely scenario.

The hypothesis is heavily supported by available data.

Why it fails: A lowest score indicates the evidence contradicts the hypothesis, so it is the least supported, not heavily supported. The option is tempting because a numeric score appears to measure support, but ACH weights evidence by its diagnosticity, meaning low scores flag hypotheses the data argues against.

The hypothesis lacks enough evidence to be evaluated.

Why it fails: A lowest score means the evidence is inconsistent with that hypothesis, making it the least supported, not insufficiently evidenced. The option is tempting because sparse evidence also produces low scores, but ACH scores reflect diagnosticity against each hypothesis, so a low score actively argues against it.

Perform a Root Cause Analysis on the operating system.

Why it fails: Root cause analysis explains why a failure occurred, not which ATT&CK technique an observation represents. It is used during incident post-mortems; mapping DLL side-loading requires matching the behaviour to the Defence Evasion technique's procedure description.

Use the CVSS score of the DLL to prioritize the threat.

Why it fails: CVSS scores a software vulnerability's severity, whereas DLL side-loading is an adversary technique exploiting a legitimate signed executable; no CVE need exist. CVSS prioritisation is correct when triaging patching of known vulnerabilities, not mapping adversary behaviour.

Calculate the frequency of the DLL calls to determine the actor intent.

Why it fails: DLL Side-Loading is mapped by identifying the technique itself, not by counting call frequency, which yields no ATT&CK identifier. Frequency analysis suits anomaly or beaconing detection, where volume and timing reveal malicious patterns. Here the observation already names the technique, so frequency calculation adds nothing to matrix mapping.

It provides a vulnerability score for every asset.

Why it fails: The Diamond Model describes intrusion events across four vertices; it assigns no severity ratings to assets. It is tempting because vulnerability scores also appear in threat reports, but those come from scanners or CVSS, not from the model's adversary-capability-infrastructure-victim structure.

It calculates the financial loss expectancy of a breach.

Why it fails: The Diamond Model maps relationships between adversary, capability, infrastructure and victim; financial quantification comes from risk or FAIR-style analysis. It is tempting because both feed executive reporting, but the model produces no monetary figures, so loss expectancy must be calculated separately.

It replaces the need for SIEM log collection.

Why it fails: The Diamond Model structures an intrusion around adversary, capability, infrastructure and victim, correlating events for analysis; it neither ingests nor stores telemetry. It is tempting because it complements SIEM output in a report, but collection remains the SIEM's function, so it cannot replace it.

The vulnerability is currently being exploited in the wild.

Why it fails: CVSS measures intrinsic severity of a vulnerability, not exploitation activity; a high base score says nothing about whether attackers are actively using it. It is tempting because severity often correlates with attacker interest, but active exploitation is tracked by threat intelligence and the CISA KEV catalogue, not the CVSS score itself.

The vulnerability affects only Windows systems.

Why it fails: CVSS scores are platform-agnostic, measuring severity through exploitability and impact metrics rather than naming affected operating systems. Platform scope is tempting because asset inventories matter for triage, but that information comes from vulnerability scanners or CVE metadata, not the CVSS score.

The vulnerability is already patched.

Why it fails: A high CVSS score reflects severity metrics such as exploitability and impact, not patch status; patched vulnerabilities typically carry reduced or no exposure. Patch state is tempting because remediation tracking matters, but that comes from configuration and vulnerability management records, not the CVSS base score itself.

Whether the threat actor has successfully exfiltrated data.

Why it fails: Sensitivity analysis tests how changes in individual assumptions or variables alter the threat-model outcome, identifying which inputs most affect risk. It tempts because exfiltration is a threat-model concern, but confirming whether data left the network is detection or incident response, not sensitivity analysis.

The total number of threat actors targeting the organization.

Why it fails: Sensitivity analysis varies input assumptions to see how conclusions change, so counting threat actors measures population size, not model sensitivity. It tempts because actor enumeration feeds likelihood ratings elsewhere in threat modelling, and would be correct when scoping which adversaries to model rather than testing how robust your risk rankings are.

The cryptographic strength of the data being protected.

Why it fails: Sensitivity analysis tests how output changes as input parameters vary; cryptographic strength is a property of the encryption implementation, not a variable being perturbed. It tempts because encryption strength does influence risk scores, and assessing it would be correct when evaluating whether protected data meets a compliance or cipher-suite requirement.

It increases the absolute volume of the data collected.

Why it fails: A rolling average reduces noise by aggregating values across a window; it does not increase the volume of data collected, and doing so would obscure rather than reveal beaconing patterns. Increasing collection volume would be relevant when raw telemetry is insufficient, but smoothing works on existing logs to expose periodic C2 intervals.

It eliminates the need for further traffic inspection.

Why it fails: A rolling average smooths short-term fluctuations so underlying periodic beaconing patterns become visible; it does not replace traffic inspection, which remains necessary to confirm malicious C2 activity. Eliminating further inspection would be tempting when reducing analyst workload, but the technique only aids pattern detection, it cannot validate or classify traffic.

It encrypts the log data for safer analysis.

Why it fails: A rolling average is a statistical smoothing method applied to numeric time-series values; it performs no cryptographic operation on log data. Encryption would be the correct choice when protecting log confidentiality at rest or in transit, but here the goal is revealing periodic beaconing intervals, which smoothing achieves without altering data security.

Ignoring the total volume of data available.

Why it fails: Ignoring total data volume is not the pitfall; trend analysis depends on sufficient volume, and analysts typically risk over-collecting rather than overlooking it. It is tempting because volume feels relevant to statistical confidence, and it would be correct if the concern were insufficient sample size for detecting patterns.

Collecting too much data from different sources.

Why it fails: More data is generally better for trends.

Using visual graphs to display the results.

Why it fails: Visual graphs aid trend analysis by revealing patterns over time; they are a recommended output, not a pitfall. It is tempting because poorly chosen charts can mislead, and graphing would be the correct approach when presenting temporal threat patterns to stakeholders.

Vulnerability scanning.

Why it fails: Vulnerability scanning enumerates software weaknesses on hosts; it cannot track adversary infrastructure whose IP addresses change daily. It would be correct for assessing exposure in your own estate. Mapping rotating infrastructure requires pivoting on stable indicators such as TLS certificates, registrars or malware artefacts.

Qualitative SWOT analysis.

Why it fails: SWOT analysis is a strategic planning framework assessing organisational strengths, weaknesses, opportunities and threats; it produces no technical indicators. It would suit business risk discussions, not infrastructure tracking. Mapping rotating adversary IPs requires pivoting on stable artefacts such as TLS certificates, domain registrations or malware signatures.

Static analysis of the malware binary.

Why it fails: Static binary analysis examines code artefacts at rest, revealing embedded strings or logic, but cannot observe the 24-hour IP rotation, which is live network behaviour. It is tempting because static analysis is genuinely useful for extracting hardcoded command-and-control addresses, yet mapping recurring infrastructure changes requires traffic-level observation over time.

Deployment

Why it fails: DREAD's D stands for Damage, not Deployment, which is a lifecycle stage rather than a risk-rating factor. Deployment is tempting because threat modelling often occurs alongside deployment planning, and it would be relevant if the question asked when in the development process modelling should happen.

Detection

Why it fails: DREAD's D stands for Damage, not Detection, which relates to discoverability rather than the acronym's risk factors. Detection is tempting because DREAD's Reproducibility and Discoverability components touch on how readily a threat is found, and it would fit a question about monitoring coverage.

Data loss

Why it fails: DREAD's D stands for Damage, the potential harm a threat causes, not Data loss, which is merely one possible damage type. Data loss is tempting because it is a concrete impact often cited in threat discussions, and it would fit if the question asked about a damage category rather than the acronym's component.

The budget allocated for the security team.

Why it fails: Threat models document assets, entry points, trust boundaries and threats; a security budget is a financial planning artefact and maps to no modelling element. It is tempting because resourcing does shape remediation priorities, and cost-benefit figures belong in a risk register or business case, not the model itself.

The employee handbook for the IT department.

Why it fails: Threat models capture architecture, data flows, trust boundaries and adversary goals; an HR policy document describes conduct, not system design. It is tempting because administrative controls do mitigate threats, and the handbook would be the right artefact when assessing personnel-related controls during a compliance or policy review.

A list of all employees with admin access.

Why it fails: Threat modelling documents components, data flows, trust boundaries and threats; an admin roster is an identity-governance inventory, not a model element. It is tempting because privileged accounts are high-value targets, and such a list is correct when performing access reviews or entitlement audits rather than threat modelling.