PT0-003 — CompTIA PenTest+ V3 Exam Blueprint
Practical exam blueprint for CompTIA PenTest+ V3 (PT0-003) candidates reviewing penetration testing scope, tools, attacks, reporting, and remediation readiness.
How to Use This Exam Blueprint
Use this page as an independent readiness map for the CompTIA PenTest+ V3 (PT0-003) exam. It is not a replacement for the official CompTIA objectives, but it helps translate the public exam scope into practical review tasks.
Work through each section and mark whether you can:
- Explain the concept without notes.
- Choose the right tool or technique for a scenario.
- Interpret common command output, logs, findings, and scan results.
- Identify risk, impact, and remediation.
- Communicate findings professionally in a penetration test report.
- Recognize what is allowed, out of scope, unsafe, or legally inappropriate.
For all hands-on review, use only authorized labs, ranges, intentionally vulnerable systems, or environments where you have explicit permission.
Topic-Area Readiness Table
| Readiness area | What to review | You are ready when you can… |
|---|---|---|
| Engagement planning and scoping | Rules of engagement, authorization, scope, constraints, timelines, communication paths, legal boundaries | Identify what is allowed, what is prohibited, and when to stop or escalate |
| Information gathering | Passive and active reconnaissance, OSINT, DNS, WHOIS, search operators, metadata, certificate data, cloud exposure | Build an attack surface map from limited information without crossing scope |
| Enumeration and scanning | Port scanning, service discovery, banner grabbing, version detection, network mapping, vulnerability scanning | Select scan types, interpret results, and reduce false positives |
| Vulnerability analysis | CVEs, CVSS concepts, exploitability, compensating controls, business impact, validation | Prioritize findings based on likelihood, impact, exposure, and context |
| Exploitation concepts | Web, network, identity, wireless, cloud, application, API, and client-side attack paths | Explain how a vulnerability can be exploited and what evidence proves impact |
| Web and API testing | Authentication, authorization, injection, XSS, CSRF, SSRF, file upload, session management, insecure APIs | Match symptoms, requests, responses, and controls to likely vulnerabilities |
| Identity and directory attacks | Password attacks, credential exposure, privilege escalation, Active Directory concepts, Kerberos/NTLM risks | Recognize identity attack paths and recommend defensive controls |
| Post-exploitation | Privilege escalation, lateral movement, persistence concepts, data discovery, cleanup, evidence handling | Describe objectives and risks without confusing testing with unauthorized activity |
| Cloud and container testing | IAM misconfiguration, public storage, metadata services, container images, orchestration risks, secrets exposure | Identify common cloud-native weaknesses and safer validation methods |
| Social engineering | Pretexting, phishing concepts, vishing, physical testing constraints, consent, safety | Know what must be authorized and how to report human-risk findings responsibly |
| Scripting and automation | Bash, Python, PowerShell concepts, regex, parsing output, simple automation logic | Read and modify small scripts used for enumeration or evidence processing |
| Tool selection | Nmap, Wireshark, Burp Suite, Metasploit concepts, vulnerability scanners, proxy tools, password auditing tools | Choose the right tool for the task and interpret common outputs |
| Reporting and remediation | Executive summaries, technical details, risk ratings, evidence, reproduction steps, remediation guidance | Write findings that are clear, defensible, prioritized, and actionable |
| Ethics and professionalism | Permission, confidentiality, data handling, non-disruption, disclosure, chain of custody concepts | Identify ethical traps and respond appropriately in scenarios |
Planning, Scope, and Rules of Engagement
Checklist
- I can explain the purpose of a statement of work, rules of engagement, authorization letter, and scope statement.
- I can distinguish in-scope targets from out-of-scope systems, users, locations, time windows, and techniques.
- I know why written permission matters before testing begins.
- I can identify escalation triggers such as production instability, sensitive data discovery, safety concerns, or scope ambiguity.
- I can explain the difference between black-box, gray-box, and white-box testing approaches.
- I can identify when a test should pause because the activity could cause harm.
- I can describe communication expectations during testing, including status updates and emergency contacts.
- I understand how cleanup, evidence retention, and data handling should be addressed before the test starts.
Scenario cues
| If the scenario says… | Think about… |
|---|---|
| “The tester found a related domain not listed in scope” | Do not test it without authorization |
| “The customer asks for phishing after kickoff, but it was not included” | Change control and written approval |
| “A scan is causing service degradation” | Stop or throttle activity and notify contacts |
| “Credentials were discovered during testing” | Protect, document, minimize use, and follow rules of engagement |
| “The client wants proof without production impact” | Use safe validation, screenshots, limited queries, or controlled evidence |
Reconnaissance and Information Gathering
Passive reconnaissance
Be ready to use and interpret information from:
- Search engines and advanced search operators.
- Public code repositories.
- DNS records and subdomain data.
- Certificate transparency sources.
- Public breach references and credential exposure indicators.
- Job postings and technology clues.
- Metadata from documents and images.
- Social media and organizational charts.
- Public cloud storage exposure indicators.
Active reconnaissance
- I can explain the difference between passive and active reconnaissance.
- I can identify when active recon may be detected by the target.
- I can select basic discovery methods for hosts, ports, and services.
- I can explain why rate limiting, scan timing, and target exclusions matter.
- I can identify risks of scanning fragile systems, industrial systems, or medical environments.
Common recon artifacts
| Artifact | What it can reveal | Exam readiness prompt |
|---|---|---|
| DNS A/AAAA records | Hostnames and IP addresses | Can you identify likely external-facing assets? |
| MX records | Mail provider and email security clues | Can you infer possible phishing controls? |
| TXT records | Verification tokens, SPF, DKIM, DMARC clues | Can you spot misconfiguration indicators? |
| TLS certificate data | Domains, subdomains, issuing patterns | Can you expand the asset inventory safely? |
| HTTP headers | Server, framework, security headers | Can you identify missing controls? |
| robots.txt | Crawling guidance and exposed paths | Can you avoid treating it as authorization? |
| Public repository data | Secrets, code, endpoints, dependencies | Can you verify exposure without abusing access? |
Scanning, Enumeration, and Vulnerability Discovery
Network scanning readiness
- I can explain host discovery versus port scanning.
- I can distinguish TCP connect scans from SYN scan concepts.
- I can interpret open, closed, and filtered port states at a high level.
- I can explain why UDP scanning is slower and less definitive.
- I can identify common services by port and banner, while remembering ports can be nonstandard.
- I can explain service and version detection.
- I can identify when OS fingerprinting may be unreliable.
- I can explain the difference between a vulnerability scan and a penetration test.
Command recognition checks
You should recognize the purpose of commands like these in an authorized lab context:
nmap -sV -sC -oA scan-results target.example
| Part | What to know |
|---|---|
-sV | Attempts service/version detection |
-sC | Runs default scripts |
-oA | Saves output in multiple formats |
target.example | Must be in scope and authorized |
curl -I https://target.example
| Part | What to know |
|---|---|
-I | Requests response headers |
| Use case | Header review, server clues, security header checks |
dig example.com MX
dig example.com TXT
| Part | What to know |
|---|---|
MX | Mail routing records |
TXT | SPF, DKIM, DMARC, and other verification data |
Vulnerability scanner interpretation
| Scanner output item | What to ask |
|---|---|
| CVE reference | Does the version and configuration actually apply? |
| Severity label | Is it contextualized for this environment? |
| Exploit available | Is exploitation reliable, safe, and authorized? |
| Authenticated finding | Was credentialed scanning performed? |
| Missing patch | Is there a compensating control? |
| TLS issue | Is it exploitable or mainly compliance-related? |
| Default credential finding | Was it validated without excessive access? |
| Web finding | Can request and response evidence support it? |
Vulnerability Analysis and Prioritization
Can you do this?
- Given a scan result, I can identify likely false positives and what validation is needed.
- Given multiple findings, I can prioritize based on exposure, impact, exploitability, and asset value.
- I can explain the difference between vulnerability presence and confirmed exploitability.
- I can separate technical severity from business risk.
- I can recommend practical remediation, not just “patch everything.”
- I can identify when compensating controls reduce risk.
- I can explain why internet-facing findings usually require faster attention than internal-only findings, all else equal.
- I can document evidence without exposing unnecessary sensitive data.
Risk reasoning table
| Factor | Higher concern when… | Lower concern when… |
|---|---|---|
| Exposure | Publicly reachable or accessible by many users | Isolated, segmented, tightly controlled |
| Exploitability | Known exploit path, low complexity, no authentication | Requires rare conditions or strong access |
| Impact | Leads to code execution, data exposure, privilege escalation | Limited information disclosure |
| Asset criticality | Supports regulated, financial, identity, or production services | Noncritical test environment |
| Controls | No monitoring, weak auth, no segmentation | Strong logging, MFA, WAF, EDR, segmentation |
| Evidence quality | Confirmed with safe proof | Based only on banner or unauthenticated inference |
Web Application and API Testing
Core web vulnerabilities
| Area | What to review | Ready means you can… |
|---|---|---|
| Authentication | Login, MFA, password reset, lockout, session creation | Identify weak flows and likely abuse cases |
| Authorization | Horizontal and vertical access control | Recognize IDOR and privilege boundary issues |
| Injection | SQL, command, LDAP, template, NoSQL concepts | Explain input handling and validation failures |
| XSS | Reflected, stored, DOM-based concepts | Identify where untrusted data reaches the browser |
| CSRF | State-changing requests and anti-CSRF controls | Explain when CSRF is relevant |
| SSRF | Server-side requests to internal or cloud resources | Recognize dangerous URL-fetching behavior |
| File upload | Content type, extension, storage path, execution risk | Identify unsafe upload handling |
| Path traversal | File path manipulation | Recognize directory escape patterns conceptually |
| Session management | Cookies, tokens, expiration, fixation | Spot weak session controls |
| Security headers | CSP, HSTS, X-Frame-Options concepts | Explain the control each header supports |
| API authorization | Object-level and function-level access | Test whether users can access unauthorized data |
| Rate limiting | Brute force, enumeration, scraping | Identify missing abuse controls |
HTTP request and response interpretation
Be ready to examine:
- Methods:
GET,POST,PUT,PATCH,DELETE,OPTIONS. - Status codes: success, redirect, client error, server error patterns.
- Cookies:
HttpOnly,Secure,SameSite, expiration. - Authorization headers and bearer token concepts.
- JSON request bodies and parameter tampering.
- Redirect parameters and open redirect risk.
- Error messages that reveal stack traces, paths, SQL errors, or secrets.
- CORS headers and cross-origin trust issues.
Web testing decision prompts
| Prompt | What the exam may expect |
|---|---|
| User A can view User B’s invoice by changing an ID | Broken object-level authorization / IDOR |
| Input appears in the page without encoding | XSS risk |
| Server fetches a user-supplied URL | SSRF risk |
| Admin-only function can be called by a normal user | Broken function-level authorization |
| Password reset token is predictable or reusable | Account takeover risk |
| File upload accepts executable content | Remote execution or stored attack risk |
| API returns excessive fields | Sensitive data exposure |
| No lockout or throttling on login | Brute-force risk |
Network, Infrastructure, and Service Exploitation Concepts
Infrastructure topics to review
- Common TCP and UDP services and their security implications.
- Misconfigured SMB, NFS, FTP, SSH, RDP, SNMP, LDAP, and database services.
- Weak or default credentials.
- Anonymous or guest access.
- Unnecessary exposed services.
- Outdated services with known vulnerabilities.
- Insecure protocols and lack of encryption.
- Network segmentation and pivoting concepts.
- Firewall and ACL impact on testing.
- VPN and remote access exposure.
- Service account misuse.
- Password spraying versus brute-force concepts.
- Credential stuffing versus password guessing.
- Privilege escalation conditions.
Service clue table
| Service clue | Possible concern | Readiness check |
|---|---|---|
| SMB shares visible | Sensitive files, guest access, signing issues | Can you identify safe enumeration steps? |
| SNMP community string exposed | Network device data leakage | Can you explain why default strings are risky? |
| RDP open externally | Credential attacks, exposed admin surface | Can you recommend MFA and access restriction? |
| FTP allows anonymous access | Data exposure or upload risk | Can you assess read/write implications? |
| Database port exposed | Direct data access or brute force risk | Can you recommend network restriction? |
| SSH with password auth | Credential attack exposure | Can you compare keys, MFA, and hardening? |
| LDAP exposed | Directory enumeration and auth risks | Can you explain secure configuration options? |
Identity, Password, and Directory Testing
Password attack concepts
- I can distinguish brute force, password spraying, credential stuffing, and dictionary attacks.
- I understand why account lockout policies affect testing strategy.
- I can explain the risk of reused passwords.
- I can identify where password hashes may be encountered during authorized testing.
- I can explain salting, hashing, and cracking concepts at a high level.
- I can describe why offline cracking risk depends on hash type, password quality, and available compute.
- I can recommend MFA, password managers, lockout controls, monitoring, and credential hygiene.
Active Directory and enterprise identity
| Topic | What to know |
|---|---|
| Users and groups | Privileges often come from group membership |
| Service accounts | May have excessive rights or weak passwords |
| Kerberos concepts | Tickets, service principal names, delegation risks |
| NTLM concepts | Legacy authentication and relay-related risks |
| Group Policy | Can expose configuration, scripts, or privilege paths |
| Local administrator reuse | Enables lateral movement |
| Shared credentials | Increase blast radius |
| Privilege escalation | Often depends on misconfiguration, weak ACLs, or excessive rights |
| Lateral movement | Requires authorization and careful scoping in a test |
| Logging | Identity events are critical evidence and detection sources |
Can you explain the difference?
| Pair | Difference to know |
|---|---|
| Brute force vs password spraying | Many guesses against one account vs one/few guesses against many accounts |
| Credential stuffing vs password spraying | Known breached credentials vs guessed common passwords |
| Hashing vs encryption | One-way verification vs reversible protection with keys |
| Authentication vs authorization | Proving identity vs granting access |
| Local admin vs domain admin | Machine-level control vs broad directory control |
| Privilege escalation vs lateral movement | Gaining more rights vs moving to other systems |
Cloud, Container, and Modern Infrastructure Testing
Cloud readiness checklist
- I can explain why cloud penetration testing must follow the provider and customer authorization model.
- I can identify common IAM misconfigurations such as excessive permissions and weak role separation.
- I can recognize public object storage exposure.
- I can explain why exposed access keys, tokens, and secrets are high risk.
- I can identify metadata service risks conceptually.
- I can recognize insecure security groups, firewall rules, or network ACLs.
- I can explain logging and monitoring gaps in cloud environments.
- I can recommend least privilege, key rotation, encryption, private access, and monitoring.
- I can distinguish customer-managed configuration issues from provider-managed infrastructure.
Container and orchestration topics
| Topic | What to review |
|---|---|
| Container images | Vulnerable packages, secrets, excessive privileges |
| Dockerfile practices | Hardcoded secrets, running as root, unnecessary tools |
| Registry exposure | Public images, weak access control |
| Runtime permissions | Privileged containers, mounted host paths |
| Kubernetes concepts | Pods, services, namespaces, RBAC, secrets |
| Network policies | East-west traffic restrictions |
| Supply chain | Dependency and image trust concerns |
| CI/CD pipelines | Secrets exposure, insecure runners, weak approvals |
Cloud scenario cues
| Scenario clue | Likely issue |
|---|---|
| Storage bucket allows public read | Data exposure |
| Access key found in a repository | Secret leakage |
| Role has broad wildcard permissions | Excessive privilege |
| Management interface open to the internet | Exposed administrative plane |
| Logs are disabled | Detection and forensic gap |
| Container runs as root with host mounts | Container escape or host impact risk |
| CI job prints secrets in logs | Pipeline secret exposure |
Wireless, Mobile, IoT, and OT Awareness
Wireless topics
- I can identify risks of weak Wi-Fi encryption and poor passphrases.
- I can explain rogue access point and evil twin concepts.
- I can identify the role of guest networks and segmentation.
- I can explain why wireless testing requires careful location and scope control.
- I can distinguish discovery, capture, authentication, and encryption concepts.
Mobile, IoT, and OT topics
| Area | What to focus on |
|---|---|
| Mobile apps | Insecure storage, weak API authorization, hardcoded secrets, certificate validation issues |
| IoT devices | Default credentials, exposed services, outdated firmware, insecure management interfaces |
| Embedded systems | Limited patching, debug ports, hardcoded accounts |
| OT/ICS | Safety, availability, fragile protocols, strict authorization, non-disruptive testing |
| Physical access | Badges, locks, ports, tailgating, written permission |
| Bluetooth/NFC/RFID | Short-range attack concepts and authorization boundaries |
Social Engineering and Physical Testing
Checklist
- I can explain why social engineering must be explicitly authorized.
- I can distinguish phishing, spear phishing, vishing, smishing, pretexting, and baiting.
- I can identify safe handling of captured credentials or sensitive responses.
- I can explain why physical testing needs location, time, and safety constraints.
- I can identify when a test creates unacceptable legal, privacy, or safety risk.
- I can recommend training, reporting channels, MFA, verification procedures, and physical controls.
Scenario cues
| Scenario | Best response |
|---|---|
| Employee reports a test phishing email | Record positive control behavior |
| Tester is challenged by security | Follow rules of engagement and stop if required |
| Target enters credentials on a test page | Protect evidence and avoid unnecessary access |
| A physical test enters a restricted safety area | Stop and escalate immediately |
| Pretext targets a sensitive personal situation | Avoid unethical or harmful pretexts |
Post-Exploitation, Evidence, and Cleanup
Post-exploitation concepts to understand
- Privilege escalation.
- Lateral movement.
- Credential discovery.
- Data discovery.
- Persistence concepts.
- Pivoting concepts.
- Tunneling and proxying concepts.
- Exfiltration simulation.
- Cleanup and restoration.
- Evidence collection.
- Deconfliction with defenders.
Keep the exam distinction clear
| Concept | Exam-safe understanding |
|---|---|
| Privilege escalation | Demonstrating increased access due to misconfiguration or vulnerability |
| Lateral movement | Showing how one compromised system can lead to another within approved scope |
| Persistence | Understanding risk; using only when explicitly authorized and safely removable |
| Data access | Proving impact with minimum necessary evidence |
| Exfiltration | Simulating or tightly controlling proof of data movement |
| Cleanup | Removing test accounts, tools, payloads, files, and configuration changes |
| Evidence | Capturing enough proof to support the finding without overcollecting |
Scripting, Automation, and Data Handling
Skills to be comfortable with
- Reading simple Bash, Python, and PowerShell snippets.
- Understanding loops, conditionals, variables, functions, and command output.
- Parsing text, JSON, and CSV output.
- Using regular expressions for matching IP addresses, domains, emails, or tokens.
- Automating repetitive checks in an authorized lab.
- Avoiding scripts that modify systems unless explicitly approved.
- Handling secrets and sensitive files safely.
Mini script recognition
import json
with open("scan.json") as f:
data = json.load(f)
for host in data.get("hosts", []):
for port in host.get("ports", []):
if port.get("state") == "open":
print(host["ip"], port["port"], port.get("service", "unknown"))
You should be able to identify that this script:
- Reads JSON-formatted scan data.
- Iterates through hosts and ports.
- Prints open services.
- Does not exploit or modify a target.
- Could support reporting or triage.
Regex readiness
| Pattern concept | Example use |
|---|---|
| Email matching | Extract possible usernames from text |
| IPv4 matching | Parse scan output |
| Domain matching | Build asset lists |
| Token-like strings | Identify possible secrets for validation |
| Error strings | Find stack traces or debug output |
Tool Selection Checklist
You do not need to memorize every flag of every tool, but you should know what tool fits the scenario and what output means.
| Tool/category | Primary purpose | Ready when you can… |
|---|---|---|
| Nmap | Host discovery, port scanning, service detection | Choose scan intent and interpret service output |
| Wireshark/tcpdump | Packet capture and protocol analysis | Identify conversations, protocols, and suspicious traffic |
| Burp Suite / web proxy | Intercept and modify web/API traffic | Analyze requests, responses, sessions, and parameters |
| Vulnerability scanners | Identify known issues and misconfigurations | Triage, validate, and prioritize findings |
| Metasploit concepts | Exploit framework and validation workflow | Understand modules, payload concepts, sessions, and risk |
| Password auditing tools | Password hash or policy assessment in authorized scope | Explain cracking, spraying, and lockout considerations |
| OSINT tools | Public data collection | Expand attack surface without active probing |
| Directory tools | Enumerate identity environments | Identify users, groups, trusts, and privilege paths conceptually |
| Cloud CLI/tools | Review cloud resources and IAM | Identify misconfiguration and exposure |
| Container tools | Review images and runtime settings | Spot vulnerable images, secrets, and privilege issues |
| SAST/DAST concepts | Application security testing | Know when static or dynamic testing is useful |
| SIEM/log tools | Detection and evidence review | Correlate activity and support findings |
Reporting and Communication
Finding structure checklist
A strong technical finding should include:
- Title that clearly names the issue.
- Affected asset or application area.
- Severity or risk rating with rationale.
- Business impact.
- Technical description.
- Evidence, such as request/response snippets, screenshots, command output, or logs.
- Reproduction steps that are safe and concise.
- Scope and assumptions.
- Remediation guidance.
- References when useful.
- Retest recommendation.
- Limitations or conditions that affect confidence.
Executive versus technical communication
| Audience | Emphasize | Avoid |
|---|---|---|
| Executives | Business risk, priorities, trends, exposure, remediation roadmap | Tool noise, excessive commands, raw exploit detail |
| Technical teams | Evidence, affected systems, reproduction, root cause, fix guidance | Vague risk statements without proof |
| Legal/compliance | Authorization, data handling, scope, evidence control | Speculation outside the test |
| Security operations | Detection opportunities, logs, attack path, indicators | Overly broad claims without timestamps |
| Application teams | Request/response evidence, code/config hints, validation logic | Blame language or unclear ownership |
Remediation mapping
| Finding type | Likely remediation themes |
|---|---|
| Missing patch | Update, virtual patching, compensating controls, monitoring |
| Weak password controls | MFA, lockout, password policy, detection, user training |
| Excessive IAM permissions | Least privilege, role review, permission boundaries |
| Public storage exposure | Restrict access, review data, logging, encryption |
| SQL injection | Parameterized queries, input validation, least privilege |
| XSS | Output encoding, CSP, input validation, secure frameworks |
| IDOR | Server-side authorization checks |
| Exposed admin interface | Network restriction, VPN, MFA, logging |
| Default credentials | Change defaults, disable unused accounts, credential management |
| Insecure TLS | Modern protocol configuration, certificate hygiene |
Legal, Ethical, and Professional Judgment
Must-know boundaries
- Authorization must be explicit and documented.
- Scope limits testing activities.
- Sensitive data should be minimized, protected, and reported appropriately.
- Testing should avoid unnecessary disruption.
- Findings should be accurate, reproducible, and defensible.
- Client confidentiality applies to tools, data, screenshots, and reports.
- Public disclosure is not appropriate unless coordinated and authorized.
- Third-party systems require separate authorization.
- Safety-critical systems require heightened caution.
Judgment checks
| Question | Correct exam mindset |
|---|---|
| Can I test a newly discovered system? | Only if it is in scope or added through authorization |
| Should I prove full data exfiltration? | Usually no; use minimum evidence required |
| Should I continue if production is unstable? | Stop or pause and notify the agreed contact |
| Can I keep credentials for later testing? | Follow data handling and rules of engagement |
| Should I include every scanner result in the report? | Validate, deduplicate, prioritize, and contextualize |
| Can I run destructive tests to prove impact? | Only if explicitly authorized and controlled |
Common Weak Areas and Exam Traps
| Trap | Why candidates miss it | How to correct it |
|---|---|---|
| Treating scan output as proof | Tools can be wrong or lack context | Validate findings safely |
| Ignoring scope | Technical curiosity overrides authorization | Always check rules of engagement |
| Confusing vulnerability severity with business risk | Severity labels are not the whole story | Consider asset value, exposure, controls, and impact |
| Overlooking authorization flaws | Candidates focus only on injection and CVEs | Test user roles, object access, and workflow abuse |
| Weak report writing | Technical knowledge does not translate into findings | Practice writing evidence-based findings |
| Tool memorization without purpose | Knowing flags is not the same as judgment | Map tool to task and output |
| Forgetting cleanup | Focus stays on exploitation | Include restoration and artifact removal |
| Missing cloud identity risk | Candidates look only at network exposure | Review IAM, keys, roles, and storage access |
| Overclaiming exploitability | A version match is not always vulnerable | Confirm configuration and conditions |
| Unsafe proof collection | Too much sensitive data is captured | Use minimum necessary evidence |
| Confusing password attacks | Spraying, stuffing, brute force, and cracking differ | Review definitions and scenario indicators |
| Ignoring detection and communication | Testing is not only technical | Know escalation, logs, and stakeholder updates |
“Can You Do This?” Final Skills Checklist
Planning and scope
- Identify whether an action is authorized.
- Choose a test type based on client goals and knowledge level.
- Recognize when to stop, pause, or escalate.
- Explain how scope affects tools and techniques.
Recon and enumeration
- Build a basic target profile from OSINT.
- Distinguish passive from active collection.
- Interpret DNS, HTTP header, and certificate clues.
- Select a scan approach for host, port, and service discovery.
- Explain scanner noise, false positives, and validation.
Exploitation and validation
- Map common findings to likely attack paths.
- Identify safe proof for a vulnerability.
- Explain privilege escalation and lateral movement concepts.
- Recognize identity, web, API, cloud, and network weaknesses.
- Avoid destructive or out-of-scope actions.
Reporting and remediation
- Write a finding with risk, evidence, impact, and remediation.
- Prioritize multiple findings.
- Communicate differently to executives and engineers.
- Recommend practical controls for common vulnerability classes.
- Explain retesting and remediation validation.
Tools and artifacts
- Recognize common command-line tools and their purpose.
- Interpret basic network, web, and scan output.
- Read simple scripts used for parsing or automation.
- Identify logs, screenshots, requests, and responses that support evidence.
- Protect sensitive artifacts.
Scenario Decision Matrix
| Scenario | Best next action |
|---|---|
| Scan identifies a critical vulnerability on an out-of-scope host | Do not test; report scope concern through agreed channel |
| Web app exposes another user’s data by changing an ID | Document as authorization flaw with minimum necessary evidence |
| Vulnerability scanner reports an outdated service | Validate version/configuration before claiming exploitability |
| Phishing test captures real credentials | Protect data, avoid use unless authorized, report per engagement rules |
| Exploit attempt causes errors in production | Stop or pause, preserve evidence, notify emergency contact |
| Public repository contains a cloud key | Treat as sensitive, validate carefully if authorized, recommend rotation |
| Internal share allows guest read access | Document accessible data types without mass copying |
| Application returns stack traces | Capture representative evidence and recommend error handling fixes |
| Login has no rate limiting | Identify brute-force or spraying risk and recommend controls |
| Container image includes hardcoded secrets | Report supply-chain and secret-management weakness |
| Executive asks for a one-page summary | Focus on business impact, top risks, and remediation priorities |
| Engineer asks how to reproduce | Provide clear, safe, scoped reproduction steps |
Final-Week Review Checklist
Seven to five days before exam
- Re-read the official CompTIA exam objectives for CompTIA PenTest+ V3 (PT0-003).
- Identify your weakest three topic areas from practice results.
- Review scope, authorization, and rules-of-engagement scenarios.
- Drill web/API vulnerability identification.
- Review identity and password attack terminology.
- Practice interpreting scan outputs and HTTP evidence.
- Write at least a few sample findings from lab results.
Four to two days before exam
- Review cloud, container, and modern infrastructure misconfiguration patterns.
- Review tool-purpose matching.
- Review common ports, services, and vulnerability clues.
- Review remediation mapping for common findings.
- Practice prioritizing findings with business context.
- Revisit scripting basics and output parsing.
- Review ethical, legal, and data handling boundaries.
Day before exam
- Do a light review of notes, not a full content cram.
- Recheck confusing terms: spraying, stuffing, brute force, cracking, exploitation, validation.
- Review your most common practice-test mistakes.
- Skim report structure and remediation examples.
- Rest and avoid late-night tool rabbit holes.
Exam-day mindset
- Read every scenario for scope, authorization, and business context.
- Do not choose the most aggressive technical answer if a safer authorized step is required.
- Prefer validation over blind trust in tool output.
- Match remediation to root cause.
- Watch for wording that changes the best answer: public-facing, production, out of scope, unauthenticated, critical asset, sensitive data.
- Eliminate answers that violate permission, safety, confidentiality, or scope.
Practical Next Step
Use this checklist to mark weak areas, then move into targeted practice. For each missed practice question, write down the topic, the decision point, and the safer or more professional action the scenario was testing. That habit builds the judgment needed for CompTIA PenTest+ V3 (PT0-003), not just memorization.