A vulnerability scan report says a web server is missing a patch rated critical. The infrastructure manager shrugs: the server sits behind a web application firewall and needs an internal account to reach the admin page. Two weeks later, a penetration tester shows a short screen recording in which an ordinary user account, a misconfigured file share and that unpatched server combine into control of the domain. The manager stops shrugging.
That is the purpose of a penetration test: to show what an attacker could actually achieve, not just list what might be wrong. On the CompTIA Security+ SY0-801 exam this sits under objective 5.5, which expects you to explain the concepts behind audit and assessment activities, including penetration testing. This lesson covers the testing environments, the physical, offensive, defensive and integrated test types, passive and active reconnaissance, and the authorization every test depends on. Reading and prioritizing a finished test report is covered in the vulnerability management section.
A penetration test proves impact; a vulnerability scan lists possibilities
A vulnerability scan is an automated check that compares systems against a database of known weaknesses and misconfigurations. It is broad, fast and repeatable, which is why organizations run scans weekly or continuously. A scan reports that a weakness probably exists. It doesn't try to use it, and it doesn't know how one finding relates to another.
A penetration test is an authorized, time-boxed attempt by skilled testers to exploit weaknesses the way a real attacker would, within an agreed scope. Testers use tools, but the value comes from people: confirming which findings are real, discarding false positives, and chaining small weaknesses into a serious compromise that no single scanner finding would show. A test ends with a report that demonstrates impact with evidence.
The two are complements, not substitutes. Scans find the routine problems often; tests show how bad those problems and the less obvious ones really are. Requirements reflect this. PCI DSS, for example, calls for internal and external vulnerability scans at least quarterly and internal and external penetration tests at least every twelve months and after significant changes.
On the exam, wording such as "verify that the vulnerability can be exploited," "demonstrate business impact" or "determine how far an attacker could get" points to a penetration test. Wording such as "identify missing patches across all hosts" or "check every server weekly" points to vulnerability scanning.
A typical test moves through planning and authorization, reconnaissance, scanning and enumeration, exploitation, post-exploitation (escalating privileges and moving to other systems to show how far access extends), reporting, and cleanup. Cleanup matters: testers remove accounts, files and tools they created, so the test doesn't leave weaknesses behind.
The testing environment is defined by what the tester is told
Objective 5.5 describes tests by how much the testers know at the start. The older terms white box, black box and gray box mean the same things, and you should recognize both sets.
In a known environment test, the testers receive full information: network diagrams, IP ranges, source code, configuration files and often accounts at several privilege levels. It is the most thorough way to find weaknesses in a short engagement, because no time is spent discovering what the organization could simply have told them. It doesn't show how an outsider with no inside knowledge would fare.
In an unknown environment test, the testers receive little more than the organization's name and the authorized scope. They must discover everything themselves, as an external attacker would. This gives the most realistic picture of an outside attack but takes longer, and it can miss weaknesses deep inside that the testers never reach in the time allowed.
In a partially known environment test, the testers receive some information, such as a standard user account, a list of in-scope subnets or a basic description of the application. This is the most common choice in practice because it balances realism with efficiency. It also models a realistic threat: an attacker who has phished one employee's credentials or a malicious insider with ordinary access.
| Environment | Older term | Tester starts with | Best for |
|---|---|---|---|
| Known | White box | Full documentation, code, accounts | Depth and coverage |
| Partially known | Gray box | Some access or details | Insider or phished-user scenarios |
| Unknown | Black box | Name and scope only | Realistic outsider view |