PT0-002 Practice Question: A penetration tester is presenting findings to a…

Answer analysis

Option-by-option breakdown

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

• ✗

  Use high-level business language only

  Why it's wrong here

  Technical audiences, such as system administrators and developers, expect to see the specific technical details behind a vulnerability—like affected services, port numbers, CVE identifiers, and the exact attack sequence. Using only high-level business language obscures these mechanics, making it impossible for them to validate the finding, assess its true exploitability, or begin triaging the issue. This approach treats a technical audience like an executive board, which fails to meet their need for actionable intelligence.

• ✓

  Demonstrate the exploit steps

  Why this is correct

  Demonstrating the exploit steps is essential for a technical audience because it proves the vulnerability is exploitable and shows the exact commands, tools, and conditions required to achieve the compromise. This hands-on walkthrough allows the defenders to understand the full kill chain—from initial access to privilege escalation—and to map those steps to their own detection and prevention controls. Seeing the exploit in action also removes any ambiguity about whether the finding is a false positive, because the tester can show the actual impact in a controlled environment.

• ✓

  Show evidence like packet captures

  Why this is correct

  Evidence like packet captures, logs, and payload samples provides objective proof that the vulnerability was exploited and documents the network footprint of the attack, including source IPs, timestamps, and the specific packets or protocol anomalies. This lets the technical team correlate the finding with their own monitoring tools, confirm that a similar compromise hasn't already occurred in production, and craft precise detection signatures or firewall rules. Without such artifacts, the finding remains an unverifiable claim, which weakens its credibility in a technical debrief.

• ✓

  Provide detailed remediation commands

  Why this is correct

  Technical staff need detailed remediation commands—such as exact patch versions, configuration directives, SQL parameterization examples, or firewall rule snippets—to implement a fix efficiently and correctly. Generic advice like "update software" or "apply best practices" is insufficient because engineers must know which package to update, which file to change, and how to verify the fix after applying it. Providing these specifics also enables them to follow change-management procedures and document the remediation for compliance audits, making the fix reproducible and auditable.

• ✗

  Focus on strategic recommendations

  Why it's wrong here

  Strategic recommendations, such as improving overall security posture or embracing a zero-trust architecture, are oriented toward executive decision-makers and long-term risk management, not the immediate needs of a technical team. They lack the operational specificity required to patch a specific vulnerability, reconfigure a service, or adjust an intrusion detection rule, which leaves engineers without a clear path to action. For a technical audience, focusing on strategy instead of tactical mitigation can delay the actual remediation and create gaps between the testing findings and the actual security fixes.

Go deeper

Related to this question