CCNA Cybersecurity (200-201 CCNACBR) common mistakes
CCNA Cybersecurity (200-201 CCNACBR) · Understand the traps and how to avoid them.
Treating the CIA triad as three interchangeable words and picking whichever sounds most alarming, instead of mapping the scenario to the property that was actually violated (for example calling a ransomware encryption event a confidentiality breach).
Candidates memorise the definitions but never practise classifying short incident descriptions, so they default to the term they saw most recently or the one that sounds most severe.
What to do instead
Build a three-column drill: for each scenario, write what the asset is, what the attacker gained, and which property changed. Encryption of data with a ransom demand is integrity plus availability; exfiltration of a customer list is confidentiality. Do 20 short scenarios and justify each choice in one sentence before checking.
Confusing the roles of a vulnerability, a threat, an exploit, and a risk, and answering 'the vulnerability is the attacker' style questions by matching keywords rather than the definition.
Everyday usage blends these words, and exam stems deliberately place them close together so keyword matching fails.
What to do instead
Anchor each term to a sentence pattern: a vulnerability is a weakness that exists, a threat is a potential actor or event, an exploit is the technique or code that takes advantage, and risk is likelihood times impact. Rewrite five news stories into those four slots until the mapping is automatic.
Reading a packet capture or log excerpt by looking only at the port number to decide whether traffic is malicious, and missing that the same port carries a different protocol or that the direction of the connection is the real signal.
Port-to-service memorisation is fast and comforting, and candidates skip the slower step of checking payload, flags, and who initiated the session.
What to do instead
For every capture or log question, state four things before answering: source and destination, protocol actually present in the payload, TCP flags or connection state, and expected behaviour for that service. If the port says 443 but the payload is plaintext HTTP or the flags show a half-open scan, the port is a decoy.
Treating every alert as either a true positive or dismissing it as a false positive, without considering benign true positives, and therefore choosing the wrong escalation or tuning action.
Binary thinking is simpler than the four-way classification, and candidates have not seen enough examples of legitimate traffic that triggers a rule.
What to do instead
Practise sorting alerts into true positive, benign true positive, false positive, and true negative, and for each write the next action: escalate, tune the rule, close, or verify sensor coverage. Recognising that a scheduled vulnerability scanner causes IDS alerts is the classic benign true positive and changes the correct answer from 'block the source' to 'suppress during the scan window'.
Assuming an endpoint is clean because the antivirus console shows no detections, ignoring fileless activity, living-off-the-land binaries, and persistence that never writes a malicious file to disk.
Candidates equate endpoint security with signature-based antivirus and have not internalised that PowerShell, WMI, and scheduled tasks can be abused without dropping malware.
What to do instead
Learn to read the specific host artefacts that reveal fileless activity: suspicious PowerShell command lines with encoded arguments, newly created scheduled tasks or services, WMI event subscriptions, and unusual parent-child process pairs such as a word processor spawning a shell. When a question says no malware was found but behaviour was odd, look for these artefacts rather than concluding the host is clean.
Misreading process ancestry and user context in a host log, for example treating a service running as SYSTEM spawning a command shell as normal, or blaming the child process instead of the parent.
Attention goes to the process with the alarming name, and candidates do not check which account launched it or whether the parent normally spawns children.
What to do instead
For any process-tree question, annotate three fields first: the user the process runs as, the parent process, and the command line. A web server worker spawning a shell is a web shell indicator; a legitimate admin tool spawning a shell under an interactive admin logon is not. Compare against a baseline of what that parent normally does.
Answering network intrusion questions by memorising that a given scan type sets particular flags, without being able to infer intent from the pattern of responses across many packets.
Flag combinations are taught as trivia, so candidates recall the name but cannot read a sequence of SYNs to many ports with RST responses and say what the attacker learned.
What to do instead
Rehearse the three-way handshake and what each response implies: SYN-ACK means open, RST means closed, no reply means filtered. Then read full sequences and state the purpose, such as host discovery, port enumeration, or service version detection. Intent follows from breadth, timing, and which hosts were touched.
Confusing detection technologies by capability, for example expecting an IDS to block traffic or a firewall to detect a payload signature, and choosing a control that cannot produce the evidence the scenario requires.
Product categories blur in marketing language, and candidates pick the tool whose name appears in the question rather than the one whose placement and function match the requirement.
What to do instead
Map each technology to where it sits and what it can see: host-based agents see process and file activity, network sensors see packets but not encrypted payloads, firewalls filter by rule, proxies terminate and inspect. For each scenario ask what visibility the evidence demands, then select the sensor that has that visibility inline or passive as required.
Treating incident response phases as a list to recite, and placing containment before identification or skipping lessons learned, so the chosen next step contradicts the phase the scenario describes.
The phases are memorised as vocabulary rather than as a decision sequence, and candidates do not track which phase the stem has already reached.
What to do instead
For each scenario, mark the current phase explicitly before answering: preparation, detection and analysis, containment eradication and recovery, or post-incident activity. Then ask what the phase requires next. Preserving volatile evidence belongs in detection and analysis; isolating a host belongs in containment; writing new detection rules belongs in post-incident activity.
Handling evidence questions by instinct, such as powering off a compromised machine or reading a file before capturing memory, without applying order of volatility or chain of custody.
The intuitive response to a suspected compromise is to shut it down, and candidates have not practised the forensic trade-off between preserving volatile state and stopping spread.
What to do instead
Apply order of volatility from most to least transient: CPU and memory state, network connections, running processes, then disk, then remote logs. Isolate the host from the network rather than powering it off when memory evidence matters, and document every transfer of custody with who, what, when, and where. When a question offers shutdown as an option, check whether volatile evidence has already been captured.