PT0-002 Practice Question: During the scoping phase of a penetration test, 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.

• ✗

  Proceed with testing the API but restrict the test to read-only operations

  Why it's wrong here

  Performing read-only API testing still constitutes unauthorized access, since the legal question hinges on authorization rather than the specific HTTP method used. Even GET requests can trigger side effects such as rate-limit consumption, verbose error logs, or exposure of sensitive data through insecure direct object references. Without explicit written authorization from the third-party owner, any interaction, whether read-only or mutating, violates the scope boundary and may breach the Computer Fraud and Abuse Act or similar statutes. The tester must strictly limit all activities to systems the client has the authority to authorize.

• ✓

  Exclude the third-party API from the scope and document the limitation

  Why this is correct

  Excluding the third-party API from the scope and documenting the limitation is the correct approach because the client cannot legally grant authorization for systems they do not own. The scoping document and rules of engagement must explicitly list out-of-scope assets, preventing any ambiguity during testing. This also creates a clear record that the client was informed of the limitation, which they can use to seek independent authorization or a separate contract with the API provider. Such documentation is essential for maintaining legal and professional defensibility of the penetration test.

• ✗

  Contact the third-party provider directly to obtain permission

  Why it's wrong here

  Contacting the third-party provider directly is inappropriate because the penetration tester is not a party to the contractual relationship and lacks the standing to negotiate testing permissions. The client is responsible for managing provider relationships and must obtain written authorization through their own legal and procurement channels. Direct contact by the tester could violate the confidentiality provisions of the rules of engagement, expose sensitive details of the assessment, and create unintended legal exposure for both the client and the tester. The proper escalation path is for the client to request permission formally and incorporate any granted access into a revised scope.

• ✗

  Include the API in the scope and note the legal risks in the report

  Why it's wrong here

  Including the API in the scope without permission and merely noting legal risks in the report does not transform unauthorized access into an authorized test. The act of probing the API itself—regardless of a disclaimer—may constitute a violation of the third party's terms of service, the Computer Fraud and Abuse Act, or other cybercrime laws. Writing about the risk after the fact cannot mitigate the fact that no authorization existed before the testing activities commenced. Authorization must be obtained and documented before any testing begins, not rationalized retroactively in the final deliverable.

Go deeper

Related to this question