mediumMultiple Choice
PT0-002 Practice Question: A client wants a penetration test of their cloud…
A client wants a penetration test of their cloud infrastructure hosted on AWS. The client states that they want to test the security of their EC2 instances, S3 buckets, and IAM configurations. The client's security team is concerned about potential service disruption due to testing. Which of the following should be included in the rules of engagement to address this concern?
⚠ Common exam trap
Many exam-takers choose options A or C, mistakenly believing that avoiding automation or restricting testing hours will prevent service disruption, when in reality the key is having a clear, measurable definition of disruption and a stop condition, as required by the PT0-002 exam's focus on scoping and risk management.
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
✓
A clear definition of what constitutes a denial-of-service condition and a requirement to stop testing immediately if such a condition is detected.
It directly addresses the client's concern about service disruption by establishing a clear threshold for denial-of-service (DoS) conditions and a mandatory stop action. In AWS, automated scanning or aggressive testing can inadvertently trigger Auto Scaling events, exhaust burst credits on EC2 instances, or saturate S3 request limits, leading to degraded performance. Defining what constitutes a DoS condition (e.g., CPU > 90%, network packet loss > 5%) ensures the tester can halt immediately, protecting the client's cloud infrastructure while still allowing effective security testing.
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 that the tester will avoid using any automated scanning tools.
Why it's wrong here
Banning all automated scanning tools is counterproductive in cloud engagements because the environment is dynamic and has a huge API-driven attack surface; automated scanners are needed to enumerate resources like buckets, IAM roles, and network controls at scale. A blanket clause can be reworded to require safe scanner configuration—rate limiting, low concurrency, and excluding availability-sensitive endpoints—instead of an outright ban. Without automated discovery, many common cloud misconfigurations would be missed, and test results would not be repeatable.
- ✓
A clear definition of what constitutes a denial-of-service condition and a requirement to stop testing immediately if such a condition is detected.
Why this is correct
To protect a cloud client from accidental availability impact, the rules of engagement should define explicit DoS indicators—for example, sustained packet loss, error-rate thresholds, or load-balancer health-check failures—and require the tester to stop immediately when any indicator is seen. Cloud elasticity can mask or amplify failures, so predefined numeric thresholds and a communication plan let both sides distinguish test-induced disruption from real incidents. This clause is superior because it directly manages the highest-risk outcome of penetration testing rather than merely limiting when or how testing may occur.
- ✗
A requirement that the tester only performs manual testing and no tools.
Why it's wrong here
Mandating manual-only testing and no tools is both ambiguous and harmful: a tester cannot meaningfully evaluate cloud configurations without API calls and scripting, and every manual action ultimately goes through a client or proxy tool. It also fails to protect availability because a carefully crafted curl request can still trigger an auto-scaling event or saturate a service, just like automated traffic. The clause should focus on approving specific tooling and setting impact thresholds, not on a blanket ban that destroys coverage and makes evidence collection difficult.
- ✗
A clause that the tester will test only during business hours.
Why it's wrong here
Restricting testing to business hours does not prevent a DoS condition, and in many deployments the production workload peaks during those hours, making any accidental disruption more costly. Cloud infrastructure is often globally distributed and follows multiple time zones, so 'business hours' is vague, and emergency response or maintenance coverage is usually better outside normal shifts. Effective rules should identify maintenance windows, pre-approved high-impact tests, and symptom-based stop criteria rather than arbitrarily limiting tests to daytime.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
This PT0-003 question is part of Courseiva's 777-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.