A municipal public website starts returning 429 and gateway errors after the tester launches aggressive automated crawls. Rules of engagement cap request rates and protect availability. What should the tester do next?
Select an answer to reveal the explanation.
Short Explanation
Think of the site like a busy front counter: slamming it with requests just creates a line that breaks for real residents. Slow down to what the rules allow, watch for pain, and keep gathering intel without taking the service down.
Full Explanation
When a municipal public website returns 429 and gateway errors after aggressive crawls, and RoE caps request rates to protect availability, the tester should throttle crawl speed to those limits, pause if availability degrades, and continue ethical recon. Ignoring errors and increasing concurrency is unsafe. Switching to unrestricted DoS tooling to force the site offline violates RoE and ethics. Disabling rate limiting on a client CDN without documenting change is unauthorized modification. Exam caveat: availability impacts on civic sites can affect public access to services—treat degradation as a stop-and-notify event. Operational check: reduce threads and requests-per-second to RoE caps, verify the site recovers, notify the designated contact if errors persist, and resume only at sustainable rates. Document the rationale in the municipal engagement notes so later civic responders know which boundary was honored and which failure modes the rejected options would create for public services. Document the rationale in the municipal engagement notes so later civic responders know which boundary was honored and which failure modes the rejected options would create for public services. Document the rationale in the municipal engagement notes so later civic responders know which boundary was honored and which failure modes the rejected options would create for public services.