CompTIA PenTest+ (PT0-002) Certification Exam Ultimate Cheat Sheet
Your Quick Reference Study Guide
This cheat sheet covers the core concepts, terms, and definitions you need to know for the CompTIA PenTest+ (PT0-002) Certification Exam. We've distilled the most important domains, topics, and critical details to help your exam preparation.
💡 Note: While this study guide highlights essential concepts, it's designed to complement—not replace—comprehensiv e learning materials. Use it for quick reviews, last-minute prep, or to identify areas that need deeper study before your exam.
About This Cheat Sheet: This study guide covers core concepts for CompTIA PenTest+ (PT0-002) Certification Exam. It highlights key terms, definitions, common mistakes, and frequently confused topics to support your exam preparation.
Use this as a quick reference alongside comprehensive study materials.
CompTIA PenTest+ (PT0-002) Certification Exam
Cheat Sheet •
About This Cheat Sheet: This study guide covers core concepts for CompTIA PenTest+ (PT0-002) Certification Exam. It highlights key terms, definitions, common mistakes, and frequently confused topics to support your exam preparation.
Use this as a quick reference alongside comprehensive study materials.
Planning and Scoping
14%ROE — Rules of Engagement (Test Boundaries & Safety)
Formal operational agreement that defines permitted techniques, targets, testing windows, escalation, and data handling.
Key Insight
ROE are binding operational and legal limits — they can prohibit methods, hours, or actions even if an exploit exists.
Often Confused With
Common Mistakes
- Treat ROE as optional guidance — they are mandatory for legal and safety protection.
- Assume ROE = scope/SOW — ROE add procedural, communication, and escalation rules.
- Perform tests outside allowed hours because a target seems weaker — this violates ROE.
Statement of Work (SOW) — Scope, Deliverables & Acceptance
Contract-adjacent document that states objectives, scope, deliverables, schedule, constraints, assumptions, and success/
Key Insight
SOW defines WHAT is to be delivered and acceptance criteria; it rarely prescribes exact tools or step-by-step methods.
Often Confused With
Common Mistakes
- Equate the SOW with the entire legal contract — SOW describes work and may be referenced by a contract.
- Expect the SOW to list every tool and technique — it focuses on outcomes and constraints, not methods.
- Assume a signed SOW is immutable — change control and amendments are common when scope shifts.
ROE & Authorization: Legal, Compliance, Change Control
Written laws, contracts and Rules of Engagement that define when/how you may test and what evidence is required.
Key Insight
Scope-specific written authorization (SOW/ROE) is required — MSAs/verbal consent don't replace explicit approval; law trumps client policy.
Often Confused With
Common Mistakes
- Assuming a signed MSA alone authorizes all testing — you still need SOW/ROE or explicit written permission.
- Beginning tests on verbal or implied consent (weak security) without documented approval and timeboxes.
- Treating a maintenance window as blanket approval — each intrusive test needs explicit sign-off and change-control entry.
PCI DSS — Cardholder Data Controls
Outcome-based security standard for any organization that stores, processes, or transmits cardholder data; it shapes scp
Key Insight
PCI covers any entity handling cardholder data (merchants & service providers); compliance is ongoing—scans/tests are evidence, not proof.
Often Confused With
Common Mistakes
- Believing PCI only applies to merchants — service providers and processors are also in scope.
- Thinking a single external scan or one pentest equals full PCI compliance.
- Assuming a PCI-compliant third party transfers all PCI responsibilities to you.
ROE — Rules of Engagement (Test Boundaries & Safety)
Formal operational agreement that defines permitted techniques, targets, testing windows, escalation, and data handling.
Key Insight
ROE are binding operational and legal limits — they can prohibit methods, hours, or actions even if an exploit exists.
Often Confused With
Common Mistakes
- Treat ROE as optional guidance — they are mandatory for legal and safety protection.
- Assume ROE = scope/SOW — ROE add procedural, communication, and escalation rules.
- Perform tests outside allowed hours because a target seems weaker — this violates ROE.
Statement of Work (SOW) — Scope, Deliverables & Acceptance
Contract-adjacent document that states objectives, scope, deliverables, schedule, constraints, assumptions, and success/
Key Insight
SOW defines WHAT is to be delivered and acceptance criteria; it rarely prescribes exact tools or step-by-step methods.
Often Confused With
Common Mistakes
- Equate the SOW with the entire legal contract — SOW describes work and may be referenced by a contract.
- Expect the SOW to list every tool and technique — it focuses on outcomes and constraints, not methods.
- Assume a signed SOW is immutable — change control and amendments are common when scope shifts.
ROE & Authorization: Legal, Compliance, Change Control
Written laws, contracts and Rules of Engagement that define when/how you may test and what evidence is required.
Key Insight
Scope-specific written authorization (SOW/ROE) is required — MSAs/verbal consent don't replace explicit approval; law trumps client policy.
Often Confused With
Common Mistakes
- Assuming a signed MSA alone authorizes all testing — you still need SOW/ROE or explicit written permission.
- Beginning tests on verbal or implied consent (weak security) without documented approval and timeboxes.
- Treating a maintenance window as blanket approval — each intrusive test needs explicit sign-off and change-control entry.
PCI DSS — Cardholder Data Controls
Outcome-based security standard for any organization that stores, processes, or transmits cardholder data; it shapes scp
Key Insight
PCI covers any entity handling cardholder data (merchants & service providers); compliance is ongoing—scans/tests are evidence, not proof.
Often Confused With
Common Mistakes
- Believing PCI only applies to merchants — service providers and processors are also in scope.
- Thinking a single external scan or one pentest equals full PCI compliance.
- Assuming a PCI-compliant third party transfers all PCI responsibilities to you.
Information Gathering and Vulnerability Scanning
22%Port Scans: SYN (Stealth) · TCP Connect · UDP · Masscan
Know packet behavior, detectability, and speed trade-offs to choose the right scan under the rules of engagement.
Key Insight
SYN = half-open (faster/stealthier but still logged); TCP connect needs no raw sockets; UDP is lossy; Masscan trades accuracy for speed.
Often Confused With
Common Mistakes
- Treating SYN scans as invisible to IDS/IPS
- Expecting UDP scans to reliably discover every UDP service
- Assuming higher scan speed always yields correct results
Service & Version Fingerprinting (Banners + Probes)
Active and passive probes plus signature databases used to identify service software and narrow vulnerability candidates
Key Insight
Banners and probe signatures suggest likely versions but can be forged or ambiguous — always validate with behavior and CVE checks.
Often Confused With
Common Mistakes
- Treating banner strings as definitive product/version
- Assuming an open well-known port guarantees the standard service
- Using fingerprint matches alone to claim exploitability
Authenticated vs Unauthenticated Scans (Credentialed / Non‑credentialed)
Scans with valid creds vs without — credentialed finds deeper config/privilege issues; non‑credentialed shows attacker‑f
Key Insight
Credentialed scans increase visibility and reduce some false positives but can change system state and miss external/network exposures; run both and记录
Often Confused With
Common Mistakes
- Assuming credentialed scans find every vulnerability
- Believing credentialed scans eliminate all false positives
- Using high‑privilege creds (e.g., Domain Admin) without least‑privilege or documentation
Passive vs Active Recon (OSINT vs Probing)
Non‑interactive OSINT/traffic observation vs interactive probes — passive lowers noise, active verifies and digs deeper.
Key Insight
Passive is low‑noise but incomplete and can still require permission; active gives verification/detail but is noisy and needs explicit authorization.
Often Confused With
Common Mistakes
- Assuming passive recon is always legal and needs no authorization
- Relying only on passive data for exploitation decisions without authorized verification
- Thinking active recon always guarantees detection — it raises likelihood but depends on defenders' controls
Attacks and Exploits
30%XSS — Script Injection (Stored / Reflected / DOM)
Browser-side script injection from untrusted input; used to steal sessions, deface pages, or run actions as the user.
Key Insight
Stored = payload saved server-side; reflected = echoes in response; DOM = client-only JS. Fix with contextual output encoding, not just input checks.
Often Confused With
Common Mistakes
- Relying on input validation alone — you must apply contextual output encoding/escaping.
- Thinking HttpOnly cookies stop all XSS impact — they block cookie JS theft but not other JS-driven attacks.
- Treating DOM XSS as a server bug — it’s a client-side JS issue; audit DOM sinks and scripts.
SQLi — Database Injection (Error / UNION / Boolean/Blind)
Injected SQL fragments alter backend queries to exfiltrate data, bypass auth, or manipulate DB state.
Key Insight
Error/UNION return data directly; boolean/time-based (blind) require inference; test all inputs (forms, headers, cookies, URLs).
Often Confused With
Common Mistakes
- Assuming client-side validation prevents SQLi — attackers bypass client checks easily.
- Treating prepared statements as infallible — concatenating unchecked strings still creates risk.
- Believing stored procedures remove SQLi risk — dynamic SQL inside procedures can be vulnerable.
LOTL (Living-off-the-Land) & Fileless Techniques
Abuse built-in OS tools and in-memory payloads (PowerShell, WMI, regsvr32) to evade disk-based detection.
Key Insight
No disk footprint ≠ invisible — detect by abnormal built-in tool usage, suspicious cmdlines, process ancestry, and memory artifacts.
Often Confused With
Common Mistakes
- Assuming 'fileless' means zero disk activity (helpers, temp files, or logs can still appear).
- Thinking LOTL is harmless because it uses legitimate OS tools.
- Believing signature AV is useless — EDR/behavioral and memory detections can catch fileless activity.
Mimikatz — Windows Credential Extraction
Extracts plaintext passwords, NTLM hashes, and Kerberos tickets from Windows memory for privilege escalation and lateral
Key Insight
Targets LSASS/process memory; can work on many Windows hosts and sometimes without SYSTEM — watch for LSASS access, token ops, and dump artifacts.
Often Confused With
Common Mistakes
- Assuming Mimikatz only works on domain controllers.
- Believing it always requires SYSTEM privileges to extract credentials.
- Thinking antivirus will always detect and block Mimikatz.
Timeboxing & Scheduling (Windows, Blackouts, Rollbacks)
Set test dates, daily windows, blackout periods, rollback plans and stakeholder contacts to avoid business impact.
Key Insight
A scheduled window only reduces risk when paired with tested rollback, monitoring and full stakeholder coordination.
Often Confused With
Common Mistakes
- Assuming a maintenance window eliminates all outage risk
- Not informing business owners and downstream stakeholders
- Treating blackout periods as licence for unchecked passive or active testing
Exploit Selection & Staged Validation (Safe PoC)
Map vulnerabilities to tailored exploits and validate them in staged, monitored steps with rollback gates for non‑destr.
Key Insight
Public exploits rarely work unchanged—validate incrementally, monitor side effects, and require rollback before escalation.
Often Confused With
Common Mistakes
- Using a public exploit 'as‑is' without environment checks or tweaks
- Escalating privileges immediately after initial success without containment
- Skipping rollback/containment because expected impact seems minimal
Reporting and Communication
18%Scope & RoE (Rules of Engagement)
Defines in-scope/out-of-scope assets, allowed actions, timeframes and constraints that legally bound tests.
Key Insight
Findings are judged against the signed scope—unauthorized or out-of-scope testing must be preapproved or excluded.
Often Confused With
Common Mistakes
- Treating scope as mere paperwork—ignoring its legal/operational limits when reporting.
- Testing or reporting on out-of-scope assets without documented approval.
- Assuming admin/privileged actions are allowed unless explicitly listed in scope.
PenTest Reports & Deliverables
Audience-tailored deliverables (exec→technical): scope, findings, evidence, impact, prioritized remediation, and verif.
Key Insight
Match deliverable to audience: execs need impact/priorities; tech teams need evidence, repro steps, CVSS, and concrete fixes.
Often Confused With
Common Mistakes
- Using one report format for execs and technicians—failing to tailor content and detail.
- Dumping raw logs/screenshots into executive briefings instead of summarized impact.
- Treating interim or draft reports as final and skipping remediation verification steps.
Findings Debrief: Prioritize, Prove, Persuade
Deliver tailored, evidence-backed briefings with root-cause analysis, prioritized fixes, and action items per audience.
Key Insight
Match evidence to audience: execs get business impact and priorities; tech teams get PoC, logs, and step-by-step fixes.
Often Confused With
Common Mistakes
- One-size-fits-all brief — execs vs ops need different evidence/detail.
- Prioritizing only by CVSS; ignore business impact and exploitability.
- Deliver report then skip live debrief/Q&A — loses buy-in and clarity.
Trigger & Escalation Playbook
Predefine what to notify, when, how, and who: criteria, channels, timelines, and required notice content.
Key Insight
Triggers are not only technical — include contractual, legal, safety, and business-impact thresholds plus required evidence and mitigations.
Often Confused With
Common Mistakes
- Reporting every finding immediately to all stakeholders — causes noise and alert fatigue.
- Using only technical severity; ignore contractual/legal/safety thresholds.
- Treating escalation as a contact list only — omit thresholds, timelines, and required actions.
Tools and Code Analysis
16%Vulnerability Scanning — Scope & Limits
Automated and manual discovery of known weaknesses; produces findings, risk scores, and remediation evidence.
Key Insight
Scanners catch known technical flaws but routinely miss zero‑days, business‑logic, and context-specific issues.
Often Confused With
Common Mistakes
- Expecting one scan to find all vulnerabilities — scanners miss zero‑days, logic, and config issues.
- Interpreting scanner severity as automatic exploitability — check context and attack path.
- Running scans without explicit authorization — scans can be unsafe and legally prohibited.
Nmap — Scan Types, NSE & Timing
Network host/port/service discovery and OS/version fingerprinting; tune scan types, timing, and use NSE for checks.
Key Insight
Scan type, timing, and NSE choices change detectability and accuracy — aggressive options can reveal more but increase noise/risk.
Often Confused With
Common Mistakes
- Believing SYN (-sS) is invisible — it can still be logged or detected by IDS.
- -sV always gives exact service/version info — results can be incomplete or misleading.
- Trusting -O as definitive OS ID — OS detection is probabilistic and can be wrong.
Scan Result Triage & Prioritization
Verify scanner output, classify true/false positives, and prioritize findings by exploitability and business risk.
Key Insight
Validate evidence first — exploitability and business context outweigh a raw CVSS score when setting priority.
Often Confused With
Common Mistakes
- Accepting scanner findings without manual validation.
- Assuming no alert means the asset or code is secure.
- Prioritizing only by CVSS and ignoring exploitability/context.
OWASP: Web & API Risk Playbook
Community security guidance: Top Ten risk categories, testing guides, and remediation best practices for web and APIs.
Key Insight
OWASP is community guidance, not law — use the Top Ten as a prioritized snapshot and adapt tests to your app/API context.
Often Confused With
Common Mistakes
- Treating the OWASP Top Ten as an exhaustive list of vulnerabilities.
- Using OWASP as a formal compliance or legal standard.
- Relying solely on OWASP tools; they won't find every vuln or cover APIs/SPAs fully.
Certification Overview
Cheat Sheet Content
Similar Cheat Sheets
- CCNA Exam v1.1 (200-301) Cheat Sheet
- AWS Certified Cloud Practitioner (CLF-C02) Cheat Sheet
- AWS Certified AI Practitioner (AIF-C01) Cheat Sheet
- Exam AI-900: Microsoft Azure AI Fundamentals Cheat Sheet
- Google Cloud Professional Cloud Architect Cheat Sheet
- Google Cloud Security Operations Engineer Exam Cheat Sheet