CS0-003 CompTIA Cybersecurity Analyst (CySA+) Exam Topics and Questions

Reporting and Communication sits at the boundary between technical work and the people who act on it. The exam tests whether you can translate scanner output and incident timelines into language that drives decisions, not just whether you understand the underlying security concepts. Gaps here tend to show up in questions about who gets told what, when, and in what form. Getting this wrong costs marks even when your technical reading of a scenario is right.

How Reporting and Communication is tested

At 17% of the exam, this topic appears often enough that a consistent weakness will show in your score. Items rarely ask you to define a term. They place you in a scenario where a report has gone to the wrong audience, a metric has been chosen poorly, or a remediation is stalled, and they ask what you should do next.

The trap is picking the most technically correct action when the question is really about communication sequence or stakeholder level. Escalation questions reward knowing when an incident has crossed a threshold that requires executive or legal notification, not just when the technical team should act. Root cause analysis items reward understanding that a lessons-learned report is a formal artifact with a specific audience, not a verbal debrief. KPI and metrics items reward distinguishing between what a CISO needs to see and what a vulnerability management team tracks internally. Candidates lose marks by answering as a technician when the scenario calls for an analyst who understands organizational accountability.

Where the previous topic focuses on what you communicate after an event, Incident Response Management is about what you do during one. At 20%, it carries real weight, and the questions are scenario-heavy. The domain spans frameworks that describe attacker behaviour, the hands-on phases of response, and the planning work that happens before any incident occurs. Your weak point is likely whichever of those three layers you have spent the least time practicing in a timed context.

How Incident Response Management is tested

Items in this topic tend to describe an event in progress and ask what phase you are in, what you should do next, or which framework concept applies. The ordering trap is common: candidates know the phases but pick the wrong sequence when containment and eradication are presented as simultaneous options. Items reward acting in the correct order before moving to recovery.

Framework questions test precision. The cyber kill chain, the diamond model, and MITRE ATT&CK each describe attacker behaviour differently, and items are written to distinguish between them. Knowing that MITRE ATT&CK maps to specific adversary techniques, while the diamond model focuses on relationships between adversary, capability, infrastructure, and victim, is the kind of distinction the exam probes.

Playbook and tabletop questions reward knowing that a tabletop exercise tests a plan without executing it, and that a playbook is a pre-approved decision tree, not a general guideline. Forensic analysis items reward preserving evidence integrity before analysis. Candidates lose marks by treating business continuity and disaster recovery as synonymous in a scenario where the distinction determines the response path.

Vulnerability Management is the single largest topic on this exam. Nearly a third of your marks come from here, which means a shaky grasp of scanning mechanics, scoring, or remediation decisions will drag your total score even if you are strong everywhere else. The domain runs from the technical details of how scans are configured, through interpreting what they find, to deciding what to fix first and how. Each layer has its own exam traps.

– Scanning setup and tool output

The scanning sub-topic is more granular than candidates expect. The exam distinguishes credentialed from non-credentialed scans on the basis of what each can actually see: a credentialed scan authenticates to the target and reports a fuller picture of installed software and configuration state, while a non-credentialed scan sees only what is exposed to the network. Agent-based scanning is tested in the context of assets that are rarely on the network, such as remote laptops, where an agentless scan would miss them entirely.

Passive scanning matters because it produces no traffic and therefore no disruption, which is the deciding factor when scanning critical infrastructure where active probing carries operational risk. Static versus dynamic analysis appears in the context of application testing: static analysis examines code without executing it, dynamic analysis runs the application. Tool output questions ask you to read scanner results and identify what type of finding is shown, whether it comes from a web application scanner, a network scanner, or a cloud infrastructure assessment. The skill tested is interpretation, not just recognition of tool names.

– Prioritization and scoring

CVSS is the primary scoring framework tested here, and the exam goes beyond asking you to define it. Items present a score or a vector string and ask what it implies about exploitability, scope, or urgency. The base score alone does not determine priority: asset value and the presence of active exploitation in the wild both modify the decision. Zero-day vulnerabilities are tested as a special case where no patch exists and compensating controls become the immediate answer.

Validating findings is a step candidates skip in practice and lose marks on in the exam. A scanner result is not automatically a confirmed vulnerability: false positives exist, and items reward confirming a finding before escalating it. Exploitability questions ask whether a vulnerability is reachable and weaponizable given the specific environment described in the scenario, not whether it is theoretically severe. The distinction between a critical vulnerability in an internet-facing system and the same vulnerability on an isolated internal host is exactly the kind of judgment the exam is designed to test.

– Mitigation controls and response

Mitigation control items focus on specific vulnerability classes. Cross-site scripting and overflow vulnerabilities each have preferred control types, and the exam tests whether you match the control to the vulnerability rather than applying a generic hardening answer. Data poisoning questions appear in the context of machine learning pipelines and training data integrity, a newer area that catches candidates who have only studied traditional web and network vulnerabilities.

The vulnerability response sub-topic brings in patch management timing, maintenance windows, and the governance layer that sits above technical decisions. Exceptions and compensating controls are tested together: when a patch cannot be applied within the normal window, what governance artifact is required, and what control substitutes in the meantime? Secure SDLC and threat modeling items ask you to identify where in the development lifecycle a vulnerability should have been caught. Service-level objectives appear as a constraint: a remediation plan that violates an SLO is not an acceptable answer even if it is technically sound.

How Vulnerability Management is tested

At 30%, this topic will appear throughout your exam. Items span every layer from scan configuration to governance, and the range means you cannot afford a blind spot in any one area.

