PT0-002 Practice Question: A client is planning a penetration test of their…

Answer analysis

Option-by-option breakdown

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

• ✗

  A clause requiring the client to provide a complete list of in-scope IP addresses.

  Why it's wrong here

  A complete IP inventory is often unavailable or inaccurate in complex networks, and the client may refuse to share it for security reasons, making such a clause unenforceable or leading to scope gaps. More importantly, it is a reactive documentation requirement, not a technical safeguard: even with a perfect list, aggressive scanning can still saturate links, exhaust connection tables, or crash fragile network appliances. Rate limiting directly constrains the tester's tool behavior independent of the client's data, so it is the only measure that inherently prevents self-inflicted denial-of-service.

• ✗

  A waiver stating that any service disruption is the client's responsibility.

  Why it's wrong here

  A liability waiver is a legal risk-transfer mechanism that may shield the tester contractually, but it does not alter the operational reality that a disruption can take down production services, trigger incident response, or cause data loss. The testing organization still bears reputational damage and violates the professional duty to avoid harm, so a waiver that only manages legal aftermath is insufficient. Rate limiting is a proactive constraint that reduces the probability of failure in the first place, while a waiver merely addresses consequences after an avoidable incident occurs.

• ✓

  A rate-limiting clause that restricts scan speed and concurrent connections.

  Why this is correct

  A rate-limiting clause operationalizes a technical control by constraining packets per second, concurrent connections, or tool-specific throttling such as Nmap's `--max-rate`, `--max-parallelism`, or timing templates. This directly reduces the risk of resource exhaustion on stateful devices like firewalls, load balancers, and application servers that have limited session tables or timeouts. Because the tester often lacks full visibility into the client's device capacities, a conservative rate limit keeps scan traffic within a safe tolerance and prevents self-inflicted DoS, even when network details are unknown.

• ✗

  An exclusion list for systems that should not be tested.

  Why it's wrong here

  An exclusion list only protects systems the tester explicitly knows about; it depends on the client accurately identifying all critical or fragile devices, which may be impossible or inconsistently communicated. It is a binary allow/deny mechanism that does nothing to reduce scan intensity on the remaining in-scope hosts, so a sensitive device not on the list—or one that becomes fragile due to load—can still be knocked offline. Rate limiting applies uniformly to all targets, shrinking the blast radius regardless of whether a specific host was pre-identified, making it a more comprehensive safeguard.

Go deeper

Related to this question