Vendor-neutral reference pattern
Defense in depth: layered controls for a public web application
One firewall is a wall. Defense in depth is a maze: even after an attacker clears the front door, several more independent controls stand between them and your data.
Why one control is never enough
Defense in depth is the practice of stacking several independent controls so that no single failure exposes the asset you care about. The assumption behind it is blunt: any one control will eventually fail, be misconfigured, or be bypassed by a technique it was never designed to catch. If a public web application sits behind only a firewall, then the day that firewall rule is fatfingered, or the day an attacker finds a flaw the firewall cannot inspect, the whole system is open.
Layering fixes this by making the controls overlap without depending on each other. A packet-filtering firewall works at Layer 4 on addresses and ports; a web application firewall works at Layer 7 on the contents of the HTTP request; an intrusion prevention system matches known attack signatures; network segmentation limits where a compromised host can go next; encryption protects the data even if every network control is bypassed. An attacker has to defeat each layer in turn, and the layers do not share the same weakness, so a bypass that beats one rarely beats the next.
Walking the layers from internet to data
Follow a request inward. At the perimeter, an edge router carries a coarse ingress access control list that drops spoofed source addresses and disallowed protocols, trimming the attack surface before anything more expensive inspects the traffic. Behind it, a next-generation firewall does stateful Layer 4 filtering and runs an inline intrusion prevention system, so it can both block by port and drop packets that match an attack signature. It permits only inbound HTTPS to the application front end and denies everything else, and it fails closed if it loses its ruleset.
The request then meets a web application firewall, a reverse proxy that terminates TLS and reads the actual HTTP payload to catch SQL injection, cross-site scripting, and other application-layer attacks the packet firewall cannot see. Only after passing that does traffic reach the web server, which lives alone in a screened subnet so that compromising it grants no direct route inward. Between the web tier and the rest of the network sits an internal firewall with a default-deny stance: it lets the web server reach only the application server on one service port, and the application server is the only host allowed to query the database. Administrators never appear in this public path at all; they reach the servers through a VPN gateway that requires multifactor authentication, keeping management interfaces off the open internet.
Same layers, different control categories
The exam also asks you to classify controls, and defense in depth is easiest to reason about when you see that the layers fall into different categories and types on purpose. By category, most of the stack is technical (firewalls, the WAF, the IPS, encryption), but the design also leans on operational controls (log review, change management for firewall rules) and managerial controls (the policy that says management access must use the VPN). A locked server room and a badge reader would add physical controls to the same asset.
By type, the same devices play different roles. The edge router, firewall, WAF, and VPN are preventive: they stop the unwanted action outright. Logging, an intrusion detection sensor on a tap, and file integrity monitoring are detective: they do not block, they tell you something happened. The IPS dropping a matched packet and the patch that closes the flaw are corrective. A warning banner is deterrent. When you cannot fix a vulnerable component immediately, a WAF rule that virtually patches the specific exploit is a compensating control, and the written policy requiring MFA on the VPN is a directive control. Defense in depth is strongest when the layers span these categories, because an attacker who evades every preventive control still trips a detective one and leaves evidence.
Failure modes and placement decisions
Layering only helps if each device is placed and configured to fail safely. A control that is inline (physically in the traffic path, like the firewall and IPS here) can block attacks but becomes a potential outage point, so its failure mode matters: fail-closed denies traffic when the device dies, protecting the asset at the cost of availability, while fail-open passes traffic to preserve availability at the cost of security. A detection-only sensor is usually deployed passively on a tap or mirror port so that its failure cannot break production traffic at all; it just stops seeing.
Device placement follows the security zones. Anything internet-facing goes in the screened subnet, never on the internal LAN. The most sensitive asset, the database, sits deepest, reachable only through the application tier, so the number of controls between it and the internet is greatest. This is the core selection-of-controls idea: match the strength and number of layers to the value of what they protect, put preventive controls in the path and detective controls beside it, and never let a single device be the only thing standing between an untrusted network and regulated data.
Sources
Practice what you just read