mediumMultiple ChoiceObjective-mapped
PT0-002 Practice Question: A client requires a penetration test of their web…
A client requires a penetration test of their web application that uses Single Sign-On (SSO) with a third-party identity provider. The client is concerned that testing could lock out real user accounts and disrupt operations. Which of the following should be included in the rules of engagement to address this concern?
⚠ Common exam trap
Many candidates assume restricting testing to business hours (Option C) is sufficient to mitigate account lockout risks, but they fail to recognize that lockout policies operate independently of time and that real user accounts remain vulnerable to disruption regardless of when testing occurs.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Provide test accounts that are excluded from lockout policies
Providing test accounts that are excluded from lockout policies allows the penetration tester to thoroughly assess the SSO authentication mechanism—including the SAML or OIDC flows—without risking the lockout of real user accounts. This directly addresses the client's operational concern while still enabling comprehensive testing of the identity provider integration.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Prohibit all testing of the authentication mechanism
Why it's wrong here
Prohibiting authentication testing would exclude a critical attack surface from the review, leaving the client blind to issues such as weak password policies, missing rate limiting, or exposure to credential-stuffing attacks. Authentication flaws are among the most commonly exploited web application risks, and a pentest contract that excludes them fails to meet the core goal of identifying exploitable security weaknesses. The rule should be to control testing via secure accounts and proper scope, not to forbid it entirely.
- ✓
Provide test accounts that are excluded from lockout policies
Why this is correct
Supplying test accounts excluded from lockout policies lets the tester simulate brute-force or password-spraying attempts on a dedicated account without the risk of locking out real production users. Since lockout thresholds are typically enforced after a small number of failed attempts, using these accounts allows repeated authentication attempts while preserving the availability and reputation of the client's legitimate user base. The accounts must be clearly segregated from production data and have restrictions on permissions to avoid unintended impact.
- ✗
Only perform testing during business hours
Why it's wrong here
Scheduling the test only within business hours does not address the root cause of account lockouts, because lockout counters trigger on failed authentication events regardless of the clock time. Within business hours, real users are actively logging in, so a burst of failed attempts could lock out legitimate staff and customers, directly causing a denial-of-service condition. The recommendation of test accounts excluded from lockout policies is specifically designed to mitigate this risk; time restrictions alone are insufficient and may even increase the chance of disrupting active users.
- ✗
Require the tester to use only passive reconnaissance techniques
Why it's wrong here
Passive reconnaissance—such as analyzing HTTP headers, public source code, and observed traffic—can provide intelligence about the application's technology stack and possible endpoints, but it cannot validate how the authentication mechanism behaves under real attacks. Flaws like improper session timeout, insecure password reset flows, and susceptibility to brute force are only discoverable through active attempts that send crafted requests and observe the application's responses. Relying solely on passive techniques would turn the assessment into a documentation review and fail to deliver actionable evidence of exploitable authentication vulnerabilities.
Go deeper
Related to this question
About these practice questions
Courseiva writes every PT0-003 question from scratch — 185 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PT0-003 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PT0-003 exam.