Defense in Depth

A POST /orders request touches at least six layers before a row is committed: DNS resolution, edge termination, network path, host, application code, and the data store — plus the humans who operate all of it. Defense in depth is the discipline of placing controls at every one of those layers, and of asking three questions at each: what prevents abuse here, what detects it if prevention fails, and what corrects the damage afterward.

The full matrix for the order service looks like this:

Not every layer is yours to control, and saying so out loud is part of the design. On managed platforms the provider owns host and physical-layer controls — hypervisor patching, disk destruction, hypervisor isolation — while you own identity, network configuration, data classification, and everything above the runtime. Writing that division into the review prevents both failure modes: gaps ('surely someone patches it') and wasted effort (a meticulous AMI hardening standard written for a serverless platform where no AMI exists).

Two columns deserve commentary. The detective column is where architecture reviews usually have holes — teams ship preventive controls because they stop visible abuse, then cannot answer 'how would you know this happened?' A prevention that fails silently is indistinguishable from a prevention that never existed. The corrective column is where security meets operations: a corrective control without a rehearsed runbook is a wish. The quarantine security group does nobody any good if the on-call engineer has never seen it documented as a step.

The categories also have different cost signatures, which is the design lever. Preventive controls are usually cheap in operations but expensive in friction: hardware MFA adds seconds to every login, review gates add hours to every release. Detective controls are cheap to install and expensive to sustain — an alert stream with no responder becomes noise, and alert fatigue is a security defect, not a staffing complaint. Corrective controls are mostly discipline: backups you have actually restored, kill switches you have actually pulled, revocation steps you have actually timed.

A common framing error to avoid in interviews: defense in depth is not the claim that more controls are always better. It is the claim that a failed control must leave another independent control standing behind it. A perimeter firewall that is your only control is a single point of failure with a marketing budget. The firewall plus application-layer validation plus least-privilege database credentials is a posture, because the failure of the first leaves the second and third operative. The next chapter takes that word — independent — and shows why it is harder to achieve than it sounds.

Assume the perimeter fails, because it will. A realistic path: an attacker finds that your WAF's request-smuggling rule does not parse a chunked body the way your API framework does. The request that reaches order-service is malformed in a way the firewall believed impossible. Now the question that separates a layered design from a slogan: what still holds?

Behind a well-layered perimeter, four things catch this attacker in sequence. Application-layer input validation with parameterized queries rejects the malformed payload no matter how it arrived — the WAF was never the thing making SQL safe. Least-privilege database credentials mean the order service can INSERT and SELECT on one table and nothing else, so even code execution in the app does not yield a database-wide dump. Egress filtering denies outbound connections except to the queue and the vendor allowlist, so a reverse shell finds nothing to talk to. And export-volume anomaly detection fires when a process that normally reads 200 rows a minute reads 400,000.

Write out the multiplication explicitly, because it is the whole argument. If two controls independently each stop 90% of relevant attempts, an attacker passing both drops to roughly 1% — two nines of reduction from two controls, not one. Stack three and you are at 0.1%. That arithmetic only holds when the failures are independent, and independence is the property you are actually buying with the second control.

Correlated controls do not multiply. Three rules parsed by products from one vendor can share the same parsing bug. Worse is the trust correlation: if the application blindly trusts an X-User-Id header injected by the gateway, and the attacker finds any path to the application that bypasses the gateway — a stale internal load balancer, a direct pod address inside the VPC — then the WAF, the gateway, and the header check are one control wearing three costumes. The test for independence is: does this control fail for a different reason than the one in front of it? Different vendor, different layer, different failure mode — that is what earns the multiplication.

Flat networks are the other classic collapse. A perimeter-only design treats everything inside as safe, so a single compromised workload walks the subnet: it queries the metadata service for instance credentials, connects to any database that accepts the security group, and calls internal admin panels that were never meant to be reachable. Layering applied inside the network — per-service identity, east-west filtering, egress allowlists — is what stops a break-in from becoming a breach report.

Insider abuse completes the picture, because no perimeter setting addresses it. A support engineer with legitimate data-store access exports a customer table 'for a report.' Prevention at the edge saw nothing wrong — every request authenticated and looked ordinary. What catches this is the data layer: query auditing that flags bulk exports by a principal whose history is point lookups, and DLP volume rules on the egress path. What limits the damage is row-level scoping that made only one segment reachable in the first place. Layering is not only about the external attacker walking your stack outside-in; the same independent controls bound the authorized-but-malicious path inside-out.

Two honest caveats for the interview room. Layered controls multiply attacker effort; they do not make you safe — design detection assuming prevention fails, because some day it will. And layering has a real cost: each control is another failure surface, another latency hop, another team's on-call. The point is not maximal stacking, it is selecting independent controls whose combined cost is less than the loss they make improbable.

Security teams never have budget for every control, so the interview question behind every design is really: how do you choose? The working method is to price controls by what they cost and what they stop, then place them where the marginal dollar removes the most risk.

Three patterns fall out of that table. First, the cheap controls are underused: rate limiting, egress allowlists, and encryption at rest each cost days and remove whole attack classes — if your design review skips them because they are not glamorous, the budget went to the wrong place. Second, expensive-but-independent controls (the mesh) earn their cost exactly when you can name the correlation they break; 'we read about mTLS' is not that name. Third, the expensive column includes human friction, and friction is a real design constraint: an MFA prompt that takes 15 seconds on a workflow run 400 times a day will be routed around by your own engineers, and a control your users defeat is a control an attacker gets for free.

Use the same pricing logic on the detective side. Every alert should name the runbook it triggers; an alert with no runbook is noise with a pager attached. An alert-noise budget matters as much as a money budget — teams that page on everything learn to ignore paging, and then the one alert that mattered is acknowledged by nobody. Sampled auditing plus threshold alerts on the signals you have runbooks for beats comprehensive monitoring nobody reads.

For the interview, the reliable structure for 'how would you secure X' is: name the preventive controls by layer in the order a request meets them; name the control most likely to fail first and why; name the detective control that would reveal that failure; name the corrective step that limits damage once it happened. That answer shows you think in independent layers rather than in products.

One trap to call out explicitly: perimeter-heavy, data-light designs. Visible controls live at the edge where demos happen; the crown jewels — tokens, PII, signing keys — sit at the data layer with one access control and no audit. If your budget put 80% at the edge and the data store has never had a restore test, you have a fort with an unlocked archive.

The final piece of the posture is that layered controls still assume a trusted network path between them — that the call arriving at layer two really came from layer one. Zero Trust Architecture removes that assumption and asks a sharper question: what proof does each individual request carry, no matter where it originates?