CompTIA PenTest+ common mistakes
CompTIA PenTest+ · Understand the traps and how to avoid them.
Writing the report as a flat list of tool output (Nmap ports, scanner CVE IDs) rather than linking each finding to the client's business risk, the affected asset, and a reproducible proof of concept.
Candidates practice exploitation and treat reporting as an afterthought, so they dump raw output at the end. PenTest+ weights the engagement-management and reporting lifecycle heavily; graders and scenario questions reward findings that state impact, likelihood, and remediation.
What to do instead
Adopt a fixed finding template and rehearse it: title, affected asset, evidence (exact command and output excerpt), business impact in the client's terms, CVSS or risk rating with justification, and a specific remediation with owner. Practice converting three raw scanner findings into this format before exam day.
Skipping the scoping and authorization artifacts and jumping straight to technical work when a scenario describes a new engagement.
Technical candidates find contracts and rules of engagement boring, so they skim past scope, target lists, testing windows, and emergency contacts. Scenario questions often hinge on whether an action was authorized, and the answer usually depends on those documents.
What to do instead
Memorize the contents and purpose of each artifact: statement of work, master service agreement, rules of engagement, and authorization letter. For any scenario, first identify the authorized targets, time window, and escalation path, then evaluate whether the proposed action fits inside them.
Treating reconnaissance as a single tool run and never pivoting from passive OSINT to active enumeration of the discovered surface.
Candidates learn one workflow (run a scanner, read results) and stop when the first tool returns data. Real engagements require correlating certificate transparency, DNS records, and public code repositories into a target list before touching the network.
What to do instead
Practice a chained workflow: passive collection first (DNS and certificate data, search engines, public repositories, metadata), then build an asset inventory, then active enumeration against only in-scope assets. Be able to explain what each source reveals and how it feeds the next step.
Assuming non-standard ports hide services, or trusting default-port assumptions instead of verifying service banners and protocol behavior.
Candidates memorize port-to-service mappings and then fail questions where a service runs on an unusual port or a banner is spoofed. Enumeration questions test whether you validate the service, not just the port number.
What to do instead
Always describe enumeration as version and banner interrogation plus protocol-specific probing (for example, HTTP response headers, TLS certificate subject, SMB dialect negotiation). When a scenario shows a mismatch between port and banner, state that the banner must be verified with protocol-specific requests before conclusions are drawn.
Reporting every scanner signature as a confirmed vulnerability without validation or false-positive triage.
Automated scanners produce version-based guesses and heuristic findings. Candidates who equate scanner output with truth miss questions about validation, and in practice they flood reports with noise that damages credibility.
What to do instead
For each candidate finding, require manual confirmation: reproduce the behavior, capture the request and response, and check whether compensating controls change exploitability. Learn to classify findings as confirmed, likely, or false positive and to document the evidence for each classification.
Scoring findings by CVSS base score alone and ignoring environmental and contextual factors when prioritizing.
Candidates memorize the base metric groups and stop there. Exam scenarios frequently present a medium base score on an internet-facing, business-critical asset versus a high base score on an isolated lab host, and expect contextual reasoning.
What to do instead
Learn the difference between base, temporal, and environmental metrics, and practice adjusting a score for exploit maturity, required privileges, user interaction, and asset criticality. Be ready to justify why a lower-scored finding might be remediated first.
Describing an exploit technique without stating the preconditions (credentials, network position, user interaction, version constraints) that make it work.
Candidates focus on the payload or tool invocation and skip the setup. Scenario questions often change one precondition and expect you to recognize the attack no longer applies.
What to do instead
For every technique you study, write a one-line precondition checklist: access level required, authentication state, network reachability, target configuration, and detection surface. Rehearse explaining why the same technique succeeds in one scenario and fails in another.
Confusing the mechanics of a class of attack, for example mixing up reflected, stored, and DOM-based cross-site scripting, or SQL injection variants, when selecting the correct payload or mitigation.
Candidates learn payloads by memorization without understanding the data flow. Under time pressure, superficially similar categories blur together, and the chosen answer addresses the wrong variant.
What to do instead
For each major web and network attack class, map the data flow: where input enters, where it is stored, where it is rendered or executed, and which control blocks it. Pair each variant with its distinct mitigation (output encoding versus parameterized queries versus content security policy) so the categories stay separate.
Stopping at initial access and not planning privilege escalation, credential access, and lateral movement as a sequence with cleanup and evidence handling.
Candidates treat exploitation as the finish line. Post-exploitation questions test whether you understand objective-driven movement, persistence tradeoffs, and the operational discipline of not leaving artifacts behind.
What to do instead
Practice narrating a full kill chain from a foothold: local enumeration, privilege escalation path, credential or token reuse, lateral movement target selection, and cleanup. For each step, state the objective, the evidence it would create, and how you would remove or document it per the rules of engagement.
Ignoring communication and cleanup obligations after a critical finding, such as discovering sensitive data or causing an outage, instead of following the escalation and stop conditions in the rules of engagement.
Candidates focus on technical success and forget that engagement management continues through execution. Questions about out-of-scope discoveries, accidental service disruption, or handling of regulated data test whether you know when to pause and notify.
What to do instead
Memorize the standard escalation triggers: discovery of out-of-scope sensitive data, evidence of a real compromise, accidental denial of service, and any action exceeding authorized scope. For each, know the expected response: stop, preserve evidence, notify the designated contact, and document the timeline.