OSDA common mistakes
OSDA · Understand the traps and how to avoid them.
Treating the SOC tier model as a fixed escalation ladder and answering that every alert must be escalated to Tier 2 before triage, rather than describing the analyst's own first-pass validation, scoping, and documentation duties at Tier 1.
Candidates memorize tier labels as a hierarchy of authority and assume 'escalate' is always the safe answer, so they skip the triage work the question is actually testing.
What to do instead
For each scenario, ask what the analyst at the stated tier is expected to do before handing off: validate the alert, collect context, decide true/false positive, and document. Reserve escalation for confirmed incidents or defined thresholds, and be able to state what those thresholds are.
Confusing SOC roles and functions, for example assigning threat hunting or detection engineering to the Tier 1 monitoring analyst, or saying the SOC manager performs malware reverse engineering.
The role names sound interchangeable and candidates map them by seniority rather than by the actual work product each role produces.
What to do instead
Anchor each role to its output: monitoring analyst produces triaged tickets, incident responder produces containment and eradication actions, threat hunter produces hypotheses and new detections, detection engineer produces and tunes rules, SOC manager owns metrics, staffing, and process. Match the question's described output to the role.
Reading an alert or log excerpt only for the field named in the question and ignoring corroborating fields (timestamp ordering, source and destination, user context, parent process) that change the verdict.
Exam stems are dense and candidates pattern-match on a single keyword such as 'PowerShell' or 'failed login' and jump to a conclusion.
What to do instead
Practice a fixed reading order for any artifact: who (account), what (process or event), where (host and network), when (sequence relative to other events), and how it deviates from baseline. State the deviation explicitly before choosing an answer.
Labeling any suspicious-looking event as malicious without distinguishing anomaly from indicator, so benign administrative activity such as a scheduled script, a vulnerability scanner, or an approved remote-management tool is classified as an intrusion.
Candidates equate 'unusual' with 'compromised' and forget that detection requires context such as known-good tooling, change tickets, and baseline behavior.
What to do instead
For each candidate answer, ask whether the evidence shows intent and effect (persistence, lateral movement, exfiltration) or merely rarity. Prefer answers that call for validation against baselines and asset ownership before declaring an incident.
Mixing up detection coverage concepts, for example claiming a signature-based IDS will catch a novel living-off-the-land technique, or that anomaly detection gives precise, low-noise alerting by default.
The tradeoffs between signature, anomaly, and behavioral detection are taught as definitions rather than as failure characteristics, so candidates pick the tool that sounds strongest.
What to do instead
Memorize each method's blind spot: signatures miss unknown and obfuscated variants; anomaly detection produces high false positives and needs baselining; behavioral analytics needs quality telemetry and tuning. Choose the method whose blind spot does not apply to the scenario.
Scoring vulnerabilities by CVSS base score alone and recommending remediation order from that number, ignoring exploitability in the environment, asset criticality, exposure, and compensating controls.
CVSS is the most memorizable number in the domain, so candidates treat it as a complete risk score.
What to do instead
Use the formula chain explicitly: risk rises with severity, exposure, asset value, and threat activity, and falls with compensating controls. When two options differ, pick the one that reflects environmental context, and be ready to say why a critical CVSS on an isolated host can rank below a medium on an internet-facing one.
Treating risk as a single quantity and using likelihood, impact, and risk interchangeably in answers, or stating that risk treatment always means patching.
Everyday usage blurs these terms and candidates default to 'remediate' as the universal response.
What to do instead
Keep the definitions separate: risk is a function of likelihood and impact; treatment options are mitigate, transfer, avoid, and accept. Match the option to the scenario, such as accepting a documented low risk on a legacy system with isolation, rather than forcing a patch that is not feasible.
Confusing preventive, detective, and corrective controls, for example listing EDR alerting as prevention or firewall rules as detection, when answering defense-in-depth or control-selection questions.
Modern tools do several things at once, so candidates classify by product name instead of by the control's function in the scenario.
What to do instead
Classify by effect at the moment of the event: stops it before it happens (preventive), records or alerts on it (detective), or restores after it (corrective). Identify the function the question asks for first, then pick the technology that performs it.
Answering network-defense questions with the wrong enforcement point, such as placing host-based blocking at the perimeter or expecting a network IDS to stop traffic rather than alert on it.
Candidates learn tool categories without their position and capability limits, so inline versus passive and host versus network get merged.
What to do instead
For each control, fix two facts: where it sits (host, segment boundary, perimeter, cloud edge) and whether it is inline or passive. Answer only with a control whose position can actually see or affect the traffic described.
Treating authentication and authorization as the same step, or assuming that a successful login with valid credentials means the action requested is permitted, when evaluating access-control scenarios.
Both happen at login time in most user experiences, so the distinction collapses in memory.
What to do instead
Separate the questions: authentication asks who you are, authorization asks what you may do, and accounting asks what you did. In any scenario, check each independently, and remember that stolen valid credentials pass authentication while authorization and least privilege still limit the damage.