Security+ common mistakes
Security+ · Understand the traps and how to avoid them.
On authentication questions, choosing the factor that matches a keyword in the stem (seeing 'smart card' and answering 'something you have' when the stem asks what the PIN represents) instead of classifying the specific credential being asked about.
Factor labels get memorized as vocabulary, so candidates pattern-match nouns in the question rather than reasoning about what the user must know, possess, be, or do.
What to do instead
Before reading the options, isolate the credential the stem names and ask one question of it: does the user know it, physically hold it, inherit it biologically, or perform it? Map only after that. For multi-credential scenarios (badge plus PIN), answer strictly for the element the stem calls out.
Using 'technical' and 'preventive' as if they were the same answer key, so a question asking for a control category (technical, managerial, operational, physical) gets answered with a control type (preventive, detective, corrective, deterrent, compensating, directive), or the reverse.
Both lists are short adjective sets taught together, and under time pressure the brain retrieves whichever list it saw most recently rather than the one the stem requested.
What to do instead
Do two passes on every control question. Pass one: is the stem asking about category or type? Pass two: apply only that axis. A guard locked door is physical (category) and preventive (type); a security awareness campaign is managerial and preventive. If an option mixes axes, it is a distractor.
Treating hashing, encryption, and digital signatures as interchangeable, e.g., claiming a hash 'encrypts' data or provides confidentiality, or asserting that a signature alone keeps the payload secret.
All three appear in the same cryptography objective and all 'protect' something, so the property each one actually delivers (confidentiality, integrity, authenticity, non-repudiation) never gets attached to the tool.
What to do instead
For each cryptographic item, state aloud the single property it provides before answering: symmetric/asymmetric encryption gives confidentiality; a hash gives integrity only; a signature gives integrity plus authenticity plus non-repudiation but not confidentiality. Eliminate any option that credits a tool with a property it cannot supply.
Answering threat questions by naming the tool or outcome ('phishing', 'malware') when the stem asked for the threat actor, the technique, or the vulnerability, e.g., labeling an insider exfiltration scenario a supply chain attack.
Vendor content and news headlines collapse all of these into one word ('threat'), so candidates never practice separating the actor, the tactic, and the weakness being exploited.
What to do instead
Parse every scenario into three slots: who is acting, what they are doing, and what weakness makes it possible. Then reread the stem to see which slot is being asked about, and pick the option that fills only that slot. An unpatched service is a vulnerability; exploiting it is a technique; the person doing it is the actor.
Filing every social engineering scenario under 'phishing' instead of matching the subtype to the delivery channel and target described (vishing, smishing, whaling, pretexting, watering hole, tailgating).
'Phishing' is the umbrella term learned first and most rehearsed, so it becomes the default answer even when the stem specifies a phone call, an SMS, or a compromised third-party site.
What to do instead
Extract two facts from the scenario: the channel (email, voice call, text, in-person, website) and the target (mass audience, executive, specific vendor, anyone visiting a site). The channel plus the target determines the subtype; only a mass email campaign is plain phishing.
Confusing recovery objectives by answering RTO questions with RPO values (or vice versa), and rating a warm site as if it had hot-site capability, when the scenario states a downtime limit or a tolerable data-loss window.
Both metrics are two-to-four-letter acronyms introduced together, and site tiers are memorized as an ordered list rather than as distinct levels of readiness.
What to do instead
Anchor each term to a unit: RTO is measured in time down (how long can we be offline), RPO in time of lost data (how much recent work can we lose), MTTR in repair time, MTBF in time between failures. For sites, rank by what is already in place: hot has hardware and live data, warm has hardware but needs data restored, cold has space and power only.
Assigning a security control to the wrong party in a cloud scenario, e.g., saying the provider patches the customer's guest OS, or that the customer is responsible for the physical datacenter because they chose the region.
The shared responsibility model is stated as a principle rather than as a per-service checklist, so candidates apply one blanket rule instead of varying it by IaaS, PaaS, and SaaS.
What to do instead
For each scenario, name the service model first, then run the 'always the customer' list (data, identities, access configuration, endpoints) and the 'always the provider' list (facilities, hardware, hypervisor, network backbone). Anything in between (OS, runtime, application) shifts to the provider as you move from IaaS to PaaS to SaaS.
Ordering incident response steps incorrectly, most often eradicating or notifying before containing, or placing lessons learned anywhere other than last.
The phases are memorized as a list of words without the dependency logic behind them, so under time pressure the sequence is reconstructed rather than reasoned.
What to do instead
Fix the skeleton as preparation, detection and analysis, containment, eradication, recovery, lessons learned, and test each option against one rule: nothing destructive or corrective happens until the spread is stopped. Note that containment can be immediate isolation before full analysis, which resolves most 'FIRST step' questions.
Answering tool questions by brand familiarity rather than by input and output, e.g., expecting a vulnerability scan to exploit findings, or using a SIEM to execute automated response playbooks when the stem describes orchestration.
Monitoring and assessment tools are learned as a vocabulary list with overlapping one-line descriptions, so candidates never distinguish them by what goes in and what comes out.
What to do instead
Write a one-line contract for each tool before answering: a vulnerability scan enumerates and prioritizes but does not exploit; a penetration test exploits and reports business impact; a SIEM correlates logs and alerts; a SOAR executes playbooks; DLP inspects content in motion, at rest, or in use. Pick the tool whose contract matches the stem's described input and desired output.
Mixing up risk vocabulary and arithmetic: treating risk appetite as a number, calling inherent risk the post-control figure, or computing ALE without multiplying SLE by ARO when the stem supplies both a single-loss figure and an annual frequency.
The terms are defined in one dense objective and look synonymous in plain English, so they are learned as prose definitions rather than as a decision chain.
What to do instead
Fix the chain: asset value times exposure factor gives SLE; SLE times ARO gives ALE. Appetite is the amount of risk leadership will accept in pursuit of goals, tolerance is the acceptable variation around it, threshold is the trigger point. Inherent risk is before controls; residual is after. Compute the arithmetic explicitly instead of estimating.
Answering data-role questions by who touches the data rather than who is accountable, e.g., naming the administrator who runs backups as the data owner, or confusing the controller with the processor in a third-party scenario.
Everyday job titles overlap with the formal roles, and the definitions read as circular until the accountability line is drawn.
What to do instead
Sort by accountability, not activity: the owner is senior and accountable for classification and access decisions; the steward or custodian performs the day-to-day handling; the controller decides why and how data is processed; the processor acts on the controller's instructions. If the entity merely carries out instructions, it is the processor no matter how much infrastructure it holds.