CSA (Other exams) common mistakes
CSA · Understand the traps and how to avoid them.
Treating a risk rating as the final answer instead of translating it into a treatment decision: candidates label a finding 'high risk' and stop, without stating whether the organization should mitigate, transfer, avoid, or accept it, who owns the decision, and what residual risk remains.
Risk-rating methodology (likelihood × impact matrices, qualitative scales) is heavily studied because it is easy to memorize, while the governance step of risk treatment and acceptance authority receives less attention, so candidates conflate 'scoring' with 'managing'.
What to do instead
For every risk scenario, practice writing a two-part answer: (1) the rating and its basis, and (2) the treatment option, the accountable owner, and the residual risk statement. Remember that acceptance is a business decision made by accountable management, not by the security architect alone, and that the architect's job is to present options with trade-offs.
Answering architecture questions with a control list rather than a design rationale: candidates name firewalls, MFA, encryption, and logging without explaining where each control sits in the architecture, what threat it addresses, and what assumption it depends on.
Exam preparation often rewards recall of control names, and candidates default to 'more controls = safer' rather than demonstrating that controls are placed to enforce a specific trust boundary or mitigate a specific threat.
What to do instead
For each control you cite, attach three things: the trust boundary or asset it protects, the threat or failure it mitigates, and the residual exposure if it fails. Practice describing a design as 'zone, boundary, control, threat' rather than as a checklist.
Confusing authentication with authorization and session management: candidates treat a successful login as proof that access is correctly scoped, and miss questions about least privilege, token lifetime, revocation, and re-evaluation of access after role changes.
Identity questions often present a single scenario (a user logs in) and candidates stop reasoning once authentication succeeds, overlooking that authorization decisions must be enforced per request and re-evaluated when context changes.
What to do instead
For every identity scenario, separate the three questions: who is the subject (authentication strength), what may they do (authorization policy and enforcement point), and how long does that hold (session, token, and revocation design). Explicitly state where the policy decision point and policy enforcement point sit.
Assuming a network segment is a security boundary by itself: candidates describe VLANs or subnets as if segmentation alone provides protection, without addressing inter-segment policy enforcement, default-deny rules, east-west traffic inspection, and control-plane access.
Segmentation is taught as a topology concept, so candidates draw zones but do not reason about what governs traffic between zones or how an attacker who lands in one zone is prevented from pivoting.
What to do instead
For every segmentation answer, specify the enforcement mechanism (stateful policy, security group, proxy, or service mesh), the default posture (deny by default with explicit allow), and how east-west and management traffic are controlled and logged. Treat segmentation as a policy problem, not a diagram problem.
Treating the cloud shared responsibility model as a single split: candidates say 'the provider secures the cloud, we secure what is in it' without distinguishing IaaS, PaaS, and SaaS, and without naming which controls (identity, patching, encryption keys, logging) remain the customer's.
The phrase is memorable and sounds complete, so candidates stop at the slogan and fail questions that hinge on where the boundary actually falls for a specific service model or managed feature.
What to do instead
Build a small matrix for IaaS, PaaS, and SaaS covering host patching, OS hardening, application code, identity configuration, key management, and log retention. For any cloud scenario, state the service model first, then name the customer-side controls explicitly.
Selecting encryption primitives by name recognition rather than by requirement: candidates propose AES or RSA without matching the primitive to the use case (bulk data vs key wrapping vs signatures vs password storage), and without addressing key lifecycle.
Algorithm names are easy to recall and appear frequently in study material, but the exam tests whether the candidate can map a requirement (confidentiality at rest, integrity, non-repudiation, password verification) to an appropriate construction and its key management.
What to do instead
Practice a requirement-to-primitive mapping: symmetric AEAD for bulk data, asymmetric for key establishment and signatures, a memory-hard password hash for credentials, and a KMS or HSM for key custody. Always include generation, rotation, storage, access control, and destruction of keys in the answer.
Ignoring data classification and lifecycle in protection answers: candidates propose encryption and access control without first stating the data's classification, where it lives across its lifecycle (creation, storage, use, sharing, archival, deletion), and which residency or privacy obligations apply.
Technical controls are more concrete and easier to study than classification schemes and data-flow reasoning, so candidates jump to controls before establishing what is being protected and under which obligations.
What to do instead
Open every data protection answer by classifying the data and tracing its lifecycle and locations, then select controls per stage. Explicitly address minimization, retention, cross-border transfer, and deletion verification, since these are where privacy and protection requirements intersect.
Treating threat modeling as a one-time document: candidates describe producing a threat model at design time and never connect it to secure coding requirements, testing, or change management, so the model does not influence later decisions.
Threat modeling is often learned as a diagramming exercise (DFDs, STRIDE) rather than as a continuous feedback loop into requirements, backlog items, and verification, so candidates omit the operational half.
What to do instead
Describe threat modeling as a loop: model the system, enumerate threats, derive security requirements and abuse cases, feed them into design and test cases, and revisit on architecture change. Name the artifacts (requirements, test cases, accepted risks) that prove the model was used.
Describing detection without specifying data sources, tuning, and response integration: candidates say 'monitor logs and alert on anomalies' without naming which telemetry, what baseline, how false positives are handled, or how an alert becomes an incident with defined severity and escalation.
Monitoring is frequently reduced to tool names, and candidates do not practice tracing a signal from collection through detection, triage, escalation, and containment, which is what scenario questions test.
What to do instead
For any detection scenario, specify the telemetry source, the detection logic and its baseline, the triage criteria and severity, the escalation path with roles, and the containment and evidence-preservation steps. Practice walking one realistic alert end to end.
Skipping the compliance-to-control mapping: candidates cite a framework name (ISO 27001, SOC 2, PCI DSS, GDPR) as if citing it answers the question, without identifying the specific requirement, the control that satisfies it, and the evidence that demonstrates it.
Framework names are highly recognizable and easy to deploy as a shortcut, but exam scenarios ask how an obligation translates into an implemented, auditable control, which requires knowing the requirement text and the evidence trail.
What to do instead
For each framework you rely on, memorize two or three concrete requirements and the control-plus-evidence pair that satisfies them. In answers, name the requirement, the control, the owner, and the evidence artifact (policy, configuration export, log, test result).