- A
The scanner used a payload that was blocked by a Web Application Firewall (WAF) before reaching the application
Why wrong: If a WAF blocks the payload, the scanner would typically get a different response (e.g., 403) and might not flag it as SQL injection; the assumption is the scanner got a response it interpreted as vulnerable.
- B
The application reflects the injected payload in error messages or response content, causing the scanner to think the injection succeeded
Many scanners check if the payload appears in the response (e.g., error messages containing SQL syntax). If the application echoes back the input without executing it, the scanner may misinterpret this as a successful injection.
- C
The scanner used outdated signatures that do not match the custom API's input validation logic
Why wrong: Outdated signatures could lead to missed vulnerabilities (false negatives) rather than false positives; false positives typically arise from response interpretation.
- D
The application returns a generic 'Invalid input' message for all types of invalid input, confusing the scanner
Why wrong: Generic error messages might reduce false positives because the scanner cannot distinguish between a blocked injection and a normal error; however, some scanners may still flag based on changes in response length or other heuristics.
Quick Answer
The answer is that the scanner is misinterpreting reflected payloads in error messages or response content as successful SQL injection. This happens because many automated vulnerability scanners, particularly when testing custom API frameworks, rely on detecting the injected string in the server’s response to confirm a vulnerability. If the application echoes back the payload—even in an error message or as part of input validation feedback—the scanner flags it as a successful injection, when in reality the database was never touched. On the CompTIA PenTest+ PT0-002 exam, this concept tests your ability to distinguish between a true SQL injection and a false positive caused by reflection, a common trap where students assume any echoed input indicates a breach. The key is to remember that reflection alone does not equal execution; manual testing is required to verify actual database interaction. Memory tip: “Reflection is just a mirror, not a window into the database.”
PT0-002 Practice Question: Information Gathering and Vulnerability Scanning
This PT0-002 practice question tests your understanding of information gathering and vulnerability scanning. The scenario asks you to isolate a root cause — eliminate options that address a different problem before choosing. After answering, compare your reasoning against the explanation and wrong-answer breakdown below. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.
A penetration tester is conducting a vulnerability scan of a web application that uses a custom API framework. The scanner reports several potential SQL injection vulnerabilities, but manual testing confirms they are false positives. The tester suspects the scanner is misinterpreting input validation. Which of the following is the most likely reason for these false positives?
Clue words in this question
Noticing these words before you look at the options changes how you read each choice.
Clue:
"most likely"Why it matters: Probability qualifier — the question wants the most probable cause or outcome, not a guaranteed one. Eliminate low-probability options.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
The application reflects the injected payload in error messages or response content, causing the scanner to think the injection succeeded
Option B is correct because the scanner likely detected the injected payload reflected in the application's response (e.g., in an error message or echoed input), which it interpreted as successful SQL execution. In custom API frameworks, input validation may reject the payload but still reflect it back in the response, causing the scanner to flag a false positive. Manual testing confirms the injection fails, so the reflection is merely a side effect of the API's error handling, not a sign of database interaction.
Key principle: Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The scanner used a payload that was blocked by a Web Application Firewall (WAF) before reaching the application
Why it's wrong here
If a WAF blocks the payload, the scanner would typically get a different response (e.g., 403) and might not flag it as SQL injection; the assumption is the scanner got a response it interpreted as vulnerable.
- ✓
The application reflects the injected payload in error messages or response content, causing the scanner to think the injection succeeded
Why this is correct
Many scanners check if the payload appears in the response (e.g., error messages containing SQL syntax). If the application echoes back the input without executing it, the scanner may misinterpret this as a successful injection.
Clue confirmation
The clue word "most likely" in the question point toward this answer.
Related concept
Read the scenario before looking for a memorised answer.
- ✗
The scanner used outdated signatures that do not match the custom API's input validation logic
Why it's wrong here
Outdated signatures could lead to missed vulnerabilities (false negatives) rather than false positives; false positives typically arise from response interpretation.
- ✗
The application returns a generic 'Invalid input' message for all types of invalid input, confusing the scanner
Why it's wrong here
Generic error messages might reduce false positives because the scanner cannot distinguish between a blocked injection and a normal error; however, some scanners may still flag based on changes in response length or other heuristics.
Common exam traps
Common exam trap: answer the scenario, not the keyword
The trap here is that candidates confuse 'reflected input' (which causes false positives) with 'stored input' or actual SQL error messages, assuming any reflection indicates a vulnerability, when in fact the scanner's heuristic is flawed for custom APIs that echo back sanitized input.
Detailed technical explanation
How to think about this question
False positives in SQL injection scanning often arise from 'reflected input' where the application echoes the payload in error messages, HTTP response bodies, or custom headers without actually executing it. Scanners like SQLMap or Nessus use pattern matching on response content to infer injection success; if the payload appears verbatim in the output, the scanner assumes the injection worked. In custom API frameworks, developers may implement input validation that rejects malicious characters but still includes the original input in error responses for debugging, creating a perfect false-positive scenario.
KKey Concepts to Remember
- Read the scenario before looking for a memorised answer.
- Find the constraint that changes the correct option.
- Eliminate answers that are true in general but not in this case.
TExam Day Tips
- Watch for words such as best, first, most likely and least administrative effort.
- Review why wrong options are wrong, not only why the correct option is correct.
Key takeaway
Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Real-world example
How this comes up in practice
A security team runs a vulnerability scan on a web application and discovers an unpatched SQL injection flaw. The team prioritises remediation by CVSS score — critical flaws are patched within 24 hours, high within 7 days. Questions like this test whether you understand vulnerability management processes, scanning tools, and remediation prioritisation.
What to study next
Got this wrong? Here's your next step.
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
- →
Information Gathering and Vulnerability Scanning — study guide chapter
Learn the concepts, then practise the questions
- →
Information Gathering and Vulnerability Scanning practice questions
Targeted practice on this topic area only
- →
All PT0-002 questions
509 questions across all exam domains
- →
CompTIA PenTest+ PT0-002 study guide
Full concept coverage aligned to exam objectives
- →
PT0-002 practice test guide
How to use practice tests most effectively before exam day
Related practice questions
Related PT0-002 practice-question pages
Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.
Planning and Scoping practice questions
Practise PT0-002 questions linked to Planning and Scoping.
Information Gathering and Vulnerability Scanning practice questions
Practise PT0-002 questions linked to Information Gathering and Vulnerability Scanning.
Attacks and Exploits practice questions
Practise PT0-002 questions linked to Attacks and Exploits.
Reporting and Communication practice questions
Practise PT0-002 questions linked to Reporting and Communication.
Tools and Code Analysis practice questions
Practise PT0-002 questions linked to Tools and Code Analysis.
PT0-002 fundamentals practice questions
Practise PT0-002 questions linked to PT0-002 fundamentals.
PT0-002 scenario practice questions
Practise PT0-002 questions linked to PT0-002 scenario.
PT0-002 troubleshooting practice questions
Practise PT0-002 questions linked to PT0-002 troubleshooting.
Practice this exam
Start a free PT0-002 practice session
Short sessions build daily habit. Longer sessions build exam-day stamina. Try a timed session to simulate real conditions.
FAQ
Questions learners often ask
What does this PT0-002 question test?
Information Gathering and Vulnerability Scanning — This question tests Information Gathering and Vulnerability Scanning — Read the scenario before looking for a memorised answer..
What is the correct answer to this question?
The correct answer is: The application reflects the injected payload in error messages or response content, causing the scanner to think the injection succeeded — Option B is correct because the scanner likely detected the injected payload reflected in the application's response (e.g., in an error message or echoed input), which it interpreted as successful SQL execution. In custom API frameworks, input validation may reject the payload but still reflect it back in the response, causing the scanner to flag a false positive. Manual testing confirms the injection fails, so the reflection is merely a side effect of the API's error handling, not a sign of database interaction.
What should I do if I get this PT0-002 question wrong?
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
Are there clue words in this question I should notice?
Yes — watch for: "most likely". Probability qualifier — the question wants the most probable cause or outcome, not a guaranteed one. Eliminate low-probability options.
What is the key concept behind this question?
Read the scenario before looking for a memorised answer.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
3 more ways this is tested on PT0-002
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A penetration tester is analyzing the results of a vulnerability scan against a web application. The scanner reports a potential SQL injection vulnerability in a login form parameter. However, manual testing with the same payload does not produce any error messages or changes in behavior. Which of the following is the most likely reason for the false positive?
medium- A.The scanner used a payload that was not URL-encoded
- ✓ B.The web application is using a parameterized query that sanitizes input
- C.The scanning engine is outdated and does not support the latest SQL syntax
- D.The login form is protected by a CAPTCHA that blocks automated scanning
Why B: Option B is correct because the use of parameterized queries (prepared statements) separates SQL logic from user input, preventing SQL injection even if the input contains malicious payloads. The scanner's payload triggered a false positive because the application's database layer safely handles the input, so no error or behavioral change occurs during manual testing.
Variation 2. A penetration tester runs a vulnerability scanner against a web server and receives a high-confidence alert that the server is vulnerable to Heartbleed (CVE-2014-0160). The tester manually verifies using an OpenSSL command and finds that the server is patched. Which of the following is the most likely cause of this false positive?
medium- ✓ A.The scanner's vulnerability signatures are outdated and still flagging the old behavior
- B.The scanner's plugin for Heartbleed was misconfigured and sent malformed packets
- C.The server returned a generic error message that the scanner misinterpreted as a sign of the vulnerability
- D.The scanner's network connection was intermittent, causing incomplete responses that were incorrectly flagged
Why A: Option A is correct because outdated vulnerability signatures are the most common cause of false positives in vulnerability scanning. The scanner's signature database likely still contains the original detection logic for Heartbleed (e.g., checking for a specific TLS heartbeat response length or pattern), which the patched server no longer exhibits. When the tester manually verified with an OpenSSL command (e.g., `openssl s_client -connect target:443 -tlsextdebug`), the patched server correctly handled the heartbeat request, confirming the scanner's alert was based on stale signatures.
Variation 3. A penetration tester is using a vulnerability scanner to assess a web application. The scanner reports a 'SQL Injection' finding with a high confidence level. However, manual verification of the same payload does not trigger the vulnerability in a browser. Which of the following is the most likely reason for this discrepancy?
medium- A.The scanner used a different HTTP method than the one used in manual testing
- B.The scanner's payloads were URL-encoded differently
- C.The vulnerability exists only in the scanner's simulated environment
- ✓ D.The scanner might have generated a false positive due to a misinterpretation of the server's response
Why D: The most likely reason is that the scanner generated a false positive due to a misinterpretation of the server's response. Vulnerability scanners often infer SQL injection based on response patterns (e.g., database error messages, timing differences) that may not actually be exploitable. Manual verification in a browser failed because the payload did not produce a true SQL error or data leak, confirming the scanner's alert was incorrect.
Last reviewed: Jun 11, 2026
This PT0-002 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PT0-002 exam.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.