Printable referenceCurrent-track reviewIndependent study resource

PenTest+ cram sheet and exam-day checklist

An authorization-first final-review reference for scoping, reconnaissance, vulnerability validation, exploit concepts, post-exploitation boundaries, and remediation-focused reporting.

This is an independently authored study aid, not official CompTIA material. It does not contain recalled, leaked, copied, or live-exam questions and is not affiliated with or endorsed by CompTIA.

Back to PenTest+ study guideTake the free practice test
Current reviewed track

Check the maintained exam record before final review.

Exam identity, timing, scoring, domain weighting, recommended experience, and the next review date are rendered from Zeph Tech's certification registry. The quick-reference material below focuses on durable reasoning and troubleshooting patterns rather than copying volatile logistics throughout the page.

Active

  • Exam: PT0-003
  • Version: V3
  • Questions: Maximum of 90 questions
  • Item types: multiple-choice, performance-based
  • Time: 165 minutes
  • Passing score: 750 on a 100–900 scale
  • Recommended background: 3–4 years in a penetration tester job role, with Network+ and Security+ or equivalent knowledge
  • Renewal: Three-year CompTIA Continuing Education cycle

Last verified: 2026-09-25

Next review: 2026-10-25

Official certification page · Official exam objectives

Published domain weighting

  • Engagement Management13%
  • Reconnaissance and Enumeration21%
  • Vulnerability Discovery and Analysis17%
  • Attacks and Exploits35%
  • Post-exploitation and Lateral Movement14%

Engagement management

  • Written scope controls: asset ownership does not automatically authorize testing.
  • Rules of engagement: record permitted techniques, hours, source addresses, contacts, stop conditions, prohibited actions, and data handling.
  • Third parties: cloud, SaaS, ISP, and hosting dependencies may require separate authorization.
  • Safety: production instability, sensitive data, denial-of-service risk, and destructive actions need explicit limits.
  • Closeout: remove tester-created artifacts as agreed, protect evidence, and document anything intentionally retained.

Reconnaissance and enumeration

  • Passive first when appropriate: public DNS, certificate, registration, repository, metadata, and organizational sources can reduce uncertainty without active interaction.
  • Fingerprinting is probabilistic: corroborate service, version, operating-system, and ownership evidence.
  • Scope every discovery: a new host, domain, IP, or cloud resource is not automatically approved for testing.
  • Enumerate with purpose: collect evidence that changes a hypothesis or attack path rather than scanning indiscriminately.
  • Document confidence: separate observed facts from likely relationships and assumptions.

Vulnerability analysis

  • Validate scanner output: banner or signature matches can be wrong, incomplete, backported, or mitigated.
  • Attack path matters: exposure, authentication, privilege, reachable feature, and compensating controls shape practical risk.
  • Server-side controls: authorization, input handling, output encoding, parameterization, secrets, and configuration are recurring root causes.
  • Minimal proof: demonstrate the boundary failure without modifying or extracting more data than necessary.
  • Report evidence: preconditions, affected asset, reproducible behavior, impact, remediation, and retest result.

Post-exploitation and reporting

  • Least privilege: broad service accounts and reusable credentials increase lateral-movement paths.
  • Trust map: connect identities, secrets, management planes, network segments, data stores, and administrative paths.
  • Persistence is not a goal: only use techniques explicitly allowed by the engagement and needed to demonstrate risk.
  • Cleanup: remove test accounts, artifacts, and temporary access according to the rules of engagement.
  • Executive reporting: explain business consequence and remediation priority without overstating what the evidence proves.

Authorization is part of the technical answer

PenTest+ questions often contain a tempting technical action that becomes wrong because the engagement does not authorize it. Treat scope as a control boundary. If you discover a new subsidiary domain, cloud tenant, wireless network, partner system, or production dependency, stop and determine whether the written authorization actually covers it. Ownership, public accessibility, or technical reachability does not substitute for permission.

The rules of engagement should make operational risk explicit. Know the test window, approved source addresses, communication path, prohibited techniques, credential constraints, data-handling requirements, social-engineering permissions, denial-of-service limitations, emergency contacts, and stop-work conditions. When a production service becomes unstable, following the agreed escalation and safety process takes priority over completing one more test case.

