Free CompTIA PenTest+ PT0-003 Practice Questions: Vulnerability Discovery and Analysis
Practice 10 free CompTIA PenTest+ V3 (CompTIA PenTest+ PT0-003) questions on Vulnerability Discovery and Analysis, with answers, explanations, and the IT Mastery next step.
Try the IT Mastery web app for a richer interactive practice experience with mixed sets, timed mocks, topic drills, explanations, and progress tracking.
Topic snapshot
| Field | Detail |
|---|---|
| Practice target | CompTIA PenTest+ PT0-003 |
| Topic area | Vulnerability Discovery and Analysis |
| Blueprint weight | 17% |
| Page purpose | Focused sample questions before returning to mixed practice |
How to use this topic drill
Use this page to isolate Vulnerability Discovery and Analysis for CompTIA PenTest+ PT0-003. Work through the 10 questions first, then review the explanations and return to mixed practice in IT Mastery.
| Pass | What to do | What to record |
|---|---|---|
| First attempt | Answer without checking the explanation first. | The fact, rule, calculation, or judgment point that controlled your answer. |
| Review | Read the explanation even when you were correct. | Why the best answer is stronger than the closest distractor. |
| Repair | Repeat only missed or uncertain items after a short break. | The pattern behind misses, not the answer letter. |
| Transfer | Return to mixed practice once the topic feels stable. | Whether the same skill holds up when the topic is no longer obvious. |
Blueprint context: 17% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.
Sample questions
These are original IT Mastery practice questions aligned to this topic area. They are not official CompTIA questions, copied live-exam content, or exam dumps. Use them to preview question style and explanation depth before continuing with topic drills, mixed sets, and timed mocks in IT Mastery.
Question 1
Topic: Vulnerability Discovery and Analysis
A penetration tester is reviewing validation notes before drafting the final report. The rules of engagement allow only non-destructive testing using approved test accounts. Which finding should be classified as confirmed rather than suspected?
Exhibit: Validation notes
| Finding | Initial evidence | Follow-up evidence |
|---|---|---|
| Outdated web server | Banner shows Apache/2.4.49 | Patch level could not be verified |
| Default admin password | Scanner reported possible default login | Manual login was not attempted |
| IDOR in invoices API | API path uses numeric invoice IDs | Test account A retrieved test account B’s invoice by changing only the ID |
| Reflected XSS | Parameter reflected in response | Output was HTML-encoded in browser testing |
Options:
A. Confirm the outdated web server finding
B. Confirm the reflected XSS finding
C. Confirm the default admin password finding
D. Confirm the IDOR finding
Best answer: D
Explanation: A confirmed finding requires corroborating evidence that the weakness is actually exploitable or observable in the tested environment. Here, the invoices API finding is confirmed because the tester used approved test accounts and demonstrated that one account could access another account’s invoice by changing only the object ID. The other items remain suspected because they rely on incomplete indicators: a banner without patch verification, an untested default-credential claim, or reflected output that appears encoded rather than executable. The key distinction is evidence quality, not scanner confidence alone.
- Banner-only evidence can indicate exposure, but backported patches or inaccurate banners can make version-based findings uncertain.
- Untested default credentials remain suspected because the scanner did not prove a successful login.
- Encoded reflection does not confirm XSS when browser testing shows the input is rendered safely.
Question 2
Topic: Vulnerability Discovery and Analysis
A penetration tester is reviewing vulnerability scan coverage before prioritizing findings. The approved scope includes the corporate LAN and an OT support subnet. The scanner was placed on the corporate LAN.
Scan summary:
| Scoped asset group | Inventory count | Scan result |
|---|---|---|
| Corporate LAN | 118 | 116 assessed |
| OT support subnet | 42 | 0 assessed; firewall blocked scanner traffic |
| Cloud web apps | 6 | 6 assessed |
Which approach best addresses the coverage gap?
Options:
A. Run unauthenticated Internet scans against the OT address range
B. Prioritize only the hosts with confirmed high-severity findings
C. Report the OT subnet as unassessed and request an approved test path
D. Exclude the OT subnet from the report because no findings were returned
Best answer: C
Explanation: A coverage gap exists when scoped assets cannot be assessed because of access, protocol, credential, or inventory limitations. Here, 42 in-scope OT support assets returned no vulnerability data because the scanner could not reach the subnet. That is not evidence that the assets are safe; it is evidence that the assessment is incomplete. The professional approach is to document the unassessed segment, explain the cause, and coordinate an authorized alternative such as a temporary firewall rule, approved scanner placement, credentialed/local checks, or a separately approved OT-safe method. Risk prioritization should clearly distinguish confirmed findings from untested scope.
- Confirmed-only prioritization misses that risk ranking is incomplete when an entire scoped subnet has no assessment data.
- Internet scanning changes the test path and may violate authorization, especially for OT assets.
- Silent exclusion misrepresents coverage because no findings were returned due to blocked access, not lack of vulnerabilities.
Question 3
Topic: Vulnerability Discovery and Analysis
A penetration tester is reconciling vulnerability scan outputs for the same in-scope server before writing the report.
Exhibit: Scan comparison
| Scan | Source / access | Result |
|---|---|---|
| A | Internet, unauthenticated | Host unreachable; no ports tested |
| B | Internal VPN, unauthenticated | Host alive; TCP 22 and 443 open; remote TLS issue found |
| C | Internal VPN, credentialed | Host alive; SSH login failed; local checks skipped |
Which interpretation is best supported by the exhibit?
Options:
A. The host was unavailable during all scans and should be rescanned later.
B. The external result is likely network-location dependent, and the credentialed scan is incomplete.
C. The credentialed scan proves there are no missing local patches.
D. The host has no externally exploitable vulnerabilities.
Best answer: B
Explanation: Scan differences often reflect scanner position, credentials, and target availability rather than actual vulnerability differences. Here, the same host is unreachable from the Internet but reachable from the internal VPN, so the external result likely indicates filtering, routing, or perimeter exposure differences. The credentialed scan did not actually perform local checks because SSH authentication failed, so it cannot support conclusions about installed patches or host configuration. The report should preserve those limitations and avoid treating incomplete coverage as a clean result.
- External clean assumption fails because unreachable from one location does not prove the host has no externally exploitable weaknesses.
- Host unavailable assumption fails because the internal scans show the host was alive.
- Credentialed clean assumption fails because authentication failed and local checks were skipped.
Question 4
Topic: Vulnerability Discovery and Analysis
A penetration tester is consolidating scanner output before drafting findings. Which analysis step best separates duplicate findings from distinct risk conditions?
Exhibit: Scan consolidation notes
| ID | Scanner finding | Target evidence |
|---|---|---|
| 1 | TLS 1.0 enabled | vpn.example.com:443, resolves to 10.10.5.20 |
| 2 | Weak TLS protocol | 10.10.5.20:443, same certificate CN as vpn.example.com |
| 3 | TLS 1.0 enabled | pay.example.com:443, resolves to 10.10.5.21 |
| 4 | Weak cipher suite | vpn.example.com:443, separate cipher evidence |
Options:
A. Merge all findings with the same severity rating.
B. Keep every scanner plugin result as a separate finding.
C. Suppress the lower-confidence scanner result automatically.
D. Correlate normalized asset, service, root cause, and evidence.
Best answer: D
Explanation: Duplicate analysis should normalize the target first, then compare the affected service and vulnerability evidence. Hostnames, IPs, and certificates can show that two records describe the same exposed service, as with vpn.example.com:443 and 10.10.5.20:443. However, the same weakness on a different asset remains a distinct risk condition, and a different weakness on the same service also remains distinct. The goal is not to reduce the report by severity or tool count; it is to preserve accurate risk while removing redundant records.
- Severity grouping fails because unrelated vulnerabilities can share the same severity.
- Plugin-by-plugin reporting creates duplicate report noise when two tools identify the same affected instance.
- Automatic suppression is unsafe because confidence must be assessed against evidence, not scanner preference alone.
Question 5
Topic: Vulnerability Discovery and Analysis
A penetration tester is configuring a vulnerability scan after initial discovery for an internal assessment. The rules of engagement authorize authenticated scanning only for 10.20.30.0/24 during the approved window and state that any newly discovered assets require written approval before testing.
Discovery notes:
VPN route visible: 10.20.40.0/24
DNS result: portal.example.com -> 198.51.100.25
Scanner import: 10.20.30.0/24, 10.20.40.0/24, 198.51.100.25
Which scan-scope adjustment best aligns discovery with documented authorization?
Options:
A. Scan only
10.20.30.0/24and queue the others for approvalB. Add
198.51.100.25because DNS ties it to the clientC. Run unauthenticated discovery against all imported targets
D. Add
10.20.40.0/24because the VPN route is visible
Best answer: A
Explanation: Documented authorization controls scan scope even when discovery reveals additional reachable or client-associated systems. In this scenario, the only approved active scan target is 10.20.30.0/24, and the rules explicitly require written approval before testing newly discovered assets. A visible VPN route and a DNS relationship are useful evidence for possible scope expansion, but they do not grant permission to scan. The safest scan-scope adjustment is to remove or exclude the unapproved targets from the active scan and track them for client approval. This preserves evidence quality and prevents unauthorized testing.
- VPN reachability is not authorization; accessible routing can expose networks that are not approved targets.
- DNS ownership clues help identify candidates, but association alone does not permit scanning an external host.
- Unauthenticated discovery is still active testing when directed at unapproved targets, so it does not solve the scope issue.
Question 6
Topic: Vulnerability Discovery and Analysis
A penetration tester is troubleshooting a vulnerability scan for an internal server assessment. The rules of engagement authorize only 10.40.12.0/24 during the weekend window. The scan report shows many hosts as “alive” but most plugin checks are unauthenticated, and the network team confirms that only scanner 10.40.12.25 is allowed through the host firewall. What is the BEST corrective scan configuration?
Options:
A. Use the approved scanner with validated credentials for
10.40.12.0/24.B. Suppress authentication failures and report the current results.
C. Expand the target list to adjacent internal subnets.
D. Run an unauthenticated scan from an external scanner.
Best answer: A
Explanation: Coverage gaps should be corrected by fixing the specific scan conditions that limited evidence quality, without exceeding authorization. Here, the report indicates credentialed checks failed, and the firewall permits only one approved scanner source. The in-scope target range is also explicitly limited to 10.40.12.0/24. The professional decision is to rerun or reconfigure the scan using the allowed scanner IP, validated credentials, and only the authorized target range during the approved window. This improves finding confidence and avoids creating out-of-scope traffic or relying on incomplete unauthenticated results.
- Adjacent subnets are not authorized by the rules of engagement, even if they may contain related systems.
- External scanning ignores the confirmed firewall filtering and would not resolve internal authenticated coverage.
- Suppressing failures hides the evidence-quality problem instead of correcting the scan configuration.
Question 7
Topic: Vulnerability Discovery and Analysis
A company asks for a vulnerability assessment of its internet-facing web servers before a public launch. The rules of engagement state that the test should show what an unknown external attacker can discover without valid credentials. The client also wants the report to separate unauthenticated exposure from issues that require logged-in access. Which scanning approach best maps to these requirements?
Options:
A. Run exploit validation against all detected services
B. Run internal credentialed scans from the corporate VPN
C. Run unauthenticated scans from an external network perspective
D. Run authenticated scans using provided application accounts
Best answer: C
Explanation: Unauthenticated vulnerability scanning is the right approach when the goal is to model external visibility or unauthenticated exposure. In this scenario, the client specifically wants to know what an unknown internet-based attacker can discover without valid credentials. Scanning from an external vantage point without credentials aligns the test conditions with that goal and helps keep the report’s evidence tied to externally observable risk. Authenticated testing can still be useful in other assessments, but it answers a different question: what is vulnerable after access has been granted. The key takeaway is to match scan authentication and vantage point to the threat perspective being measured.
- Authenticated application scans would identify logged-in weaknesses, but the stated goal is non-credentialed external visibility.
- Internal VPN scanning changes the vantage point and may expose findings that are not internet-visible.
- Exploit validation can create unnecessary risk and is not required to choose the scan strategy here.
Question 8
Topic: Vulnerability Discovery and Analysis
During an authorized vulnerability assessment, the client asks which single finding should be prioritized for remediation before the next change window. Production exploit attempts are not permitted, but validated scanner evidence and business impact should drive prioritization.
| Finding | Evidence | Business context |
|---|---|---|
SQL injection on /api/orders | DAST reproduced abnormal database error handling on multiple requests | Internet-facing customer portal processes orders and PII |
Outdated OpenSSH on dev-wiki01 | Unauthenticated scan inferred version from banner | Internal dev wiki; compensating VPN access required |
Weak TLS ciphers on www | Scanner reports legacy cipher support | Public marketing site; no login or customer data |
| Missing SPF record | DNS check failed SPF lookup | Corporate email domain used for newsletters |
Options:
A. Outdated OpenSSH on
dev-wiki01B. SQL injection on
/api/ordersC. Missing SPF record
D. Weak TLS ciphers on
www
Best answer: B
Explanation: Finding priority should combine evidence confidence, exploitability context, exposure, and business impact. The SQL injection finding is supported by repeatable DAST behavior, affects an internet-facing application, and involves order processing and PII, so it presents the clearest near-term risk. The OpenSSH item may be important, but the evidence is less reliable because it is based only on unauthenticated banner inference and the host is behind VPN access. The TLS and SPF issues are valid security hygiene concerns, but the supplied context shows lower immediate impact than a validated application weakness on a customer-facing system. Prioritization should not follow scanner severity alone when confidence and business context point elsewhere.
- Banner-based versioning can overstate risk because unauthenticated scans may misidentify patched or backported services.
- Public exposure alone is not enough when the affected marketing site has no login or sensitive data in scope.
- Email hygiene risk matters, but the SPF issue is less directly tied to the stated order-processing and PII impact.
Question 9
Topic: Vulnerability Discovery and Analysis
A penetration tester scanned the same in-scope server twice during a vulnerability assessment. The report owner asks why the two results differ.
Exhibit: Scan comparison
| Scan | Access used | Notable result |
|---|---|---|
| A | No credentials | Open ports and banner-based SSH finding; local checks skipped |
| B | Valid SSH credentials | Installed package versions, patch status, and file permission issues confirmed |
Which interpretation is best supported by the exhibit?
Options:
A. Scan A is more reliable because it avoids logging in.
B. Scan B should be discarded because credentials changed the host state.
C. Scan B provides higher confidence for host-level findings.
D. Both scans have equal visibility because the target is identical.
Best answer: C
Explanation: Authenticated scanning uses approved credentials to inspect host-level details such as installed packages, registry or configuration settings, patch status, and permissions. That deeper visibility usually improves finding confidence and reduces banner-based false positives. Unauthenticated scanning is still useful for discovering exposed services and remotely observable issues, but it cannot confirm many local conditions because it sees only what is reachable from the network. In this exhibit, Scan A skipped local checks and relied on banners, while Scan B confirmed internal evidence. The best reporting conclusion is that the authenticated scan provides stronger support for host-level vulnerability findings.
- Avoiding login does not make the unauthenticated scan more reliable for local patch or configuration validation.
- Same target does not mean equal visibility; access level changes what evidence the scanner can collect.
- Credential use is expected in authenticated scanning when authorized and does not by itself invalidate results.
Question 10
Topic: Vulnerability Discovery and Analysis
A penetration tester is assessing a client’s internally developed web application before a production release. The client has provided read-only access to the source repository, dependency manifest, and CI build artifacts, but the staging environment is unavailable until after the testing window. The objective is to identify insecure coding patterns and vulnerable third-party components without affecting business operations. What is the BEST professional decision?
Options:
A. Attempt manual exploitation of production endpoints
B. Perform DAST scanning against the production application
C. Run a SAST review against the repository and build artifacts
D. Delay all testing until staging is available
Best answer: C
Explanation: Static application security testing is the right fit when the tester has source code, dependency manifests, or build artifacts and the goal is to find code-level weaknesses without interacting with a live application. In this scenario, the staging environment is unavailable and production impact must be avoided, so a runtime technique such as DAST would not satisfy the constraints. SAST can examine insecure coding patterns and often helps identify vulnerable dependencies or build-time issues from the provided materials. The key decision is to match the testing method to both the available evidence and the authorization boundaries.
- Production DAST fails because it targets a live runtime environment and may affect business operations outside the stated testing setup.
- Waiting for staging misses useful authorized testing that can be performed within the current window using the provided artifacts.
- Manual exploitation exceeds the safer objective because the scenario asks for static analysis of code and components, not runtime exploitation.
Continue in the web app
Use IT Mastery for interactive CompTIA PenTest+ PT0-003 practice with mixed sets, timed mocks, topic drills, explanations, and progress tracking.
Try CompTIA PenTest+ PT0-003 on Web