PAPA common mistakes
PAPA · Understand the traps and how to avoid them.
On prompt-injection items, treating the injected text as a legitimate instruction and picking the answer that says the model should follow the new instruction because it came from an authenticated user or a retrieved document.
Candidates conflate 'the input is trusted infrastructure' with 'the content is trusted instruction.' Retrieved documents, tool outputs, and user-supplied files are data, not commands, so the correct answer almost always separates the instruction channel from the data channel.
What to do instead
Before answering, label each element in the scenario as instruction-channel or data-channel. If injected content arrives through the data channel, eliminate any option that authorizes it and prefer the option that preserves the original system/task instruction, flags the conflict, or quarantines the content.
For agentic or tool-use AI scenarios, selecting the answer that gives the agent broad standing permissions (write access, shell, email send) because it is 'more capable,' rather than the least-privilege option scoped to the task.
The stem often emphasizes productivity or autonomy, which pulls candidates toward the most powerful option. Questions testing excessive agency are usually dressed up as efficiency improvements.
What to do instead
When an AI agent has tool access, rank options by blast radius. Prefer read-only, per-task scoped, human-approved, and reversible options over standing credentials. If an option expands the agent's permissions without a matching control, eliminate it.
On RAG and vector-store questions, choosing the answer that says access control is unnecessary because the model 'only sees what it retrieves,' instead of recognizing that the retrieval index must enforce the same authorization as the source system.
Candidates reason about the model's context window rather than the retrieval pipeline. They forget that a shared index can surface documents the asking user is not entitled to, and that embeddings can leak content.
What to do instead
Treat the retrieval layer as a data-access layer. The correct answer usually filters at query time by the requesting identity, keeps per-tenant or per-user partitions, and never relies on prompt instructions to hide documents. Reject any option that defers authorization to the model.
On network segmentation items, answering with 'install a firewall' or 'add an ACL' when the scenario already shows a firewall in place, instead of identifying that the rule set permits the lateral path (for example, any-to-any east-west traffic).
Candidates pattern-match 'segmentation' to 'firewall' and stop reading. The stem's detail that traffic between zones is allowed is the actual failure being tested.
What to do instead
Read the topology for what is explicitly permitted. If east-west or cross-zone traffic is allowed, the fix is default-deny between zones with explicit allow rules, not another control layer. Choose the option that changes the permit rule, not the one that adds a device.
On TLS and certificate questions, selecting 'enable TLS' as the fix when the scenario already states TLS terminates at a load balancer and traffic continues in cleartext to the backend, or when the issue is certificate validation being disabled in code.
Candidates see 'unencrypted' and reach for the encryption toggle. The tested gap is usually the segment after termination or a client that skips verification, neither of which the toggle fixes.
What to do instead
Trace where encryption starts and stops. If termination happens before the sensitive hop, the answer is re-encryption to the backend or mTLS between services. If the stem mentions disabled verification or a pinned-cert bypass, the answer restores validation, not adds a protocol.
On DNS and email-security items, picking SPF as the complete anti-spoofing answer when the stem shows a message that passed SPF but failed DMARC alignment, or choosing DKIM alone when the scenario is about the visible From header.
Candidates memorize the three records as a checklist and pick whichever appears first. They miss that SPF authenticates the envelope sender and does not survive forwarding, and that DMARC is what ties authentication to the visible From domain.
What to do instead
Map each record to what it authenticates: SPF to envelope/return-path, DKIM to a signing domain via a header, DMARC to alignment with the From header plus a policy. If the question is about spoofed visible senders, the answer involves DMARC alignment and policy, not SPF alone.
On detection and alerting items, choosing 'tune the rule' or 'disable the noisy alert' as the first response to a high false-positive rate, instead of preserving detection coverage while adding enrichment or suppression scoped to known-good behavior.
Candidates optimize for analyst comfort and pick the option that reduces volume fastest. Exam items reward coverage-preserving fixes, and blunt tuning is the distractor that looks efficient.
What to do instead
Ask whether the option removes the ability to detect the malicious case. Prefer allowlisting known-good entities, adding context or correlation, or raising fidelity, and reject options that suppress the rule globally or widen exceptions beyond the observed benign pattern.
On incident-response sequencing items, jumping to eradication or recovery (rebuild the host, restore from backup) before containment and evidence preservation, or isolating a host in a way that destroys volatile memory needed for scoping.
Candidates want to 'fix it' and the most decisive-sounding option is usually the destructive one. They also underweight the need to determine scope before evicting the attacker.
What to do instead
Order options by phase: identify and scope, contain without destroying evidence (network isolate rather than power off), preserve volatile data, then eradicate and recover. Eliminate any answer that reboots, wipes, or reimages before scope is established.
On cloud identity items, choosing long-lived access keys or a broad role because 'it works across accounts,' rather than federation with short-lived credentials and a trust policy scoped to specific principals and conditions.
Candidates carry on-premises habits (service accounts, static credentials) into cloud scenarios and undervalue the identity provider as the control point. They also miss that a role's trust policy, not just its permission policy, defines who can assume it.
What to do instead
In cloud scenarios, prefer short-lived credentials from federation or instance/workload identity, conditions on the trust policy (source account, external ID, subject), and permission sets scoped to the task. Treat any static long-lived key as a finding unless the stem shows a control that compensates.
On cloud storage and logging questions, answering 'encrypt the bucket' or 'enable versioning' when the exposure is public read access or an overly permissive bucket policy, or assuming provider-side logging is on by default and covers data-plane reads.
Candidates substitute a familiar control for the actual misconfiguration in the stem. They also assume default logging captures object-level access when it often requires explicit data-event logging.
What to do instead
Identify the specific exposure first: public ACL, public policy, missing block-public-access, or cross-account grant. Match the control to it (block public access, policy condition, signed URLs). For detection questions, confirm whether data-plane/object-level logging is explicitly enabled before assuming events exist.