LPF LPQ common mistakes
LPF LPQ · Understand the traps and how to avoid them.
When asked what to do before active scanning, the candidate jumps straight to describing nmap flags and scan types instead of first confirming the signed scope/authorization document, rules of engagement, and test window.
Candidates study tooling far more than governance, and the exam's scenario questions reward sequencing; the habit of 'scan first' from lab practice overrides the methodology the question is testing.
What to do instead
For any 'what is the FIRST step' item, run a mental checklist: authorization and scope signed, rules of engagement agreed, emergency contacts and test window confirmed, then reconnaissance, then active scanning. Practice by writing the pre-engagement sequence from memory until it is automatic.
On recon questions, the candidate treats active scanning (port scans, banner grabs) as 'reconnaissance' and cannot distinguish it from passive OSINT such as certificate transparency logs, WHOIS, DNS records, and search engine dorking.
The word 'recon' is used loosely in tutorials, so the passive/active boundary and the footprinting-versus-scanning distinction never get fixed in memory.
What to do instead
Build a two-column table: passive sources (CT logs, WHOIS/RWHOIS, DNS zone data, Shodan, social media, job postings, leaked credentials) versus active sources (port scans, service/version detection, zone transfer attempts, web crawling that touches the target). Classify ten example activities before checking answers.
The candidate reads a scenario about a discovered vulnerability and immediately writes 'exploit it and escalate' rather than weighing impact, likelihood, business context, and the agreed scope before deciding whether exploitation is appropriate.
Exploitation is the most exciting part of the material, so candidates pattern-match 'vulnerability found' to 'exploit found' and skip the risk-judgment step the question is really testing.
What to do instead
For exploitation decisions, apply a fixed sequence: confirm the asset is in scope, assess business criticality and potential outage risk, choose the least invasive proof (e.g., a benign command or screenshot rather than a destructive payload), and document the decision. Rehearse with 'what would you do if this were a production database' style scenarios.
When a question describes a web input reflected into a page, the candidate labels it generically as 'XSS' without distinguishing reflected, stored, and DOM-based variants, or confuses it with SQL injection or CSRF.
The categories blur because they share the same entry point (user-controlled input) and candidates memorize payloads rather than the data-flow and trust-boundary differences.
What to do instead
Learn each class by its data flow: reflected XSS returns in the immediate response, stored XSS persists server-side, DOM-based XSS executes via client-side sinks without server reflection; SQLi alters a query; CSRF abuses ambient credentials on a state-changing request. For each, be able to state the source, sink, and a one-line fix.
The candidate answers wireless questions by recommending WPA3 or 'stronger encryption' as the fix for an evil-twin or rogue access point, missing that the attack targets client behavior and credential capture rather than the cipher.
Encryption strength is the most rehearsed wireless fact, so it becomes a default answer even when the threat model is a fake AP or deauthentication/association attack.
What to do instead
Map each wireless threat to its actual control: evil twin and rogue AP to client-side certificate validation, WIPS, and user awareness; deauth to management frame protection (802.11w); weak PSK to passphrase strength and WPA3-SAE. Practice matching threat to control rather than to algorithm.
On reporting questions, the candidate lists findings as raw tool output (severity scores, CVE IDs, screenshots) without business impact, affected asset context, reproduction steps, or a prioritized remediation recommendation.
Candidates equate a finding with a report and underestimate how much of the exam tests communication to non-technical stakeholders.
What to do instead
Structure every finding as: title, affected asset, technical description, evidence/reproduction, business impact in plain language, severity with justification, and specific remediation with owner. Write one sample finding end-to-end and check it contains all seven elements.
When asked about handling sensitive data found during a test (customer records, credentials, PII), the candidate says to 'collect it as evidence' or 'keep it for the report' rather than minimizing collection, protecting it, and following data-handling and retention rules.
Evidence collection is emphasized in practical training, while data minimization and confidentiality obligations feel like legal trivia and get skipped.
What to do instead
Adopt the rule: collect the minimum needed to prove the finding, store it encrypted with restricted access, never exfiltrate real customer data beyond what is agreed, and delete or return it per the engagement terms. Be ready to cite confidentiality, data protection, and retention obligations in the answer.
The candidate treats a 'scope' question as purely technical and forgets that out-of-scope systems (third-party SaaS, shared hosting neighbors, cloud provider infrastructure) must be excluded even when reachable and vulnerable.
Technical reachability feels like permission in lab environments, and candidates rarely practice reading scope documents that carve out third parties and shared infrastructure.
What to do instead
Memorize the principle that authorization, not connectivity, defines scope. When a scenario mentions a shared host, cloud tenant, or third-party service, explicitly state that testing stops at the boundary and that written permission from the third party is required. Practice by annotating a sample scope statement with what is and is not permitted.
On post-exploitation questions, the candidate describes privilege escalation and lateral movement but omits cleanup, evidence preservation, and restoring the environment to its pre-test state.
The exciting phases dominate study time, and cleanup is treated as an afterthought rather than a defined phase of the methodology.
What to do instead
Add a closing phase to your mental model: remove shells, accounts, scheduled tasks, and uploaded tools; verify the environment is restored; log all changes; and confirm with the client. For any post-exploitation scenario, end your answer with cleanup and documentation.
The candidate misidentifies the layer or protocol involved in a network scenario, for example blaming a firewall for an ARP spoofing issue or describing a VLAN hop as a routing problem, because they memorize attack names without the underlying protocol behavior.
Tool-centric study leaves gaps in how ARP, DHCP, VLANs, DNS, and TLS actually behave, so the attacker's position in the stack is guessed.
What to do instead
For each common network attack (ARP spoofing, DHCP starvation/rogue server, VLAN hopping, DNS spoofing, on-path TLS interception), state the protocol abused, the layer, the precondition, and the defensive control (dynamic ARP inspection, DHCP snooping, native VLAN and trunk hardening, DNSSEC, certificate pinning). Drill this four-part mapping until it is fluent.