PT0-002 Practice Question: During a penetration test of a large e-commerce…

Answer analysis

Option-by-option breakdown

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

• ✗

  Add the microservice to the test and include it in the final report as an unadvertised finding

  Why it's wrong here

  Proceeding to test the microservice and slipping it into the final report as an unadvertised finding bypasses the mutually agreed Rules of Engagement (RoE). This unilateral scope expansion can invalidate the penetration test's legal authorization, expose the tester to liability under computer fraud statutes, and undermine the admissibility of any evidence collected. In professional practice, every test must be explicitly covered by the signed scope and authorization, and unadvertised findings beyond that scope are a contractual violation, not a value-add.

• ✗

  Decline the request because the microservice was not part of the original scope

  Why it's wrong here

  Declining the request outright is overly rigid and fails to recognize that scope is not immutable. The correct first step is to engage the client in a scoping discussion, clarifying whether the microservice handles sensitive data, exposes a new attack surface, or should be considered in-scope via a formal amendment. Refusing without dialogue risks damaging the client relationship and missing a genuine security concern, as the original authorization can be legally extended through a signed change request.

• ✓

  Inform the client that a scope amendment is needed and pause testing on the microservice until it is approved

  Why this is correct

  This is the required professional response because the authorization to test is defined by the signed RoE or statement of work, and any new system falls outside that legal boundary. Pausing testing on the microservice until a formal scope amendment is approved protects both parties from legal exposure and ensures that any findings are defensible and actionable. The amendment process typically involves updating the contract with the new IP address/domain, explicit testing rules, and client sign-off, after which testing can resume safely.

• ✗

  Test the microservice only if it is using the same technology stack as other targets

  Why it's wrong here

  Basing authorization to test on a technology stack similarity is a dangerous fallacy; legal permission to perform penetration testing is not derived from technical characteristics but from explicit contractual consent. Even if the microservice uses an identical framework, language, or deployment model as in-scope targets, testing it without a scope amendment is unauthorized and could constitute illegal access. The RoE defines permissible targets by asset identifiers (hostnames, IP ranges, application names), not by implementation details, so any similarity is irrelevant without a documented expansion.

Go deeper

Related to this question