PenTest+ is a methodology exam. It tests whether you can run an authorised penetration test properly from first client conversation to final report, and only one of its five domains is about attacking things. This guide is built as a full self-study course around that structure: it walks through each PT0-003 domain in depth, explains the reasoning the scenario questions are built on, and then turns the material into a week-by-week plan and a description of exam day.
Two boundaries apply throughout. Everything here is written for authorised, in-scope testing only, so the course explains what each technique category is for, what its output means and how a defender sees it, and deliberately contains no operational attack instructions, commands or payloads. And it contains study guidance and original explanations only, with no reproductions of test content. Always confirm the current domains and weights against CompTIA’s official PenTest+ page before you book.
Chapter 1: Exam overview and how to use this guide
What PenTest+ actually measures
PenTest+ measures whether you can conduct and communicate a professional penetration test, not whether you can compromise one particular machine. The current version, PT0-003, organises the exam into five domains with these official weights: Engagement management at 13%, Reconnaissance and enumeration at 21%, Vulnerability discovery and analysis at 17%, Attacks and exploits at 35%, and Post-exploitation and lateral movement at 14%.
Read those weights carefully, because most candidates read them wrong. Attacks and exploits is indeed the largest single domain, but the three “process” domains around it, engagement management, reconnaissance and enumeration, and post-exploitation, add up to 48%. Nearly half the exam is about how a test is scoped, sequenced, documented and closed out. That is the deliberate identity of this certification, and it is why it is worth taking even if you already know how attacks work.
The exam is up to 90 questions in 165 minutes, mixing multiple choice with performance-based questions (PBQs), and you need a scaled 750 out of 900 to pass. That is a generous time allowance compared with other CompTIA exams, and it exists because the performance-based items ask you to work through something rather than pick a term.
Why it is a judgement exam
Most PT0-003 questions describe a situation during an engagement and ask what you should do next, or what a piece of output means. Two options will often both be technically possible, and the better one reflects testing judgement: staying inside scope, choosing the technique that answers the client’s actual question, gathering evidence you can defend in a report, and doing the least damage necessary to prove a finding. This is why memorising tool names is a weak strategy. Know what a category of tool is for, what its output looks like, and what you would conclude from it.
How to use this course
Read the chapters in order. Chapter 2 sets up engagement management, which frames everything after it, and the attack chapter assumes the reconnaissance and vulnerability vocabulary built before it. Treat the bold terms as a checklist you can explain in one sentence. Pair every chapter with lab work in an environment you own or a purpose-built vulnerable practice range, because the performance-based questions reward having actually looked at output. Then use the final chapters to convert all of it into a schedule.
A standing note on authorisation
Everything in PenTest+ exists inside a signed agreement. You test only what you own or what you have explicit written permission to test, within the agreed window, from the agreed source, using the agreed techniques. The exam tests that boundary directly and repeatedly, and this guide keeps to the same line: it teaches what techniques are and why they work at a conceptual level, never how to execute them against a system.
Chapter 2: Engagement management (13%)
This domain is what separates PenTest+ from purely technical offensive certifications. It covers everything around the testing itself, and it is where questions are most often lost by people who are technically strong.
Pre-engagement and scoping
An engagement begins with agreement, not with tooling. Scoping defines what is being tested, which addresses, domains, applications, cloud tenants or physical sites are in and out, what techniques are permitted, when testing may run, and who is authorised to approve changes. The rules of engagement (RoE) put that in writing along with escalation contacts and stop conditions. Supporting documents you should recognise are the statement of work (SOW), which defines deliverables and commercial terms, the master service agreement (MSA), which sets the standing legal relationship, and the non-disclosure agreement (NDA), which protects what you discover.
Two scoping distinctions come up constantly. First, known-environment, partially known and unknown-environment testing (the older white, grey and black box terms) describe how much information the client shares, and each is a trade-off between realism and coverage. Second, the threat model you are simulating, an external attacker, a compromised employee, a malicious insider, determines the starting position and the techniques that make sense. As a teaching illustration of scoping judgement: if a client asks whether their internal file server can be reached from the guest wifi, an unknown-environment external test answers the wrong question.
Authorisation, legal and compliance considerations
Authorisation must come from someone with the authority to give it, in writing, before testing begins. Where assets are hosted or managed by a third party, such as a cloud provider or a shared hosting company, the client’s permission alone may not be enough and the provider’s own testing policy applies. Regulated data adds further constraints: an engagement touching payment card data, health records or personal data under privacy law will restrict how you handle, transmit and store anything you extract. The exam expects you to notice when a scenario has crossed into needing extra approval and to answer with “stop and confirm” rather than “proceed carefully”.
Communication during and after the test
Good testers communicate continuously. You need a defined channel and cadence with the client, a de-confliction process so the blue team can tell your traffic from a real incident, and clear triggers for immediate notification: discovering a critical vulnerability under active exploitation, finding evidence of a prior breach, causing an outage, or encountering data that should not have been in scope. Knowing which of those interrupts the test and which goes in the report is directly testable.
Reporting and remediation
The report is the deliverable the client actually pays for. Expect to know its structure: an executive summary written for non-technical leadership, a methodology section that makes the work repeatable, findings with evidence, reproduction detail and a risk rating, and remediation guidance that is specific enough to act on. Beyond the report, know the attestation of findings, a short signed statement of what was tested and when that clients often pass to auditors, and the value of a retest confirming that fixes worked. A finding is only useful when the reader understands the business risk, so a good report explains impact, not just technical severity.
Chapter 3: Reconnaissance and enumeration (21%)
This is the second-largest domain and the phase that determines how good everything after it will be. The theme is turning a target definition into a precise map.
Passive versus active reconnaissance
Passive reconnaissance collects information without sending traffic to the target: public registration records, certificate transparency data, published documents and their metadata, job adverts revealing the technology stack, code repositories, and general open-source intelligence (OSINT). It is quiet and rarely detectable by the target, which is why it comes first. Active reconnaissance sends traffic to target systems to see what responds, and it is detectable, noisy and only legitimate inside the agreed scope and window. The exam frequently checks that you know which category a given activity falls into, because the two carry different legal and detection profiles.
What enumeration produces
Enumeration is the disciplined build-out of detail once you know something exists. Broadly you enumerate hosts (what is alive), services and versions (what is listening and which software it is), shares and file resources, users and groups, directory and domain structure, web application content and endpoints, APIs and their documented or discoverable methods, wireless networks, and increasingly cloud assets such as storage containers, functions and identity configurations. Each category answers a different question, and the skill the exam tests is choosing the enumeration that will actually inform your next decision instead of running everything.
Reading output and thinking in attack surface
The practical skill here is interpretation. Given the output of a discovery activity, you should be able to say what it implies: an unexpected service version suggests an unmanaged host, a directory of user accounts suggests where credential attacks would be relevant, an exposed management interface suggests a high-value path. Group your findings into an attack surface picture, everything exposed that could be interacted with, because the next domain is about which parts of that surface deserve attention. Automation and light scripting support this phase by making repetitive collection consistent, and PT0-003 expects you to recognise what a script is doing at a conceptual level rather than to write one from scratch under exam conditions.
Detection and the defender’s view
A useful study habit for this domain is to ask, after every technique, how a defender would notice. Sudden volumes of connection attempts, requests to non-existent hostnames, anomalous authentication failures and unusual query patterns are the signals a monitoring team sees. This matters for the exam because scenarios often involve staying quiet, and it matters professionally because a test that is detected quickly is also a useful result for the client.
Chapter 4: Vulnerability discovery and analysis (17%)
This domain sits between mapping and attacking. It is about finding candidate weaknesses and, crucially, judging which of them are real and which matter.
Scan types and how to configure them
Vulnerability scanning compares what it finds against a database of known issues. The main choices to understand are credentialed versus non-credentialed scanning, where authenticating gives a far more accurate view of patch and configuration state while an unauthenticated scan shows what an outsider sees; agent-based versus network-based collection; and the intensity settings that trade thoroughness against noise and against the risk of disrupting fragile systems. Special-purpose scanning categories include web application scanning, API testing, container and image scanning, cloud configuration review, and wireless assessment. Knowing which to reach for in a scenario is the testable skill.
Validation is the professional step
Scanners produce candidates, not conclusions. A false positive is a reported issue that is not really exploitable in this environment, and a false negative is a real issue the scan missed. Validation, confirming manually whether the condition genuinely exists, is what turns a scan result into a defensible finding. This is also an ethics point that the exam takes seriously: proving a vulnerability should be done with the least intrusive method that establishes it, and evidence should be sufficient for the client to reproduce and fix the issue without causing unnecessary impact.
Analysing without a scanner
Not every weakness comes from a scan. Expect coverage of configuration review, comparing a system against a hardening baseline, source code and dependency analysis, where the weakness is in the application or a third-party library, and logic flaws, where every component is patched but the workflow allows something it should not. Static analysis examines code without running it while dynamic analysis examines a running application, and the two find different classes of problem. Supply-chain exposure through outdated or unmaintained components is now a standard part of this conversation.
Prioritising by real risk
The final and most examinable skill is ranking. CVSS gives a severity score, and CVE gives an identifier, but a base score describes the vulnerability in the abstract, not in your client’s environment. A high-severity issue on an isolated internal test box with no sensitive data may matter less than a moderate one on an internet-facing system holding customer records. Prioritisation should weigh exposure, asset value, data sensitivity, whether exploitation is known to be practical, and what compensating controls exist. As a teaching illustration: two systems with the same scored vulnerability are not the same finding if one is reachable from the internet and the other is not, and a report that ranks them identically is a weaker report.
Chapter 5: Attacks and exploits (35%)
This is the largest domain, and it is organised by attack surface. The exam does not ask you to run attacks; it asks you to recognise which category of attack applies to a described situation, what it would achieve, what its indicators are, and how it is prevented. Study it that way and it becomes far more manageable than a list of tools.
Network and host attack categories
At the network layer, the concepts to know are attacks that abuse trust in name resolution and address resolution to intercept or redirect traffic, on-path positions where an attacker sits between two parties, relay and replay of authentication material, abuse of legacy or plaintext protocols that expose credentials, and denial of service, which is usually explicitly out of scope in commercial engagements. At the host layer, the categories are credential attacks against weak or reused passwords, abuse of over-permissive service configurations and scheduled tasks, attacks on unpatched components, and misuse of legitimate administrative tooling so activity blends into normal operations. For each, learn the three-part frame: what it achieves, what a defender would see, and what control prevents it. The prevention answers recur, network segmentation, strong and unique credentials with multi-factor authentication, disabling legacy protocols, least privilege, patching, and monitoring for anomalous authentication.
Web application and API attacks
Web and API content is heavily represented because it is where most real findings live. The categories to recognise conceptually are injection, where untrusted input is interpreted as a command by a database, operating system or other interpreter; cross-site scripting, where untrusted input is returned to other users’ browsers as script; broken authentication and session handling, where identity or session material is guessable, exposed or not invalidated; broken access control, including manipulating an identifier to reach another user’s object and reaching admin functionality without authorisation; server-side request forgery, where the application can be induced to make requests on the attacker’s behalf; insecure deserialisation and file upload weaknesses; and security misconfiguration, from default credentials to verbose error pages. For APIs, add missing object-level authorisation, excessive data exposure in responses, absent rate limiting, and undocumented or forgotten endpoints that no one is monitoring. Mitigations cluster just as tightly: validate and encode input, use parameterised queries, enforce authorisation server-side for every request, and never rely on the client to police itself.
Wireless, physical and social engineering
Wireless coverage focuses on the concepts of rogue and evil-twin access points, weaknesses in older encryption standards, and attacks on enterprise authentication and captive portals. Physical testing, when in scope, covers tailgating, unattended workstations, exposed network ports in public areas and inadequate visitor control. Social engineering in an authorised test covers phishing and its variants, pretexting and impersonation, and the reason it is so effective: it bypasses technical controls entirely. Two exam-relevant points: social engineering needs explicit written permission and careful handling because it involves real people, and the finding you write should describe process failure rather than name and shame an individual employee.
Cloud, container and IoT surfaces
V3 broadened this domain, so know the modern surfaces. In cloud, the recurring themes are over-permissive identity and access policies, publicly exposed storage, exposed metadata and credential material, weak separation between tenants or accounts, and the shared responsibility model determining what is even yours to test. In containers and orchestration, the themes are images built from vulnerable or untrusted bases, secrets baked into images, over-privileged containers, and exposed control-plane interfaces. In IoT and operational technology, the themes are default and hardcoded credentials, unpatched or unpatchable firmware, insecure update mechanisms and unencrypted local communication, all made worse by devices that must not be disrupted. As a teaching illustration of judgement: on an industrial control target, availability usually outranks proof, so an aggressive technique that risks disrupting a running process is the wrong choice even when it would demonstrate the point.
Choosing the technique
The exam’s favourite question shape gives you a target description and asks what you would attempt. Answer it by reasoning: what is exposed, what does the client want to learn, what is permitted by the rules of engagement, what proves the finding with the least impact, and what evidence would the report need. Choosing a technique because it is powerful, rather than because it answers the question in scope, is the classic wrong answer.
Chapter 6: Post-exploitation and lateral movement (14%)
This domain covers what a professional does after gaining a foothold, and it ends with the part amateurs skip: cleaning up.
Establishing access and privilege
Persistence is any mechanism that keeps access alive across reboots or session ends. In an authorised test it is legitimate only when agreed, and every mechanism must be recorded so it can be removed. Privilege escalation splits into vertical, obtaining higher privileges than the account you hold, and horizontal, obtaining a different account at a similar level, and the usual conceptual routes are misconfigured permissions, over-privileged services and accounts, unpatched local components, and credential material left accessible on the system. Reports should be precise about which type occurred, because the remediation differs.
Lateral movement and pivoting
Lateral movement is reaching additional systems from your foothold, typically by reusing credentials or trust relationships that the environment grants automatically. Pivoting specifically means routing traffic through a compromised host to reach a network segment you could not touch directly, which is how testers demonstrate that segmentation is not as strong as the client believed. The exam expects you to understand why these matter: a single compromised workstation is a minor finding, while the same workstation providing a route to the domain’s crown jewels is a critical one. The defensive counterparts are the answers to know: network segmentation, unique local credentials, tiered administration, multi-factor authentication on internal services, and monitoring for unusual authentication paths.
Data handling, staging and exfiltration
Demonstrating that data could leave the environment is often the point of the test, and it is also the moment with the most legal risk. Concepts to know are staging, collecting data in one place before it moves, and exfiltration over channels chosen to blend into normal traffic. Professionally, the rules are strict: extract the minimum needed to prove the finding, handle anything sensitive according to the engagement’s data-handling terms, store it encrypted, and destroy it when the engagement closes. On a regulated engagement, taking a full copy of real customer data to prove a point is a serious mistake even though it demonstrates the vulnerability.
Detection avoidance and cleanup
Detection avoidance in this syllabus is conceptual, understanding why activity that looks like normal administration is harder to spot, and why timing, volume and channel choice affect detection. Its usefulness to the client is that it tests the monitoring, so a mature engagement records both what you did and whether anyone noticed. The domain closes with cleanup: removing accounts, tools, scripts, uploaded files, scheduled tasks and configuration changes, restoring anything altered, and documenting everything you removed. Leaving artefacts behind creates real risk for the client and is a professional failure, which is why PT0-003 treats it as examinable content rather than an afterthought.
Chapter 7: Study plan, performance-based questions and exam day
Allocate time by weight, not by interest
Pace your study by the official weights so nothing important is squeezed out. Give the largest single block to attacks and exploits (35%), solid time to reconnaissance and enumeration (21%) and vulnerability discovery and analysis (17%), and genuine, unhurried time to post-exploitation (14%) and engagement management (13%), which together are more than a quarter of the exam and are the fastest marks to secure. A comfortable plan for most people is about twelve weeks at eight hours a week: the process domains first, three weeks on attacks, two on post-exploitation, then a fortnight of mixed review. People already testing professionally can compress to eight weeks at twelve to fifteen hours, while candidates coming straight from Security+ with no testing experience should stretch to sixteen weeks and protect the lab time. To turn whichever timeline you pick into dated weeks from your own start date, use the free study-plan generator.
Practise the performance-based questions deliberately
The performance-based questions are where the clock disappears, so prepare for them on purpose. Build an isolated lab, purpose-built vulnerable practice environments plus your own virtual machines are enough, and spend the time on the skills PBQs actually test: reading scan and enumeration output and stating what it means, ordering the phases of an engagement correctly, matching findings to appropriate remediation, classifying an activity as in or out of scope, and recognising what a short script or command is intended to accomplish. Never point any of this at a system you do not own or have written permission to test. When a task stalls you on exam day, flag and return: 165 minutes is generous, but only if you bank the quick multiple-choice marks first.
Exam day and format
On the day you have up to 90 questions in 165 minutes, at a Pearson VUE test centre or online through OnVUE remote proctoring, booked via your CompTIA account, and you need 750 out of 900 to pass. Expect the performance-based items early. If you test online, run the system check in advance and clear your desk and room, because the proctor will require it. Read every scenario for the constraint hidden in it, the scope, the client’s actual question, the system that must not go down, and answer the question that was asked. That habit is both what passes PT0-003 and what makes a tester worth hiring.
After the exam
PenTest+ is valid for three years and renews with 60 CEUs plus the CE fee for the cycle, or in one step by passing a higher or newer qualifying exam. If your goal is a hands-on testing role, treat PenTest+ as the methodology layer and consider OSCP next for practical proof. If your work is pulling back toward defence, CySA+ covers detection and response, and the two together make a credible “I can attack and I can detect” story in interviews.