PT0-002 Practice Question: A penetration tester is prioritizing remediation…

Answer analysis

Option-by-option breakdown

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

• ✗

  Vulnerabilities that require significant code changes first.

  Why it's wrong here

  Prioritizing vulnerabilities that require significant code changes first confuses remediation effort with risk. A critical remote code execution flaw that demands a large refactor must still be scheduled ahead of a low-severity cosmetic issue, because leaving it unaddressed exposes the organization to an actively exploitable high-risk condition. This approach also delays quick wins, as the team spends cycles on long-lived changes while numerous faster, impactful mitigations remain undone.

• ✗

  Vulnerabilities with the lowest CVSS scores to clear many issues quickly.

  Why it's wrong here

  Lowest-CVSS vulnerabilities are by definition lower in severity and typically have limited exploitability or impact, so fixing them first fails to reduce meaningful organizational risk. This tactic optimizes for ticket count rather than risk reduction, which is a common pitfall in immature remediation programs. Furthermore, a low-severity finding may be contextually irrelevant next to an unpatched critical vulnerability, and attackers will target the high-severity path regardless of how many low-severity issues are closed.

• ✓

  Critical and high severity vulnerabilities, especially those that are easy to fix.

  Why this is correct

  Critical and high severity vulnerabilities correspond to the greatest potential for exploitation and business impact, so addressing them first is the core of risk-based prioritization. When those fixes are also easy to implement—such as applying a patch, changing a config, or disabling a vulnerable service—they deliver immediate risk reduction and build momentum for the remediation workflow. This approach aligns with standard frameworks like CVSS severity, exploitability scoring, and asset criticality, while still allowing quick wins to be captured without spending enormous effort.

• ✗

  All vulnerabilities in the order they were discovered.

  Why it's wrong here

  Remediating vulnerabilities in discovery order ignores all information about severity, exploitability, and the value of the affected asset. A critical vulnerability found three weeks ago could still be unmitigated while the team spends time fixing a long backlog of informational findings that pose no demonstrable threat. This method is purely arbitrary and can leave the most dangerous attack vectors exposed for longer, which is why professional penetration testing reports always present a prioritized remediation section rather than a chronological list.

Go deeper

Related to this question