Evidence handling matters from the beginning. Decide what needs to be retained, how sensitive client data will be protected, where screenshots or logs will be stored, who may access them, and how temporary artifacts will be cleaned up. A finding can be technically valid and still be professionally mishandled if evidence collection creates unnecessary exposure.

Reconnaissance and vulnerability analysis: prove what you actually know

Separate passive discovery, active discovery, enumeration, vulnerability identification, and exploit validation. Public certificate transparency can suggest hostnames; DNS can show current records; service responses can provide banners; authenticated assessment can reveal patch and configuration state. Each source has limitations. Do not turn a weak signal into a definitive statement when another safe check can corroborate it.

Scanner severity is not the same as validated exploitability. Before reporting a critical path, confirm the affected product or feature, version evidence, reachable interface, authentication requirement, privileges required, mitigation state, and actual security boundary. Backported fixes, disabled features, reverse proxies, virtual hosting, and compensating controls can all make a signature-based result misleading.

When validating web and API issues, identify the violated boundary. Injection means untrusted input changes downstream command or query meaning. Broken object authorization means the server fails to verify the requesting identity may access the specific resource. Cross-site scripting means attacker-controlled content reaches a browser execution context without the required handling. The strongest report describes the failed control and a safe reproduction, not an unnecessarily destructive exploit chain.

Attack-path reasoning: think in prerequisites, privileges, and blast radius

For exploitation concepts, list prerequisites before tools. Does the path require network reachability, a valid account, a specific role, user interaction, a vulnerable configuration, local access, or a trusted relationship? Then identify what the successful step grants: code execution, data access, authentication bypass, privilege escalation, credential exposure, or control of another trust boundary. This keeps the analysis tied to impact rather than to technique names.

Post-exploitation questions are strongest when modeled as trust relationships. A credential in a configuration file matters because of what that identity can reach. A service account with broad administrative rights matters because compromise expands blast radius. A flat management network matters because one foothold can expose multiple control planes. Remediation should break the path with scoped identity, credential protection, segmentation, hardening, or monitored administrative access.

Always prefer the minimum action required to establish the finding. If reading a harmless test record proves an authorization failure, modifying production customer data adds risk without improving the core evidence. If a limited command proves code execution, persistence may be unnecessary. Professional testing is not about demonstrating the largest possible consequence; it is about proving enough to support a defensible remediation decision.

Reporting and retest: make the deliverable more useful than the exploit

A useful finding starts with scope and preconditions, then explains the observed behavior, affected asset or component, realistic impact, evidence, and remediation. Separate confirmed behavior from plausible escalation. If a scanner found a vulnerable version but you could not safely validate exploitability, say so. If a compensating control blocked the attack path, document both the weakness and the control context rather than pretending either one does not exist.

Write remediation at the correct layer. Broken authorization requires server-side access control, not hiding a button. SQL injection requires parameterized queries and safe data handling, not merely suppressing database errors. Exposed management interfaces require restricted administrative paths and strong identity controls, not just longer passwords. Root-cause recommendations make retesting clearer and reduce recurrence.

Retest the original condition after remediation. Confirm the vulnerable behavior is no longer possible under the same preconditions and that the fix did not merely move the symptom. Close the engagement by cleaning up test artifacts, protecting retained evidence, and documenting unresolved risk. On exam questions, reporting and cleanup are not administrative trivia; they are part of a complete penetration-testing lifecycle.

Exam-day method

Use the qualifiers and constraints before reaching for a memorized answer.

  • Read the command word first: FIRST, NEXT, BEST, MOST likely, and LEAST change the decision you are being asked to make.
  • Identify the objective and the constraint before evaluating products or commands. Several answers may be technically possible while only one fits the scope, evidence, safety, availability, or least-privilege requirement.
  • When two options seem correct, prefer the one that creates useful evidence, preserves reversibility, reduces unnecessary impact, and addresses the stated layer of the problem.
  • Do not use a practice percentage as a pass prediction. Treat missed or guessed questions as pointers to weak concepts and decision patterns, then verify the current objectives with the certification owner.
  • For performance-based thinking, practice the workflow rather than memorizing a screenshot: establish state, choose a safe action, interpret the result, and verify that the original requirement is now satisfied.

Use this cram sheet after full study and hands-on practice. CompTIA's current certification page and objectives remain the authority when any exam fact changes.