A denial-of-service attack has one purpose: to make a service unavailable to the people who are supposed to reach it. Nothing is stolen, nothing is read, nothing is altered. The attacker exhausts a finite resource, whether that is bandwidth, connection slots, or CPU time, until legitimate requests can no longer get through. A distributed denial of service (DDoS) does the same thing from many sources at once, often thousands of them, which is what makes the flood large enough to matter and hard to block by address.
Fix the goal in your head before anything else in this course: the objective is denial of availability, not disclosure of data. A DDoS against a storefront does not hand the attacker a customer list; it simply drowns the front door so nobody can walk through it.
That precision matters because a DDoS is easy to mistake for three other problems that look similar from the outside but demand completely different responses.
| Event | What actually happened | Right first response |
|---|---|---|
| DDoS | A resource was flooded from outside | Engage upstream mitigation |
| Breach | Data was read or stolen | Forensics, disclosure, credential rotation |
| Hardware failure | A disk, NIC, or host died on its own | Replace hardware, restore from backup |
| Ordinary outage | A bad deploy or bug crashed the service | Roll back the change |
Treating a hardware failure as an attack wastes hours calling a DDoS desk that cannot fix a dead disk, just as treating a real flood as a bug wastes those hours redeploying code that was never broken. The rest of this module teaches you to read the symptom correctly.
The first minute of an incident is a diagnosis, not a fix. Naming which row of the table you are actually facing decides everything that follows.