Scanning items are scenario-based: you are given an environment with constraints (air-gapped network, remote workforce, production system that cannot go offline) and asked which scan type fits. Items reward matching the scan method to the constraint, not picking the most thorough option by default.

Prioritization items are the ones where candidates most often lose marks. The trap is treating CVSS score as the only input. Items reward a combined judgment that factors in asset criticality, network exposure, and whether exploitation has been observed in the wild. A high CVSS score on a non-internet-facing, low-value asset does not automatically top the remediation queue.

Remediation items test process discipline. Items reward following the correct governance steps, including exception documentation and compensating control selection, before closing a finding. Candidates who jump straight to patching as the answer lose marks when the scenario includes a constraint that makes patching unavailable or premature.

Security Operations is the largest topic on the exam, accounting for a third of your marks. It covers the day-to-day analytical work of a SOC analyst: reading architecture to understand what logs should exist, spotting indicators of malicious activity across network, host, and application layers, using the right tools to investigate, acting on threat intelligence, and improving processes over time. The breadth is the challenge. Strong candidates have gaps in at least one of these layers.

– Architecture and the data it produces

Understanding system and network architecture is tested as a prerequisite for everything else in this topic. If you cannot read a network diagram and identify where logs should be generated, you will misread the scenario before you even reach the question. The exam covers log ingestion in the context of what a SIEM receives and what it cannot see if a source is not feeding it. Operating system concepts appear when a scenario involves host-level evidence: process trees, registry changes, and file system artefacts.

Identity and access management is tested in the context of anomaly detection: an account authenticating at an unusual time or from an unusual location is a signal, and the exam asks you to recognize it as such. Encryption appears as a blind spot: encrypted traffic reduces visibility, and items ask what controls or tools compensate for that. Sensitive data protection questions focus on where data lives in the architecture and what controls are in place at each boundary. The underlying skill is reading an environment description and knowing what is normal before you can identify what is not.

– Detecting and analyzing malicious activity

Malicious activity indicator items are scenario-driven and require you to classify what you are seeing. Network anomalies like unexpected bandwidth spikes or rogue devices on a segment each have a typical cause, and the exam tests whether you associate the indicator with the right threat category. Host-based indicators, particularly unauthorized software installations and signs of data exfiltration such as large outbound transfers or staging directories, are tested in terms of what they suggest about attacker stage and intent.

Application-layer indicators include unexpected outbound connections from a service that should not initiate them, and service interruptions that do not match a known maintenance window. Social engineering indicators appear as email and communication anomalies. The exam does not ask you to memorize indicator lists. It presents a mix of signals in a scenario and asks you to identify which one is most significant or which threat category best fits the combination. Pattern recognition across multiple data points is the skill being assessed.

– Tools, techniques, and scripting

Tool questions test applied knowledge, not product familiarity. Wireshark items ask you to interpret what a packet capture shows, not to describe the tool's interface. SIEM questions focus on how correlation rules work and what a SIEM alert does and does not confirm on its own. VirusTotal and similar reputation-based tools appear in the context of indicator enrichment: a hash or domain is submitted, and the result is one data point in an investigation, not a definitive verdict.

Email analysis is tested as a technique: reading headers, identifying spoofed sender domains, and recognizing phishing indicators in message structure. Pattern recognition items ask you to identify a sequence of events across log entries that fits a known attack pattern. Scripting questions focus on Python and PowerShell in the context of automation: a candidate should know what kind of task each language is typically used for in a SOC context and be able to read a short script excerpt and describe what it does, without being expected to write code from scratch.

– Threat intelligence, hunting, and process improvement

Threat intelligence items test your ability to evaluate and apply intelligence, not just consume it. Comparing threat actors by their tactics, techniques, and procedures means knowing that a nation-state actor and a commodity ransomware group have different tooling, targets, and persistence methods, and that this difference changes your detection priorities. Confidence levels matter: intelligence with low confidence should inform hunting, not trigger automated blocking. Collection methods and intelligence sharing questions cover the difference between open-source, commercial, and government-shared feeds.

Threat hunting items reward a hypothesis-driven approach: you start with a question about attacker behaviour and look for evidence, rather than waiting for an alert. The exam distinguishes hunting from monitoring.

Process improvement questions cover operational maturity. Standardizing processes and integrating tools are tested in terms of what they reduce: alert fatigue, manual steps, and coverage gaps. The single pane of glass concept is tested as a visibility goal, where a SOC analyst should be able to triage from one interface rather than pivoting between disconnected consoles. Items reward recognizing when a fragmented toolset is the root cause of a detection failure.

How Security Operations is tested

At 33%, Security Operations will define your result more than any other topic. Items are almost entirely scenario-based, and they are written to reward analysts who read the full scenario before committing to an answer.

The most common loss of marks comes from tool and technique questions where candidates answer based on what a tool can do rather than what it shows in the specific scenario. A SIEM alert confirms a rule fired, not that an attack occurred. Items reward the next analytical step, not an immediate response action.

Threat intelligence items reward applying intelligence to the described environment. A TTP associated with a specific threat actor is relevant only if the scenario's victim profile matches that actor's known targeting. Candidates lose marks by treating all intelligence as equally actionable.

Process improvement items are the ones candidates underestimate. They reward recognizing operational inefficiency as a security risk in its own right. An analyst spending time on manual correlation that a tool could automate is a gap, and items are written to test whether you see it that way. Architecture items reward knowing what you cannot see before concluding that nothing happened.