What a penetration test actually is, and is not

Objective 1.1 in this course covers planning and scoping — CompTIA describes it as defining rules of engagement, testing windows and target selection. This lesson sets up what is being scoped and why; the mechanics of writing the scope are in lesson 3.

Why this matters

Domain 1, Engagement Management, is 13% of PT0-003 — larger than most people expect from the domain with no exploits in it. It is also where the exam's scenario questions are hardest to bluff, because they are about judgement rather than recall.

There is a more practical reason to start here. Almost every professional mistake in this field is a scoping mistake, not a technical one. Testers do not generally get into trouble for failing to find a vulnerability; they get into trouble for touching something they were not asked to touch, at a time they were not asked to touch it, and for saying so badly afterwards.

The lesson

Where a test sits against a vulnerability scan and a red team

These three get used interchangeably by clients and are examined as distinct things.

• A vulnerability scan is automated and broad. It tells you what a tool recognises, at one moment, with a known false-positive rate. Nobody tries to exploit anything. Domain 3 is about doing this well.
• A penetration test is scoped, time-boxed and human. It asks whether the findings are real and reachable, chains them, and reports the business consequence. It is loud by default — the client knows it is happening.
• A red team engagement tests the client's detection and response, not their vulnerability list. Success is measured by what the defenders noticed, stealth matters, and scope is usually objective-based ("get to this data") rather than target-based.

The exam distinction that catches people: a penetration test is not trying to avoid detection unless the scope says so. If a client wants to know whether their SOC would catch you, that is a different engagement with different rules, and assuming it is your job to be quiet can mean you never test the thing they paid for.

Black, grey and white box, and what each buys the client

The difference is how much you are told before you start, and the trade-off is always the same one: realism against coverage.

• Black box — you get a name and nothing else. Most like an external attacker, and the worst value per hour, because you spend the budget rediscovering things the client could have told you in an email.
• Grey box — you get some knowledge: a network diagram, a standard user account, a list of in-scope ranges. The usual commercial choice, because it spends the budget on depth rather than on reconnaissance.
• White box — you get everything, up to and including source code and architecture documents. The best coverage per hour and the least realistic simulation.

The right answer in an exam scenario usually follows from what the client said they want to learn. "We want to know if our patching is working" is a white or grey box job. "We want to know what someone with no access could do in two weeks" is black box.

Why an unscoped test is worthless to both sides

A test with no scope cannot be finished, cannot be priced, and cannot be defended afterwards.

For the client, it produces a report they cannot act on: findings against assets they may not own, with no statement of what was not examined. A report that does not say where it stopped implies it went everywhere, and that is the most dangerous thing a security document can imply.

For the tester, the scope is the only evidence that what you did was authorised. "They asked me to test their security" is not a defence when the thing you touched turns out to be a third party's shared hosting.

The deliverable is the report, not the shell

This is the sentence most worth carrying into the exam and into the job.

A client cannot act on the fact that you got domain administrator. They can act on: which weakness let you in, what it would have taken to stop you, which of their controls fired and which did not, and what to fix first given what it will cost. The access is evidence; the report is the product.

That is why Domain 1 and Domain 5 together are 27% of PT0-003 — more than a quarter of the exam — and why both open and close on communication. It is also why a tester who cannot write is capped, no matter how good they are at the technical half.

What a test cannot tell a client about their security

A penetration test is a sample, taken by particular people, in a particular window, against a particular scope. Honest reporting means being clear about all four limits:

• It is not proof of absence. Finding nothing means this team found nothing in this time, not that nothing is there.
• It is a point in time. It describes the estate on the days you tested it. A deployment the following week can undo every conclusion.
• It is bounded by scope. Anything excluded is unexamined, and the report must say so plainly rather than leaving a silence.
• It reflects the testers. Different specialists find different things.

A client who believes a clean report means they are secure has been failed by the report, not by the test.

What to take into the exam

• Match engagement type to the client's stated question — the scenario usually tells you what they want to learn, and the answer follows from that.
• A penetration test is overt unless scoped otherwise; stealth is a red team property.
• The report is the deliverable. Expect scenario questions where the "best" action is a communication action, not a technical one.
• Know the four limits above well enough to recognise a report claim that overreaches.