CS0-004 CompTIA Cybersecurity Analyst CySA+ V4 (New Version) Exam Topics and Questions

Security Operations is where the exam puts the most weight, and it earns that position. This topic covers the daily machinery of a SOC: how data flows in, how analysts read it, and how threats get identified before they become incidents. The breadth is intentional. You will be tested across network and endpoint signals, cloud and identity telemetry, tooling, threat intelligence, and the process improvements that keep a team from drowning in alerts.

– Architecture, identity, and logging

A SOC is only as good as its visibility, and visibility depends on architecture decisions made long before an alert fires. You need to understand how security components fit together: where sensors sit, what they feed, and why certain log sources matter more than others. Identity is woven through this because most modern attacks pivot through credentials at some point. Knowing how identity systems generate telemetry, and what that telemetry looks like when something is wrong, is a practical skill the exam probes directly. Logging practices matter too. What gets logged, at what fidelity, and where it lands shapes everything downstream. Gaps in log coverage are a favourite exam angle because they represent a blind spot that an attacker can exploit and a defender can miss entirely.

– Detecting malicious activity across surfaces

Network anomalies, endpoint behaviour, cloud API calls, and identity events each produce different signal types, and the exam expects you to read them accurately. Suspicious activity on the network might mean unusual port usage, beaconing patterns, or lateral movement between hosts. On endpoints, you are looking at process trees, file system changes, and persistence mechanisms. Cloud environments add a layer of complexity because the shared responsibility model shifts what you can see and what you must infer. Identity-based attacks, credential stuffing, token theft, and privilege escalation show up in authentication logs and directory events. The exam will present scenarios mixing these surfaces and expect you to identify what the activity indicates, not just that something looks odd.

– Tooling: SIEM, EDR, packet analysis, and threat intelligence platforms

Knowing a tool's name is not enough. The exam tests whether you understand what each tool is actually positioned to do and where it falls short. A SIEM aggregates and correlates; an EDR provides endpoint telemetry and response capability; packet analysis gives you ground truth on what crossed the wire. Threat intelligence platforms add external context, linking an observed indicator to a known actor or campaign. The practical skill being assessed is choosing the right tool for a given investigative step and interpreting what the output tells you. Misreading a SIEM alert because you do not understand its correlation logic, or dismissing a packet capture because you cannot parse the relevant fields, are the kinds of errors that cost marks here.

– Threat intelligence, threat hunting, automation, and AI

Threat intelligence frameworks such as MITRE ATT&CK give analysts a shared language for describing adversary behaviour. The exam expects you to use that language, not just recite it. Threat hunting takes intelligence a step further: you form a hypothesis, define what evidence would confirm or deny it, and then go looking. That process is structured, and the exam will test whether you understand the steps. Automation and workflow improvements are about reducing analyst fatigue and mean-time-to-respond. The AI angle is newer on this version of the exam. You need to understand where AI assists detection, where it introduces risk, and what governance questions arise when models are involved in security decisions. Governance is the part candidates underestimate.

How Security Operations is tested

At 34% of the exam, Security Operations will appear in the majority of the items you face. The items are scenario-driven. You are given a log snippet, an alert description, a tool output, or a brief incident narrative, and you must draw the right conclusion or take the right next step. The trap in this topic is surface-level pattern matching. Candidates who have memorised indicator types without understanding how they chain together will pick an answer that fits one data point but ignores a contradicting one. Items reward reading all the evidence before committing to a conclusion. The AI and automation sub-topics tend to produce conceptual items rather than scenario items, and candidates who skipped them because they seemed abstract often lose easy marks. Threat-hunting questions reward understanding the hypothesis-driven process, not just the tools used. Expect the exam to distinguish between reactive detection and proactive hunting, and to reward the candidate who knows which mode a given situation calls for.

Where Security Operations is about detecting threats in motion, Vulnerability Management is about finding weaknesses before an attacker does. The discipline sounds mechanical, but the exam is not interested in whether you can run a scanner. It wants to know whether you can interpret what the scanner found, decide what to fix first, and explain that decision in terms a risk owner will accept. The gap between running a scan and acting on one intelligently is where most candidates lose marks.

– Scanning methods and tool selection

Different scanning approaches expose different things. An unauthenticated scan shows what an external attacker sees; an authenticated scan reveals the fuller picture of what is actually installed and misconfigured. Agent-based scanning gives continuous visibility on endpoints that move off the corporate network. The exam expects you to match the method to the context: scanning a cloud workload, an OT environment, or a web application each calls for a different approach, and picking the wrong one produces misleading results. Tool selection follows the same logic. The question is not which scanner is best in the abstract, but which approach is appropriate given the environment, the access available, and the risk profile of the target.

– Reading and analysing scan output

