1.1.2. Defense in Depth Across Cloud and AI
💡 First Principle: No single control is perfect, so security is built as layers — each one catches what the layer before it missed. A gap in one layer should be an inconvenience, not a breach.
The domains in this guide map almost directly onto defense-in-depth layers: identity and governance (Phase 2) sit at the innermost layer controlling who can act; network controls (Phase 3) restrict how resources can be reached; compute-level controls (Phase 4) harden the workloads themselves, including the newly-added AI layer; and posture management and monitoring (Phase 5) is the outermost layer watching for anything that got through. AI workloads don't get a separate defense-in-depth model — they inherit all four layers and add agent-specific concerns (like blast radius and prompt-injection guardrails) on top.
| Layer | Primary Controls | Covered In |
|---|---|---|
| Identity & governance | Entra ID, PIM, Conditional Access, RBAC, Policy | Phase 2 |
| Network | NSGs, Azure Firewall, Private Link, VPN | Phase 3 (networking) |
| Data & platform | Storage/database security, Key Vault | Phase 2 & 3 |
| Compute & AI workload | VM hardening, container security, Defender for AI, Foundry guardrails | Phase 4 |
| Visibility & response | Defender for Cloud, Sentinel, Security Copilot | Phase 5 |
⚠️ Exam Trap: "Defense in depth" questions often test whether you'll recommend removing an existing layer because a newer control seems to cover the same ground (for example, "now that Defender for Servers is enabled, do we still need NSGs?"). The answer is almost always yes — layers are additive, not a swap.
Reflection Question: Why does adding Defender for AI Service to a Foundry deployment not remove the need for Conditional Access policies on the agent identities calling it?
