PT0-002 Practice Question: A penetration tester is scoping a test for a…

Answer analysis

Option-by-option breakdown

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

• ✓

  Test using non-production accounts

  Why this is correct

  Using non-production accounts is the correct scoping choice because it creates synthetic identities that exist only in the test environment, preventing test traffic from contaminating production user data or triggering lockouts on real accounts. These accounts can be provisioned with known credentials in a dedicated test OU or group, enabling clean credential rotation and teardown after the engagement without touching production identity stores.

• ✗

  Conduct testing during off-peak hours

  Why it's wrong here

  Scheduling testing during off-peak hours reduces the chance of user-visible disruption, but it does nothing to isolate the test from production identity systems. Every authentication attempt still traverses the production Active Directory or IdP, consuming authentication capacity and generating logs that can trip anomaly detection; any misstep—such as an accidental password reset or policy change—would still affect real production accounts and could cause a targeted denial of service.

• ✓

  Use a separate domain for testing

  Why this is correct

  Leveraging a separate domain for testing is fully correct because it establishes a hard security boundary between test and production identity infrastructure. A dedicated AD forest or identity domain means authentication requests, group policy objects, certificate services, and federation trust settings are completely independent, so no test account or password policy can influence production users; this is the gold standard for isolating identity-related penetration testing.

• ✗

  Perform password spraying against all users

  Why it's wrong here

  Performing password spraying against all users is an attack technique, not a scoping or isolation method, and it is explicitly dangerous in a production environment. Spraying common passwords across the entire user population will rapidly approach or exceed account lockout thresholds, effectively causing an authentication denial of service; it also risks revealing valid credentials for real users, which violates the principle of least privilege and typical rules of engagement.

• ✗

  Disable MFA for test accounts

  Why it's wrong here

  Disabling MFA for test accounts is misguided because it changes the security posture you are supposed to be validating and creates a false sense of success. MFA is a critical control, and turning it off on any account—even a test account—weakens the overall identity infrastructure if the test accounts share the same domain or policy; it also prevents the test from accurately reflecting real-world authentication behavior, potentially missing MFA bypass flaws that should have been identified.

Go deeper

Related to this question