PT0-002 Engagement Management Practice Question

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 API is secure because it is a well-known provider

  Why it's wrong here

  Relying on a provider's reputation or market share is a form of trust-based risk assumption, which violates the fundamental scoping principle that authorization must be explicit and documented for every system under test. Even well-known APIs can have misconfigurations, deprecated endpoints, or tenant-specific flaws that are not the provider's responsibility but could still be exposed through the client's integration. Furthermore, 'well-known' does not equate to 'in-scope,' and without a written authorization boundary, any testing performed against that API could constitute unauthorized access, creating legal liability for the tester and the client.

• ✗

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

  Why it's wrong here

  Excluding the API from testing entirely creates a false sense of coverage because the interaction between the client-side code and the API is often where injection flaws, authentication bypasses, and business logic issues manifest. A penetration test scope should encompass the entire attack surface of the application, including third-party dependencies that process or store sensitive data, not just the code the client owns. While it may be tempting to limit testing to the client's code for simplicity, doing so leaves the most critical trust boundaries unexamined and fails to provide the client with a meaningful risk assessment of the application as a whole.

• ✓

  Obtain written permission from the third-party provider before testing

  Why this is correct

  Written permission from the third-party provider is the only legally defensible basis for actively testing their API, as it establishes an authorization boundary that protects both the tester and the client from claims of unauthorized access under laws like the Computer Fraud and Abuse Act (CFAA) and similar regulations. This permission should explicitly define the testing scope, allowed techniques, and time windows, and it should ideally be obtained through the provider's official pen-testing authorization process or by adding the tester to the client's contract with the provider. Without such written authorization, even well-intentioned security testing can be construed as malicious activity, so obtaining this document is a non-negotiable prerequisite before any API testing begins.

• ✗

  Include the API in scope without permission because it is critical to the application

  Why it's wrong here

  Including the API in scope without the provider's permission is a direct violation of the rule that penetration testing must only be performed within the boundaries of explicit authorization. Even if the API is critical to the application's functionality, the tester does not have the standing to grant permission to themselves or to the client to test infrastructure owned by a third party. Unauthorized testing could lead to civil liability, criminal charges, or a permanent ban of the client's access to the API, which would be far more damaging than documenting the API as out-of-scope. The correct approach is to either obtain permission or formally exclude the API from the test and note it as a limitation in the final report.

• ✓

  Document the API as out-of-scope if permission is not granted

  Why this is correct

  Documenting the API as out-of-scope when permission is not granted is the professional and defensible way to manage scoping constraints, because it preserves the legal integrity of the entire penetration test while ensuring the client understands the residual risk. This documentation should appear in the rules of engagement, the scope section of the final report, and any executive summary so that stakeholders are aware that the API was not tested and may contain vulnerabilities. Additionally, the tester should recommend specific compensating controls, such as reviewing API logs for suspicious activity or performing a separate assessment once permission is obtained, to help mitigate the risk in the interim.

Go deeper

Related to this question