Scan results are not self-interpreting. A finding carries a severity rating, a CVSS score, and contextual metadata, and the exam expects you to read all of it. CVSS base scores describe a vulnerability in isolation; environmental and temporal metrics adjust that score for your actual situation. Candidates who treat the base score as the final word will prioritise incorrectly. False positives are another angle the exam covers: a finding that looks critical may not be exploitable in your environment, and a finding that scores low may be trivially exploitable given what else is present. Analysing output means cross-referencing findings against asset context, network exposure, and compensating controls, not just sorting by severity and starting at the top.

– Prioritisation, mitigation, and risk-based decision-making

Once you have a list of findings, the exam wants to know how you triage it. Risk-based prioritisation weighs exploitability, asset criticality, and business context together. A critical vulnerability on an isolated development server ranks differently from a medium-severity finding on a public-facing authentication endpoint. Threat intelligence feeds into this: if a vulnerability is being actively exploited in the wild, that changes the calculus regardless of its base score. Mitigation options range from patching to configuration changes to network-level controls, and the exam will test whether you know which approach fits which situation. Accepting residual risk is also a legitimate outcome, but only when documented and approved by the right authority.

– Controls, policies, and compliance in vulnerability management

Vulnerability management does not operate in a vacuum. Patch management policies, change control processes, and compliance frameworks all shape what you can do and when. The exam tests whether you understand how these constraints interact with technical remediation. A patch that fixes a vulnerability may require a change window, testing in a staging environment, and sign-off from a system owner before it can be deployed. Compliance requirements may mandate that certain classes of vulnerability are remediated within a defined timeframe. Control types, preventive, detective, and corrective, each play a role in a mature programme. Knowing which control type addresses which gap, and how to document that decision, is the kind of applied knowledge this sub-topic rewards.

How Vulnerability Management is tested

At 26%, this topic produces a substantial portion of your exam. Items lean heavily on scenario and data interpretation. You will be given scan output, CVSS scores, or asset inventories and asked to make a prioritisation or remediation decision. The most common mistake is over-relying on the raw severity score without applying business context. Items reward the candidate who adjusts for asset criticality, active exploitation status, and compensating controls already in place. A second trap appears in the controls and compliance sub-topic: candidates confuse control types or misidentify who owns a remediation decision. The exam is testing applied judgement, not recall of definitions. Scanning method questions tend to be context-driven: the right method in one environment is wrong in another, and items reward understanding why. Expect at least some items that present a finding and ask what additional information you would need before acting, rewarding the candidate who resists jumping to a conclusion without complete data.

Vulnerability Management is about preventing damage; Incident Response is about limiting it once something has gone wrong. At 24%, this topic is smaller than the first two but carries real exam weight, and the items are among the most scenario-dense on the exam. You will be expected to move through an incident mentally, applying the right technique at the right phase, and to reason about attacker behaviour using structured frameworks. Procedural knowledge and analytical skill both matter here.

How Incident Response and Management is tested

Items in this topic tend to present an active scenario: an alert has fired, evidence has been collected, or a system has been isolated, and you must decide what comes next. The phase of the incident response process matters because the right action at containment is wrong at eradication, and the exam exploits that. Candidates who treat the phases as a list to memorise rather than a decision framework lose marks when a scenario places them mid-incident and asks what to do. Attack methodology frameworks appear in items that ask you to map observed behaviour to a stage of an attack, or to infer what an attacker is likely to do next. The trap is confusing similar-sounding phases across different frameworks: MITRE ATT&CK and the Cyber Kill Chain do not map one-to-one, and items reward knowing the distinction. Evidence handling questions reward correct sequencing and chain-of-custody awareness. Triage and escalation items reward knowing when a finding exceeds the analyst's authority to act alone.

The technical work of security operations and incident response only produces value if it is communicated clearly to the people who act on it. At 16%, Reporting and Communication is the lightest topic on this exam, but candidates who dismiss it as soft content often drop avoidable marks. The items here test whether you know what belongs in a report, who it goes to, and how the metrics used to measure security performance are defined and interpreted.

How Reporting and Communication is tested

Items in this topic tend to be shorter and less scenario-heavy than those in Security Operations or Incident Response, but they require precision. A question about which metric best reflects detection effectiveness, or what a post-incident review should document, has a single strongest answer, and the other options will look plausible to a candidate who has only a vague sense of the material. Vulnerability management reporting items often ask you to match report type to audience: a technical finding report serves a different purpose than an executive dashboard, and the exam tests whether you know the difference. Incident documentation items reward understanding what must be captured and when, particularly around timelines and chain of custody. Metrics such as mean time to detect and mean time to respond are tested on their definitions and on what they reveal about programme health, not just their names. The communication sub-topic also covers escalation: knowing when an analyst must escalate, to whom, and what information must accompany that escalation is the kind of procedural detail that separates candidates who have practised from those who have only read.