Use this cheat sheet for CompTIA PenTest+ (PT0-003) after you know the tools and need better engagement judgment. PenTest+ questions reward authorized, scoped, low-disruption testing with evidence that proves impact and remediation that a defender can act on.
PT0-003 answer sequence
Use this when the stem mixes authorization, phase, scope, proof, or cleanup.
flowchart TD
S["Scenario"] --> A["Confirm authorization and scope"]
A --> P["Identify the engagement phase"]
P --> S2["Choose the safest proof method"]
S2 --> C["Preserve evidence and clean up"]
Read every PenTest+ question in this order
- Confirm authorization, scope, timing, and rules of engagement.
- Identify the phase: planning, recon, enumeration, vulnerability analysis, exploitation, post-exploitation, cleanup, or reporting.
- Choose the safest method that proves the requirement without exceeding scope.
- Preserve evidence and avoid unnecessary disruption.
- Connect the finding to impact, likelihood, remediation, and retest.
Planning and scoping
| Requirement |
Strong answer pattern |
| permission to test |
written authorization, signed agreement, and approved scope |
| target boundaries |
IPs, domains, applications, accounts, cloud assets, dates, and exclusions |
| test constraints |
rate limits, blackout windows, production safety, social engineering rules |
| communication |
escalation contacts, emergency stop, status cadence, and incident handling |
| success criteria |
objectives, deliverables, reporting format, severity model, and retest expectations |
| legal risk |
do not test outside scope even if technically possible |
Reconnaissance and enumeration
| Need |
Better approach |
| low-noise initial info |
passive OSINT, DNS records, certificate transparency, public repos, metadata |
| service discovery |
controlled scanning aligned with rules of engagement |
| web app mapping |
directories, parameters, authentication flow, roles, session behavior |
| cloud surface |
exposed storage, IAM clues, metadata exposure, public endpoints |
| identity target |
users, groups, email patterns, password policy clues |
| enumeration proof |
record command, time, target, result, and scope alignment |
Vulnerability validation
| Scanner says… |
Analyst should… |
| critical CVE |
validate version, exposure, exploitability, compensating controls, and safe proof |
| default credentials |
test only within rules; document evidence without exposing secrets unnecessarily |
| SQL injection |
verify input, impact, data access, and safe payload handling |
| XSS |
identify reflected/stored/DOM context and business impact |
| weak TLS |
show affected endpoint, protocol/cipher issue, and remediation |
| misconfiguration |
prove actual exposure or plausible attack path |
Exploitation and post-exploitation
| Scenario |
Better instinct |
| exploit could crash service |
use safer validation or get explicit approval |
| shell obtained |
document proof, limit actions, avoid persistence unless authorized |
| privilege escalation possible |
prove impact minimally and record path |
| credentials found |
protect them, avoid unnecessary reuse, and report handling |
| lateral movement |
stay within scope and track every accessed system |
| data access proof |
use minimal sample evidence and protect sensitive data |
Cleanup and restoration
| Artifact |
Expected cleanup |
| test account |
disable or remove as agreed |
| payload or web shell |
remove and verify removal |
| changed config |
restore prior state or document approved change |
| logs and evidence |
preserve according to engagement terms |
| credentials |
report exposure and recommend rotation |
| temporary files |
remove safely without destroying client-owned evidence |
Reporting
| Report element |
What it should answer |
| finding |
what weakness exists? |
| evidence |
how was it validated? |
| impact |
what could an attacker do? |
| likelihood |
how reachable and practical is exploitation? |
| remediation |
what specific fix reduces risk? |
| retest |
how should closure be verified? |
| executive summary |
what business risk matters most? |
Common traps
| Trap |
Better instinct |
| exploit before scope |
authorization and rules of engagement come first |
| scanner output as final report |
validate and explain exploitability |
| maximum-impact proof |
prove enough, not more than necessary |
| persistence by default |
only if explicitly authorized |
| cleanup ignored |
leave the environment stable and documented |
| report full of commands only |
convert evidence into risk, impact, and remediation |
Final 15-minute review
| If the stem says… |
Start here |
| new engagement |
scope, authorization, contacts, rules, and deliverables |
| passive information |
OSINT, DNS, public repos, certs, metadata |
| vulnerable service |
validate safely, document proof, avoid outage |
| web application |
auth flow, input handling, session, roles, and business impact |
| post-exploitation |
least action, evidence, scope, cleanup, and disclosure control |
| final report |
severity, evidence, impact, remediation, retest |
Practice fit
Use IT Mastery for the exact product route, practice status, spaced review when available, and close-answer explanation practice as coverage expands.
One-line decision rule
PenTest+ answers should stay authorized, scoped, safe, validated, documented, and remediation-focused.