PT0-002 Practice Question: A penetration tester is analyzing a Bash script…

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 a delay with 'sleep 1' between requests to avoid rate limiting.

  Why it's wrong here

  Adding 'sleep 1' between requests inserts a delay to throttle the request rate and avoid triggering rate limiting or IP bans, but this does nothing to interpret the responses. The script still produces raw output for every attempt, so the attacker must manually identify which response indicates a successful login. Rate limiting control is a pre-processing tactic, not a post-processing analysis of status codes or content.

• ✗

  Pipe the output to 'grep -v 200' to exclude any responses that are not 200 OK.

  Why it's wrong here

  Using 'grep -v 200' removes every line that contains the substring '200', which would delete all successful 200 OK responses and leave only failures and redirects. This is the inverse of the desired behavior, and because many login success responses are 302 redirects to a dashboard, those would remain but not be automatically flagged as successes. Additionally, grep operates on text lines, not structured HTTP status codes, so it may miss multi-line responses or status codes embedded in other output.

• ✓

  Add a conditional statement that checks if the HTTP status code is 302 (redirect) or 200, and if so, prints the successful credentials.

  Why this is correct

  Adding a conditional in the bash script to check for HTTP 302 or 200 and then printing the credentials directly automates the success detection. In web applications, a login form often responds with a 302 redirect to the authenticated user's dashboard upon success, or 200 with the post-login page; unsuccessful attempts typically return 401, 403, or 200 with an error message in the body. By capturing the status code with curl -w '%{http_code}' and comparing it in an if statement, the script can immediately isolate valid credential pairs from the noise, turning raw output into actionable findings.

• ✗

  Use 'curl -v' to see the full response headers.

  Why it's wrong here

  Running curl with the -v flag provides verbose output that includes request headers, response headers, and TLS handshake details, which is helpful for manual debugging of a single request. However, it outputs every request and response in full, making it even harder to parse through hundreds of attempts, and it does not apply any conditional logic to identify successful logins. The pentester would still have to visually scan each response, defeating the purpose of an automated script, and it certainly does not print the successful credentials by itself.

Go deeper

Related to this question