GCT-2A-324 common mistakes
GCT-2A-324 · Understand the traps and how to avoid them.
Treating risk as a single 'high/medium/low' label and picking the answer that removes the risk entirely, rather than ranking options by residual risk after the stated controls.
Candidates memorize qualitative rating words and stop reading once a familiar term appears, so they miss that the scenario asks which option best reduces risk to an acceptable level, not which eliminates it.
What to do instead
Before answering any risk question, write down likelihood, impact, and the control already in place, then score each option on residual risk. Eliminate any option that claims zero risk, since no control removes risk completely.
Choosing 'create a policy' as the response to an incident or a detected control gap, when the immediate need is containment, escalation, or a technical fix.
Policy is the most visible governance artifact, so it feels like the safest answer, and candidates confuse the strategic layer with the operational response the question is describing.
What to do instead
Identify the question's time horizon first: minutes/hours means operational action, quarters means program or policy change. Only select a policy answer when the stem describes a repeated pattern with no governing rule.
Picking the strongest cryptographic algorithm or the longest key whenever two options are both technically valid, ignoring performance, interoperability, and the stated constraint.
Candidates equate 'most secure' with 'correct', but exam scenarios usually embed a constraint such as legacy client support, latency budget, or key rotation cost that makes the moderate option right.
What to do instead
Re-read the stem for an explicit constraint before comparing algorithms. If both options meet the security requirement, choose the one that satisfies the stated operational constraint, and reserve 'strongest' answers for questions that explicitly prioritize maximum assurance.
Confusing encryption, hashing, encoding, and tokenization when asked which control protects data at rest, in transit, or in use.
The terms are used loosely in vendor material, and candidates map 'protect the data' directly to 'encrypt' without checking whether the requirement is confidentiality, integrity, or format preservation.
What to do instead
Build a one-line definition for each: encryption is reversible with a key, hashing is one-way for integrity, encoding is not security, tokenization replaces data with a surrogate. Match the definition to the requirement word in the stem (confidentiality, integrity, or reduced scope).
Answering identity questions with authentication mechanisms when the scenario is actually about authorization or accounting, or vice versa.
All three are grouped under access management, and stems often describe a user 'accessing' a resource without signaling which control failed.
What to do instead
Locate the failure point in the stem: proving who you are is authentication, deciding what you may do is authorization, recording what you did is accounting. Then check whether the proposed control addresses that exact point.
Defaulting to federated SSO or MFA as the answer to every identity question, even when the scenario concerns privileged accounts, service accounts, or orphaned entitlements.
MFA and SSO are heavily emphasized, so they become reflexive answers, and candidates overlook that the stem describes a lifecycle or privilege problem that MFA does not solve.
What to do instead
Classify the identity problem first: onboarding/offboarding, privilege creep, credential strength, or session management. Choose the control that maps to that class, and treat MFA as the answer only when the risk is credential compromise at login.
Selecting a network control at the wrong layer, such as proposing a WAF for a problem that requires segmentation, or a VLAN for a problem that requires application-layer filtering.
Candidates match on keywords like 'web' or 'internal' instead of identifying the layer where the traffic or threat actually operates.
What to do instead
State the OSI layer of the threat and the layer of each proposed control before choosing. If the layers do not match, the option is wrong regardless of how security-sounding it is.
Treating a detection tool as a prevention tool, or recommending more logging when the scenario's problem is alert fatigue or missing triage.
Monitoring and response questions share vocabulary with prevention questions, and candidates assume that seeing an event equals stopping it.
What to do instead
Ask what the stem says is failing: prevention, detection, triage, or response. Logging and SIEM address detection; tuning and playbooks address triage; only prevention controls stop the event. Pick the control that fixes the named failure.
Ranking vulnerabilities by raw CVSS score alone and ignoring exploitability in the actual environment, such as internet exposure, existing compensating controls, or active exploitation.
CVSS is the most familiar number in the stem, so candidates sort by it and skip the contextual clues that determine real priority.
What to do instead
Use CVSS as a starting point, then adjust for exposure, threat intelligence, and compensating controls. When two options differ only in remediation order, choose the one that reflects reachability and active exploitation over the higher base score.
Accepting a vendor's SOC 2 report or certification as proof of adequate control without checking scope, period, and whether it is a Type I or Type II report.
Certifications read as pass/fail badges, and candidates do not distinguish a point-in-time design opinion from an operating-effectiveness opinion over a period.
What to do instead
For any third-party question, check three things: what systems are in scope, what time period is covered, and whether the assurance is design-only or operating effectiveness. Choose the option that addresses the gap in those three, such as a right-to-audit clause or a bridge letter.