Zero Trust, defence in depth and Defender for Cloud

Zero Trust deletes one sentence

The sentence is "it came from inside the network, so it must be fine". Zero Trust replaces the assumption that a location implies trust with three working rules. Verify explicitly, using every signal available, wherever the request originated. Grant the least privilege that does the job, and only for as long as it is needed. And assume breach, designing as though some part of the environment is already compromised, so that segmentation, monitoring and encryption limit what a foothold is actually worth.

Two misreadings are offered as answers. The zero refers to implicit trust, not to access — people are granted access continually, just explicitly verified and scoped rather than assumed. And it is not a product: nothing switches it on, because it is a model that shapes how identity, devices, networks, applications and data are configured across many services. When a scenario contains a phrase that gives trust away for free, that phrase is what Zero Trust removes.

Defence in depth: layers that are assumed to fail

Defence in depth arranges controls in rings around the thing you actually care about, and the design question at each ring is what happens after the ring outside it has already failed. That is why the strongest single control is not a substitute for the arrangement: each layer buys time and containment for the ones inside it, and the model takes for granted that one of them will one day be the layer that failed.

It is not redundancy, and that is the distractor. Redundant components do the same job so that one can take over; these layers do different jobs at different levels and are not standby copies of each other. Nor is it a compliance-driven habit of counting controls — frameworks ask for layering because layering demonstrably contains breaches, which is cause rather than effect.

Classify a control by its mechanism, not by what sits behind it

The hardest question on this lesson gives you a control and asks which layer it belongs to, with a plausible wrong answer drawn from whatever the control happens to protect. A network security group blocking traffic between the application subnet and the database subnet is a NETWORK control, because it matches addresses, ports and protocols and knows nothing about which user is behind a packet — even though a database sits behind it.

Applied consistently: sign-in requirements and role assignments are identity and access; volumetric protection at the edge is perimeter; patching and endpoint protection on hosts are compute; input validation is application; encryption and control of the keys are data. The same database can be defended at four different layers at once, and in a healthy design it is.

Defender for Cloud: posture, and protection

Microsoft Defender for Cloud does two jobs that are easy to conflate. Posture management continuously assesses how resources are configured against security recommendations and expresses the result as a secure score, with the recommendations ranked so there is an obvious next thing to fix. Workload protection is the other half: detecting threats against resources that are actually running, rather than commenting on how they are set up.

Its hybrid and multicloud reach is the detail worth remembering, because it is what makes it the answer to a scenario spanning several clouds and a rack of servers in an office — accounts in another public cloud can be onboarded, and Azure Arc is what lets a server outside Azure be assessed alongside a virtual machine in a subscription. Keep the neighbours apart: Azure Policy audits and enforces rules you wrote, Azure Monitor collects telemetry so you can see what is happening, and Azure Advisor spans cost, reliability, performance, security and operational excellence — taking its security recommendations from Defender for Cloud in the first place.