PT0-002 Practice Question: During a vulnerability scan, a penetration tester…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Enable SYN scan instead of full TCP connect scan

  Why it's wrong here

  Enabling a SYN (half-open) scan alters the TCP handshake method used for port discovery, minimizing the number of fully established connections and logs left on the target. However, this choice only affects how ports are identified; once a port is discovered, the vulnerability scanner's plugin engine will still run the same suite of service-detection and exploit-testing plugins. The aggressiveness of those plugins is governed by separate options (such as 'safe checks'), not by the underlying port-scan technique.

• ✗

  Adjust the scan timing template to a slower rate

  Why it's wrong here

  Adjusting the scan timing template to a slower rate (for example, T1 or T2) reduces packet transmission speed, connection parallelism, and overall network load, which can help avoid overwhelming the target or tripping intrusion detection systems. That said, timing templates only control the scanner's bandwidth and pacing; they do not in any way alter the set of vulnerability checks that will be executed against open services. Even a deliberately slow scan will still attempt the same potentially intrusive exploit plugins that could disrupt a service, so this does nothing to make the scan safer.

• ✓

  Activate the 'safe checks' option in the scanner

  Why this is correct

  Activating the 'safe checks' option is the correct solution because it instructs the scanner to suppress all plugins that are flagged as intrusive, disruptive, or destructive, and instead rely on non-invasive methods such as banner grabbing, version fingerprinting, and configuration analysis. This prevents the scanner from actively attempting to exploit a vulnerability to confirm its existence, thereby avoiding service crashes, data corruption, or other unintended side effects. It also reduces false positives that can arise from failed exploit attempts, making the scan results more reliable in a production environment.

• ✗

  Increase the port range to include high ports

  Why it's wrong here

  Increasing the port range to include high ports broadens the scope of the scan by telling the scanner to probe more TCP/UDP port numbers, which might reveal web interfaces on 8080, management consoles on 8443, or other high-port services. However, this change simply expands which ports are checked; it has no effect on the scanner's testing policy or the plugins that will be executed against those discovered services. If the scanner's plugin set contains dangerous checks, those will still be fired at any newly found open port, so this option does not reduce the aggressiveness of the scan.

Go deeper

Related to this question