PSAA common mistakes
PSAA · Understand the traps and how to avoid them.
Treating an AI prompt-injection scenario as a classic SQL injection and selecting a WAF signature or input-sanitization fix, instead of addressing the trust boundary between instructions and untrusted data.
Candidates pattern-match on the word 'injection' and reuse application-security reflexes; AI-specific failure modes like instruction/data confusion, tool-call abuse, and model output being consumed by downstream systems are less familiar and rarely appear in older study material.
What to do instead
For any AI Security item, first classify what is being attacked: the model's instruction hierarchy, its tools/plugins, its training data, or its output consumers. Then choose controls that match that layer (e.g., least-privilege tool scopes, output validation before action, segregation of retrieved content from system instructions) rather than generic input filtering.
Assuming a SASE design automatically secures traffic just by 'moving to the cloud', and failing to identify that branch-to-internet traffic still needs explicit policy enforcement points and that legacy on-prem inspection is bypassed.
SASE marketing language conflates network transformation with security outcomes. Candidates remember the acronym's components (SD-WAN, SWG, CASB, ZTNA, FWaaS) but not how traffic paths change and where policy is actually applied after the shift.
What to do instead
For every SASE question, draw the packet path: user/device to destination, and mark each enforcement point. Ask which component inspects which traffic (web vs. SaaS API vs. private app) and whether anything now flows uninspected. Select answers that close the specific gap in the drawn path.
Choosing 'block the IP' or 'add a firewall rule' as the remediation for a detection alert, when the scenario describes compromised credentials, lateral movement, or a living-off-the-land technique that IP blocking will not stop.
Candidates default to perimeter controls because those are the most rehearsed. Security Operations items often test whether you can read the evidence (identity-based indicators, unusual process lineage) and pick containment proportionate to the actual intrusion vector.
What to do instead
Before answering, extract the indicator type from the scenario: identity, endpoint, network, or data. Match containment to that type (session revocation and credential reset for identity; host isolation for endpoint; egress restriction for network). Reject options that act on a layer the evidence does not implicate.
Confusing identity federation, SSO, and provisioning roles, and answering an Identity Security question with 'enable MFA' when the actual gap is authorization scope, role explosion, or stale entitlements.
Authentication controls are heavily publicized, so candidates reach for them first. Questions about least privilege, access reviews, and privilege creep require reasoning about authorization lifecycle, which is less intuitive and easy to skip during study.
What to do instead
Separate the identity question into authentication (who are you), authorization (what may you do), and lifecycle (should this still exist). If the scenario describes over-broad access or orphaned accounts, choose governance controls such as periodic access certification, role mining, or just-in-time elevation, not another authentication factor.
Answering cloud security questions with data-center assumptions, such as placing a perimeter firewall in front of workloads or assuming the provider secures customer data and IAM configuration.
The shared responsibility model is stated so often that candidates recite it without applying it. They miss that the boundary shifts by service type (IaaS vs. PaaS vs. SaaS) and that most cloud incidents stem from customer-side misconfiguration and identity, not provider failures.
What to do instead
For each cloud item, state explicitly which layer the provider owns and which the customer owns for that specific service model. Then check whether the proposed control addresses a customer-owned layer; if the scenario is about exposed storage or over-permissive roles, the answer must be a customer-side configuration or posture control.
Treating observability as synonymous with logging volume, and selecting 'collect more logs' or 'increase retention' when the scenario is about detection latency, missing context, or an inability to trace a request across services.
Candidates equate visibility with quantity. Observability & Remediation items test whether you can distinguish metrics, logs, and traces, and whether telemetry is correlated and actionable rather than merely abundant.
What to do instead
Diagnose the observability gap: is it coverage (no signal), correlation (signals not joined), or timeliness (signal arrives too late)? Choose the fix that matches, such as distributed tracing for request flow, structured enrichment for correlation, or automated response playbooks to cut remediation latency.
Selecting a single 'best' control for a network security scenario that actually requires defense in depth, or conversely stacking redundant controls when the question asks for the most targeted mitigation.
Candidates oscillate between maximalism and minimalism because they do not anchor on the stated threat and constraint. Exam items often include a budget, performance, or operational constraint that rules out the broadest option.
What to do instead
Read for the explicit constraint and the specific threat named. If the item asks for the most effective targeted mitigation, prefer the control that directly addresses the identified vector; if it asks for architectural resilience, prefer layered controls with independent failure modes. Justify the choice against the stated constraint.
Ignoring the difference between detection, prevention, and response when the question asks which capability a given tool provides, leading to answers that credit a SIEM with blocking traffic or an EDR with network segmentation.
Product categories overlap in marketing, and candidates remember brand associations rather than functional boundaries. This produces plausible-sounding but functionally wrong selections.
What to do instead
Build a mental table mapping each tool class to its primary function and typical data source. When answering, ask 'does this tool have the placement and authority to perform the action described?' If not, eliminate the option regardless of how familiar the product name is.
Failing to recognize that zero trust is an architecture of per-request verification and least privilege, and instead answering zero-trust questions with 'put it behind the VPN' or 'trust the internal network'.
Candidates carry implicit castle-and-moat assumptions from traditional network training. Zero-trust items deliberately place resources that were formerly 'internal' and test whether you still grant implicit trust based on network location.
What to do instead
For zero-trust scenarios, evaluate every access decision on identity, device posture, and context rather than network position. Eliminate any option that grants access because traffic originates inside a trusted zone, and prefer continuous verification with least-privilege, per-session authorization.
Skipping the data-classification and data-flow step when designing controls for AI or cloud scenarios, and applying uniform protection to all data regardless of sensitivity.
Classification feels administrative and is easy to treat as a prerequisite rather than the input that determines control selection. Without it, candidates cannot distinguish which data may enter a model, leave the tenant, or require DLP.
What to do instead
Before selecting a control, identify the data's classification and its permitted flow. Then choose controls proportional to sensitivity, such as blocking sensitive prompts to external models, restricting training data sources, or applying CASB/DLP policy to sanctioned versus unsanctioned SaaS. State the classification assumption explicitly in your reasoning.