PT0-002 Practice Question: A client hires a penetration testing firm to…

Answer analysis

Option-by-option breakdown

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

• ✗

  Assume the client has already obtained permission from the API provider

  Why it's wrong here

  Assumption is a high-risk shortcut in penetration testing: the client cannot bind a third party, and verbal assurances or 'management approval' do not constitute a legal authorization surface. If the assumption later proves false, the tester bears liability for unauthorized access under laws like the CFAA or equivalent statutes. Even with the client's best intentions, only the API provider's documented, written grant of permission protects the tester legally, so an assumption is never a defensible substitute.

• ✓

  Obtain written authorization from the third-party API provider

  Why this is correct

  Written authorization from the third-party API provider is the only legally binding endorsement for testing infrastructure you do not own. It must be explicit about the scope, IP ranges, endpoints, methods, and time window to avoid exceeding authorized access. Without it, the tester risks criminal or civil liability regardless of the client's request, because the client lacks legal authority to deputize a tester on the provider's systems. A provider's documented permission also protects the client's future relationship and the tester's professional standing.

• ✗

  Rely on the client's statement that the API is within scope

  Why it's wrong here

  The client's statement that the API is 'in scope' is merely a claim about a contract between the client and the API provider; it does not transfer authorization to the penetration tester. The tester must independently verify scope by reviewing the actual authorization document or by obtaining direct confirmation from the provider. Relying on a secondhand assertion from the client leaves the tester exposed to unauthorized-access claims if the provider's terms or contract actually prohibit testing. Scope is a legal fact, not a matter of the client's interpretation.

• ✗

  Test only the client's application code and ignore the API

  Why it's wrong here

  Testing only the client's application code while deliberately ignoring the API would leave the API's attack surface unexamined, thus failing the client's explicit request to include the API and producing an incomplete risk assessment. However, it is also a misstep because the API may expose the same vulnerabilities—such as broken object-level authorization or injection flaws—that exist in the rest of the application. This option avoids the legal issue by sidestepping the third-party asset, but it violates the engagement's terms and yields a false sense of security, making it an unethical and technically inadequate choice.

Go deeper

Related to this question