Google Cybersecurity common mistakes
Google Cybersecurity · Understand the traps and how to avoid them.
Confusing the CIA triad labels - labelling an integrity attack as an availability attack (or vice versa) when reading a short scenario such as a ransomware encryption event or a defaced website.
Candidates memorise 'CIA' as a list of three words and match on keywords like 'data' or 'stolen' instead of asking which property was actually harmed: was the data changed, was it kept secret, or was access lost?
What to do instead
Before answering, write one line: 'What did the attacker do to the asset?' Then apply the test - unauthorised change = integrity, unauthorised disclosure = confidentiality, denial of access = availability. Practise on mixed scenarios where one incident touches two properties (e.g. ransomware is availability, with confidentiality risk if data is exfiltrated).
Treating frameworks, controls and regulations as interchangeable - e.g. describing GDPR as a control framework or CIS Controls as a law - and picking an answer because the acronym looked familiar.
The course groups many named documents together in one module, so candidates learn the names without learning the category each one occupies.
What to do instead
Build a three-column table: laws/regulations (GDPR, HIPAA, PCI DSS), frameworks/voluntary guidance (NIST CSF, NIST SP 800-53), and control catalogues (CIS Controls). For each, note who it applies to and whether it is mandatory. Answer by category first, then by name.
Mixing up the NIST CSF core functions (Identify, Protect, Detect, Respond, Recover) by assigning an activity to the wrong function - for example placing vulnerability scanning under Detect or placing log monitoring under Protect.
Real activities overlap (scanning both finds weaknesses and produces alerts), so candidates answer from intuition about the word 'detect' rather than from the function definitions.
What to do instead
Anchor each function to a question: Identify = what do we have and what is at risk; Protect = what safeguards prevent or reduce impact; Detect = how do we know something is happening now; Respond = what do we do during the incident; Recover = how do we restore. For a scanning question, ask whether the activity is finding weaknesses ahead of time (Identify/Protect) or observing an event in progress (Detect).
Matching the wrong port or protocol to a service - e.g. saying SSH is port 23, HTTPS is port 80, or that DNS uses TCP by default - when answering network-security items.
Port numbers are rote facts, and candidates study them in a list without linking each one to what the service does, so adjacent numbers blur together.
What to do instead
Learn ports as a small paired set with the service's purpose: 22 SSH (encrypted remote shell), 23 Telnet (cleartext remote shell), 25 SMTP, 53 DNS, 80 HTTP, 443 HTTPS, 20/21 FTP. Deliberately memorise the confusable pairs (22 vs 23, 80 vs 443, 20/21 vs 22) and the fact that DNS uses UDP 53 for lookups and TCP 53 for zone transfers.
Describing a firewall as if it inspects packet contents, or a VPN as if it makes traffic anonymous - choosing the 'strongest sounding' option rather than the one that matches the tool's actual function.
Security terminology is used loosely in everyday speech, so candidates import popular meanings ('VPN = privacy tool') instead of the technical definitions taught in the course.
What to do instead
For each network device, memorise a one-line capability statement with its limit: stateless firewall filters on headers only; stateful firewall tracks connection state; proxy server sits between client and server and can filter content; VPN creates an encrypted tunnel to a trusted endpoint but does not hide the fact of the connection from the endpoint or ISP metadata. Reject any option that claims a capability beyond that line.
Confusing Linux permission fields in `ls -l` output - misreading the owner/group/other triples, or confusing the meaning of `chmod 640` versus `chmod 604` - and picking the answer that 'looks like' the intended permission.
The nine-character string and the octal shorthand are read quickly and positionally, and candidates forget that octal digits map left-to-right to user, group, other.
What to do instead
Always expand octal to symbols before deciding: 4 = read, 2 = write, 1 = execute; first digit user, second group, third other. For 640 that is rw- for user, r-- for group, --- for other. Reconstruct the string by hand on every practice item rather than pattern-matching the digit order.
Using the wrong SQL clause or filter operator - filtering with WHERE when the question asks for a group-level condition (HAVING), or using `=` when the pattern requires LIKE with wildcards - in questions about querying a security log table.
Basic SELECT ... WHERE queries are practiced most, so GROUP BY/HAVING and pattern matching feel unfamiliar and candidates substitute the clause they know.
What to do instead
Learn the execution order as a checklist: FROM → WHERE (row filter) → GROUP BY → HAVING (group filter) → ORDER BY. If the condition mentions an aggregate such as COUNT or AVG, it must be HAVING. Use LIKE with % for partial string matches and = only for exact values. Practise writing the query out fully before looking at the options.
Classifying a threat as the wrong actor type - labelling a hacktivist an insider threat, or an advanced persistent threat an 'authorised hacker' - because the scenario mentions motivation rather than access.
Candidates match on emotional words in the scenario ('protest', 'ideology') and ignore the access dimension that defines insider threats.
What to do instead
Classify actors on two axes before choosing: access (insider vs external) and motivation/resourcing (hacktivist, criminal, APT, competitor). The defining feature of an insider threat is legitimate authorised access that is misused; APTs are defined by persistence, patience and resourcing, not by the target type.
Treating a vulnerability, a threat and a risk as the same thing in asset-management and risk items - e.g. calling an unpatched server 'a threat' or describing a phishing email as 'a vulnerability'.
The three words overlap in ordinary usage, and the exam scenarios deliberately mention all three in one sentence, so candidates grab whichever word they read last.
What to do instead
Apply fixed definitions: vulnerability = a weakness in the asset; threat = something or someone capable of exploiting it; risk = the likelihood and impact of that exploitation. In each item, name the asset, then the weakness, then the actor, then the outcome. Choose the option that matches the specific slot the question asks about.
Misreading detection artefacts - calling a log entry an alert, or an alert an incident - and skipping the triage step when asked what an analyst should do first on receiving a notification.
The detection-and-response workflow is taught as a sequence, but in exam items the sequence is compressed into one sentence, so candidates jump to escalation or containment because those sound more decisive.
What to do instead
Memorise the chain: log (raw record) → event (notable occurrence) → alert (rule or tool flagged it) → incident (confirmed, requires response). For 'what should the analyst do first' items, the first step is almost always to validate/triage the alert against the log data and the playbook, not to contain or escalate. Eliminate any option that begins with containment before confirmation.