CENTC common mistakes
CENTC · Understand the traps and how to avoid them.
Treating confidentiality, integrity, and availability as interchangeable labels when asked to classify the primary impact of a given control or incident, rather than identifying which one the scenario actually degrades.
Candidates memorize the CIA triad definitions but practice by reciting them instead of applying them to scenarios, so under time pressure they pick the first plausible-sounding property instead of the one the scenario describes.
What to do instead
For every practice scenario, write one sentence naming the asset, the threat action, and the specific property harmed before looking at the answer options; drill until classification is automatic.
Confusing the functions of symmetric vs. asymmetric cryptography and where each is used in a real protocol (for example assuming a session key is exchanged by encrypting it with a symmetric key).
Candidates learn the algorithms as a list without tracing a full handshake or key-exchange flow, so the role of each primitive blurs.
What to do instead
Diagram one TLS-style handshake end to end from memory, labeling which step uses asymmetric keys, which uses symmetric keys, and which uses hashing; repeat until the flow is reproducible without notes.
Misclassifying a threat by its delivery vector rather than by what it actually does, e.g., labeling a phishing email carrying a macro as a 'phishing attack' when the question asks what type of malware executed on the host.
Scenarios often contain multiple layers (delivery, exploit, payload), and candidates answer the layer they noticed first instead of the layer the question targets.
What to do instead
Before answering, underline the question's subject (vector, vulnerability, payload, or impact) and match the answer to that specific layer; practice with multi-stage scenarios.
Assuming a vulnerability is mitigated because a compensating control exists, without checking whether the control addresses the specific exploit path described.
Candidates pattern-match 'control present' to 'risk resolved' instead of evaluating whether the control interrupts the actual attack chain.
What to do instead
For each scenario, trace the attack path step by step and mark exactly where the named control intervenes; if it does not sit on that path, treat the vulnerability as unmitigated.
Placing security controls in the wrong architectural zone, such as putting an inline inspection device outside the perimeter or assuming segmentation alone provides inspection.
Candidates memorize device names without mapping them to traffic flows, so they cannot reason about where in the topology a control must sit to see the traffic it needs.
What to do instead
Redraw a reference topology (internet, edge, DMZ, internal segments) and place each control on the exact traffic path it inspects; practice explaining why each placement is required.
Choosing 'defense in depth' or 'least privilege' as the answer whenever a design question appears, regardless of whether the scenario is about layered controls or about authorization scope.
These principles are over-learned as default answers, and candidates stop reading the scenario's specific design gap.
What to do instead
Identify the design gap explicitly (missing layer, excessive permission, single point of failure) before reviewing options, and eliminate any principle that does not close that gap.
Selecting a control that detects an issue when the requirement calls for prevention, or vice versa, because the option sounds operationally responsible.
Candidates conflate 'good practice' with 'answers the stated requirement' and do not check the control's function against the requirement verb.
What to do instead
Classify every candidate control as preventive, detective, or corrective before choosing, and match it to the requirement's verb (prevent, detect, recover).
Treating a configuration change as complete once applied, without accounting for verification, logging, or rollback steps in the operational sequence.
Candidates focus on the technical action and skip the operational lifecycle, so they miss options involving validation or change control.
What to do instead
Practice ordering operational tasks as plan, approve, implement, verify, log, and document; when a question asks 'next step,' pick the earliest uncompleted lifecycle stage.
Jumping to containment or eradication before confirming scope and preserving evidence when a question asks for the first action in an incident.
Candidates associate decisive response with immediate containment and overlook that the question may hinge on the incident-response phase order.
What to do instead
Memorize the response phase sequence and, for each scenario, state the current phase before selecting an action; if evidence or scope is unestablished, the earlier phase wins.
Treating a log alert or SIEM notification as a confirmed incident and skipping triage and validation steps in the monitoring workflow.
Candidates equate detection with confirmation and pick response actions that assume the alert is a true positive.
What to do instead
Insert an explicit triage and validation step into every monitoring scenario, and only escalate to response actions after the alert is confirmed or the question states it is verified.
Answering risk questions with a control recommendation when the question asks for risk treatment categorization (avoid, mitigate, transfer, accept).
Candidates conflate the treatment decision with the implementation detail and pick a technical control instead of the treatment type.
What to do instead
Classify each scenario into one of the four treatment categories first, then, only if asked for implementation, select the specific control.
Assuming a compliance framework or regulation guarantees security, or that passing an audit means risk is eliminated, when the question tests the distinction between compliance and risk management.
Candidates treat frameworks as prescriptive security standards rather than as governance baselines that still require risk-based judgment.
What to do instead
Practice distinguishing 'meets the requirement' from 'reduces the risk'; when a scenario involves residual risk or exceptions, choose the risk-based governance answer over the checkbox answer.