ACIA Capstone common mistakes
ACIA Capstone · Understand the traps and how to avoid them.
Treating a named framework (ISO 27001, NIST CSF, SOC 2, PCI DSS) as interchangeable when a scenario asks which control objective applies, and citing a control number from the wrong framework or from a superseded revision.
Candidates memorise one framework's structure during study and pattern-match any governance prompt to it, because the scenario language ('control environment', 'certification', 'attestation') overlaps heavily across frameworks.
What to do instead
Before answering, classify the prompt: is it asking for certification of a management system, an audit opinion on controls, a contractual baseline, or a payment-card mandate? Map each to exactly one framework family and only then recall structure. Where a revision matters, state the version explicitly in your reasoning so an outdated citation is visible to you.
Answering an access-control scenario with the strongest mechanism (mandatory access control, full privileged access management) when the requirement is least privilege plus separation of duties at a scale the organisation can actually operate.
Candidates equate 'most secure' with 'correct', and exam stems that mention regulated data or insider risk pull attention toward maximal controls rather than proportionate, auditable ones.
What to do instead
Identify the decision being protected (who approves, who executes, who reviews) and place a control at each boundary. Then check feasibility: if the proposed mechanism cannot be administered by the stated team size or breaks a stated availability requirement, it is the distractor. Prefer controls that produce reviewable evidence.
Selecting a segmentation or filtering design without first establishing the trust boundary and data flow direction, so the chosen control (stateful inspection, proxy, microsegmentation) does not match where the enforcement point actually sits.
Network questions are often read as product-selection questions; candidates jump to a device class before drawing where the zones and flows are.
What to do instead
Sketch the zones, the allowed flows with direction and port, and the enforcement point in one line each before reading the options. Reject any option that places enforcement on the wrong side of the boundary or that requires the flow to traverse a device it does not naturally cross.
Conflating the cloud provider's responsibility with the customer's, particularly assuming the provider secures guest-level configuration, patching inside workloads, or identity policy correctness.
Marketing language around 'managed' services and the shared-responsibility model's variation by service type (IaaS, PaaS, SaaS) invites a single mental model that is wrong for at least one service tier.
What to do instead
Name the service model first, then split duties explicitly: physical and hypervisor versus guest OS, runtime, data, and identity configuration. For any control, ask who can technically observe and change it; that party owns it. Options that shift a customer-side configuration duty to the provider are almost always the trap.
Choosing an encryption approach without matching key lifecycle to the threat model, for example recommending encryption at rest as a fix for an authorisation flaw or ignoring key custody and rotation when data crosses trust domains.
Encryption is treated as a universal remedy, and candidates under-weight the operational half (key generation, escrow, rotation, revocation) because the algorithm names are more memorable.
What to do instead
State the threat being mitigated: data at rest on stolen media, data in transit on an untrusted path, or data in use by an over-privileged operator. Only then select the primitive and, critically, who holds the key and how it rotates. If the threat is an authorised user accessing data they should not see, encryption at rest does not address it.
Jumping to containment actions in an incident scenario before establishing scope and preserving evidence, and choosing a response that destroys the forensic record needed for later phases.
Incident prompts create urgency, and candidates reward decisive-sounding actions; the lifecycle phases are known but not applied under the scenario's time pressure.
What to do instead
Run the phase order explicitly in your reasoning: detect and validate, scope, contain, eradicate, recover, review. Prefer containment that preserves evidence (isolate the host, revoke sessions, block at the perimeter) over actions that wipe or rebuild immediately. If an option both contains and preserves, it usually wins.
Treating a vulnerability score as a business priority, ranking remediation purely by base severity while ignoring exploitability, exposure, and compensating controls stated in the scenario.
Scoring systems produce a single memorable number, and candidates substitute that number for the contextual judgement the question is testing.
What to do instead
Build a short ranking on three axes: is it reachable from an untrusted position, is exploitation observed or trivially automatable, and what compensating control already limits impact. Use the score as an input, then adjust. When two options differ only in order of remediation, the contextual one is correct.
Proposing a control in a design scenario without stating the failure mode it addresses or the residual risk it leaves, so the recommendation is a component list rather than an architecture.
Candidates study controls as catalogue items and reproduce them, missing that design questions reward traceable reasoning from threat to control to residual risk.
What to do instead
For each proposed element, write one clause of the form: threat, control, residual risk, monitoring signal. If you cannot name the residual risk, the control is not fully understood. Answers that pair a control with its detection and its accepted residual risk are the designed-correct ones.
In case-analysis items, answering each sub-question in isolation and letting earlier assumptions contradict later answers, or ignoring a constraint introduced in the scenario narrative.
Capstone cases are long and candidates manage cognitive load by answering locally, losing the thread of stated constraints such as budget, regulatory scope, or legacy dependencies.
What to do instead
Before the first sub-answer, extract the scenario's hard constraints into a short list and keep it visible. After the final answer, re-read the list and check each answer against it; a contradiction between two answers is a reliable signal that one is wrong.
Reading the question stem once and selecting an option that is true in general but does not answer the specific ask, such as describing a control when asked for evidence, or naming a risk when asked for a treatment.
Under time pressure, recognition of familiar terminology substitutes for parsing the interrogative, and plausible-sounding options are accepted without checking the verb.
What to do instead
Underline the operative verb and the object in the stem (identify, justify, select, sequence) and restate the ask in your own words before evaluating options. Eliminate any option that is accurate but answers a different verb; then choose among the remainder.