Defender for Cloud — posture as a score
Microsoft Defender for Cloud assesses supported resources against security recommendations. Its secure score summarizes selected checks and helps you find work to do. A higher percentage does not prove that a resource is safe or that an attack is impossible. Open each recommendation, inspect the affected resources, and ask what an attacker could actually reach. Part I's workflow and identity review still matters because a score does not cover every pipeline permission.
A score can help track selected changes over time, but the recommendation list is more useful than a percentage alone. When a recommendation does not apply, an authorized person can record an exemption with a reason and scope. Exemptions change how findings and scores appear; they do not change the resource. A Mitigated exemption can raise the score, while a Waiver excludes the resource from the calculation. Review exemptions separately from fixes. Foundational CSPM is free; advanced posture and workload protection plans can cost extra and must be checked before enabling.1
The regulatory compliance view maps assessed resources to selected framework controls. It can help locate failing checks and collect some evidence, but a green control is not an audit certificate. Confirm the framework scope, what resources were assessed, and the evidence an auditor still requires. Defender workload plans add capabilities for selected resource types; review current plan coverage and pricing before turning them on.
Play it through
Three minutes, two drags. In a fictional example, fix one finding and exempt another. The displayed percentages illustrate how a score can change; the remaining risk must be judged from the actual resource.
Supply chain — watching what you build on
The application's supply chain includes packages, base images, and build tools the team did not write. A vulnerable dependency is one possible attack path. Scanners help detect known problems within their supported scope; no scanner covers every package, image, and behavior. Check which protections are enabled for the actual repository and plan:
- Dependabot
- Checks supported dependency files against known advisories. An alert names an affected version; if security updates are enabled and a fix can be made, Dependabot may propose a pull request. Run CI and review that change before merging it.
- Code scanning
- Static analysis checks supported source languages for patterns such as unsafe data reaching a query. CodeQL must be configured for the repository and actually run; check the Code scanning page for a completed analysis before relying on its results.
- Secret scanning
- Searches supported repositories for recognized credential patterns. Push protection can block a supported value before a push reaches GitHub; it does not erase a local commit, catch every format, or prevent an authorized bypass. Rotate a value that was already exposed.
- Image scanning
- A configured image-scanning service can flag known vulnerabilities in a registry image. Coverage depends on the service, enabled plan, and image. Rebuild with an updated dependency or base image, then rescan and redeploy.
Availability and charges differ: GitHub offers several protections for public repositories, while private-repository features and Defender image assessment can require paid plans. Assign an owner to findings, verify that scans actually run on the files and images you use, and review alerts after changes to the repository or security plan.
These four belong to a taxonomy interviewers name, worth holding as a set. Dependabot is SCA — software composition analysis, reading the dependencies you inherited. CodeQL is SAST — static application security testing, reading your source code at rest. Secret scanning and image scanning round out what can be checked without running anything. The category none of them covers is DAST — dynamic application security testing, which probes the running application for flaws that surface only at runtime, and which is not a GitHub switch but a stage you add: a tool such as OWASP ZAP fired at a deployed test environment. That split — scan the code at rest, then probe it running — is the shape you rebuild in Class Thirty-Nine on Production Pipelines with GitHub Actions, where the security checks are stages that fail the build exactly as a failing test does. The idea under all of it is shift-left: run every check as early as it can run, because a finding on a pull request costs a review comment and the same finding in production costs an incident.
Defence in depth, and the line Microsoft won't cross
Everything so far has hardened one layer at a time: a vault for secrets, a score for posture, scanners for the supply chain. Defence in depth means using several controls so one missed problem does not leave the application unprotected. First find out who operates each layer. In Azure, Microsoft operates the physical datacentre, host, and network. What you configure depends on whether you use a virtual machine, a managed platform, or a finished software service.
The line's position is not fixed; it slides with the service model from Class Four. On a virtual machine you patch the guest OS; on App Service the platform patches the OS and you own only the app and its configuration; on a SaaS mailbox you own almost nothing but the data and who may read it. The most expensive misreading in this work is assuming the provider covers a layer they explicitly do not — because when a storage account leaks, Azure did its job. The disk was encrypted, the datacentre locked; the public-access toggle you left on sat above the line. The provider secures the building; you lock the room.
| Layer | IaaS · VM | PaaS · App Service | SaaS |
|---|---|---|---|
| Physical host & datacentre | Microsoft | Microsoft | Microsoft |
| Guest OS & patching | You | Microsoft | Microsoft |
| Runtime & middleware | You | Microsoft | Microsoft |
| Network configuration | You | You (limited) | Microsoft |
| Identity & access | You | You | You |
| Data & its exposure | You | You | You |
Identity and data stay yours at every tier — which is why this class spends most of its budget there — but the middle layers move, and the network is the one worth walking in full, because it is where the earlier classes stack into a wall. Read it from the internet inward. DDoS Protection absorbs volumetric floods at the edge before they reach anything you pay for. A Web Application Firewall (WAF), riding on Front Door or Application Gateway, inspects HTTP for the injection and scripting patterns CodeQL catches in your code — but at runtime, for traffic you did not write. Azure Firewall governs what your subnets may reach outbound, the exfiltration path most designs forget to close. Network security groups are the per-subnet, per-NIC allow-lists. And private endpoints (Class Fourteen) take the PaaS services off the public internet entirely, so the storefront reaches its database over a private address that never leaves the VNet. No one of these is security; stacked, they are.
The provider secures the building. You lock the rooms.
Cloud security posture — Zero Trust and the CNAPP
The secure score in §1 answered a checklist question one finding at a time. The frontier past that list has a name the industry has settled on and interviewers now expect — Zero Trust — and it is three sentences, not a product. Verify explicitly: every request authenticates and is authorised on its own merits — identity, device health, location checked at the door each time — rather than trusted because the caller is already inside the network. Use least privilege: Part I's pipeline audit and privileged-identity work, in space and in time, is this principle already built. Assume breach: design as though an attacker is already inside, which is precisely the premise under the defence in depth of §3 — segment the network, bound the blast radius, log everything, so the breach you assume is one you can see. The old model trusted a perimeter and let anything inside roam; Zero Trust deletes the idea of "inside."
The tools that operationalise this split into two jobs worth naming precisely, because the acronyms are interview currency — and Azure's answer folds them into one product you have already been driving.
- CSPM
- Cloud security posture management — the misconfiguration half. Is this storage account public, is MFA on, is encryption set? Defender's free posture tier and its secure score are CSPM; you met it in §1 and owe it nothing more here.
- CWPP
- Cloud workload protection platform — the runtime half. Is this VM running something that looks like a miner, is this container calling a known-bad address? Defender's paid per-workload plans (also §1) are CWPP: detection on the living workload, not the config at rest.
- CNAPP
- Cloud-native application protection platform — the two folded into one pane, so a posture finding and a runtime alert can be reasoned about together. Defender for Cloud is Azure's CNAPP; a job posting that lists the word is describing what this whole class taught, under one label.
The reason folding them together earns its keep is the feature that changes how you triage: attack-path analysis, built on Defender's cloud security graph. A flat list treats "VM has a public IP", "VM's identity can read the storage account", and "storage account holds customer data" as three separate medium findings you may never reach. The graph connects them into one sentence — an internet-exposed VM can reach the crown-jewels storage through its own identity — and ranks that path above a hundred isolated items, because it is the one an attacker actually walks. Posture stops being a backlog to burn down and becomes a set of chains to break at their cheapest link: drop the public IP and the whole path is severed.
An attacker walks paths, not lists.
Two operational choices sit under all this. Workload scanning comes agent-based — a Defender agent runs on the machine, giving deep, live runtime signal at the cost of something to deploy, patch, and account for on every VM — or agentless, where Defender snapshots the disk out of band and scans the copy, seeing installed packages and secrets with zero footprint on the workload but without the live process view. Mature estates run both: agentless for universal coverage, agents where the running picture earns its keep. And none of it is Azure-only — Defender connects AWS accounts and GCP projects and renders one secure score across all three, which is the actual job, since almost no real estate is single-cloud. The frontier, in one line: not "we scan our resources" but "we can see the paths an attacker would walk across every cloud we run, and we break them in priority order."
DevSecOps, past the scanners — policy as code and provenance
The §2 scanners find problems; policy-as-code stops the problem from ever deploying, by writing the rule as a machine-checked gate instead of a wiki page nobody reads. Two gates, at two layers, worth telling apart. Azure Policy (Class 8) sits at the ARM control plane: a policy that denies any storage account with public access, or audits any resource missing a required tag, is evaluated when the resource is created or changed, and the non-compliant deploy is refused by Azure itself before the resource exists. Gatekeeper — the Kubernetes admission controller built on OPA (Open Policy Agent) — sits one layer in, at the AKS API server: when a pod is applied, Gatekeeper checks it against policy and rejects it at kubectl apply if it runs privileged, pulls from an untrusted registry, or omits resource limits. Azure Policy governs the Azure resource; Gatekeeper governs what runs inside the cluster — and Azure Policy for AKS is Microsoft's managed Gatekeeper, so the two meet. The shared idea: the rule is code, versioned and reviewed like any other grant of power, and enforcement is automatic rather than a reviewer's memory.
The rule is code, or the rule is a rumour.
The same shift-left instinct reaches back into the Bicep and Terraform of Classes 20 and 21. IaC security scanning — Checkov, tfsec, or Microsoft's PSRule — reads the template before apply and fails the pipeline on the public storage account, the unencrypted disk, the NSG open to the world, catching in a pull request what Defender would otherwise surface in production a week later. It is a stage you add to the Class 39 pipeline exactly like a test: the plan is scanned, the build goes red on a high finding, the misconfiguration never reaches an environment. Policy-as-code and IaC scanning are the same lesson at two moments — one refuses the bad deploy at the platform, the other at the pipeline — and defence in depth wants both.
The four scanners watched what you depend on; the supply chain's other half is proving what you ship. Three nouns carry it, and they belong together as a set.
- SBOM
- Software bill of materials — a manifest of every component inside an artifact, so that when the next Log4j lands you answer "are we affected?" with a query against the SBOM instead of a week of archaeology.
- Signed artifacts & provenance
- The build signs its output (cosign, Notary) and records how it was built, so a consumer can verify the image came from your pipeline and not a substitute slipped in transit. SLSA is the industry ladder of maturity for exactly this provenance — a level you can be measured against.
- Dependency pinning
- Lockfiles, and pinning by digest rather than a mutable tag, close the gap where latest silently becomes something else overnight. What you tested is what you ship, because the version cannot move underneath you.
Together they answer the question the §2 scanners cannot: not "is what I depend on known-bad" but "is what is running actually what I built." Two closing moves finish the discipline. First, rotation as machinery, not memory: Key Vault carries rotation policies and fires Event Grid events on expiry, so a certificate or key rotates on a schedule and its dependents are notified rather than surprised — and at the top end, secret scanning can auto-revoke a leaked credential with the provider the instant it is detected, so detection response stops being a human paging a human. Second, the part no tool ships: DevSecOps is a culture before it is a pipeline. Shift-left is a team practice, not a product — security folded into design review, threat modelling done while the feature is still a diagram and cheap to change, a security champion embedded in the team rather than a gate bolted on at the end, and the blameless-postmortem discipline that makes people report the near-miss instead of hiding it. The tools in this class raise the floor; the culture decides whether anyone treats the red build as a real failure or a switch to override. Security as everyone's job is not a poster — it is who gets asked, and when.
The posture story you tell in interviews
"Tell me about security in your last environment" is a question most candidates answer with a product list, which is exactly as convincing as answering "are you healthy?" with the contents of a medicine cabinet. The strong answer is a posture story with a shape: where the secrets live (a vault, RBAC'd, referenced by managed identity — nothing stored in code, settings, or pipelines); how you know your standing (a score, its trend, and the exemptions you argued); what watches the code and its supply chain (four scanners, each with an owner); and what bounds the blast radius (a least-privilege audit, run on a calendar). Four sentences, each backed by something you can screen-share — and the senior version adds two more that separate a candidate from the pack: that you triage attack paths rather than finding lists (§4), and enforce the rules as code at the platform rather than by review after the fact (§5).
End the story the way honest security people do: with the residual risk, named. "The workflow files are still the most powerful text in the company, which is why they get the strictest review" — or whatever your estate's true soft spot is. Naming your own weakness, unprompted, is the highest-credibility move available in a security conversation, because it proves the posture is something you maintain rather than something you recite.3 Auditors, interviewers, and incident retrospectives all reward the same voice — Class Twenty-Three's auditor conversation taught it, and it transfers everywhere.
The 11pm secret, finally laid to rest
Class Nine told the story in passing: a Campux engineer, at 11pm, committed a storage key to the repository, and the "fix" was deleting the line — which, as Class Seventeen later made painfully clear, removes nothing from history. The key has been valid ever since. Nobody exploited it; nobody could prove nobody had. This class runs the full treatment, in the right order. Rotate first: the exposed key is regenerated, and the window of exposure is documented — commit date to rotation date, twenty-two months, a number that makes the room quiet. Then prevent recurrence: secret scanning finds two more forgotten strings in history (both rotated); push protection turns on, and the next 11pm mistake bounces at push time instead of entering history.
Then remove the reason it happened: a Key Vault per application, secrets loaded by reference through each app's managed identity, and the storage key that started it all is no longer in anything — the storefront's identity fetches it from the vault, and rotation is a vault operation the app never notices. Dependabot, code scanning, and image scanning switch on the same week, each finding routed to an owner per Class Thirty's rule. Defender's secure score reads 43 percent the day it is enabled — which is not a crisis but a baseline, and Situation 01 is the meeting where Campux decides what to do about it. The engineer who committed the key, for the record, still works there; the postmortem blamed the missing guardrails, not the tired human. That sentence is also part of the posture.
The official page, and a CAMPUX overview
What is Microsoft Defender for Cloud?
learn.microsoft.com/azure/defender-for-cloud/defender-for-cloud-introduction
Check which scans run, then test one dependency alert
Use a new, empty practice repository that you own. Do not add a vulnerable dependency to a shared or deployed project. This exercise adds a manifest for detection only; do not install or run the old package.
In the repository: Settings → Advanced Security. Enable Dependabot alerts and Dependabot security updates.
What to notice: two switches — one to be told about vulnerable dependencies, one to let the robot open the fix PR itself. Free for public repositories, and among the highest-value clicks in this bootcamp.Inspect Secret scanning, Push protection, and Code scanning on the same security settings page. If available, enable them and choose CodeQL's Default setup.
What to notice: push protection checks supported secrets when you push; it cannot erase a secret already in local history and may allow a bypass. This empty repository has no supported application source for CodeQL to analyze. An enabled switch alone is not evidence of a completed scan.In GitHub's file editor, add requirements.txt to the practice repository's default branch with this single line:
requests==2.19.0
What to notice: a published GitHub advisory affects this version. The manifest lets you observe dependency detection without installing the package.Open Security → Dependabot alerts and look for the requests finding. Processing time varies. If no alert arrives, confirm alerts are enabled, that the file is on the default branch, and that GitHub recognizes the manifest.
Finish: read the affected version and recommended fix. A security-update pull request may appear if enabled and supported; do not assume one will. Remove the practice manifest when finished and verify that the alert resolves. Review current plan terms before enabling paid features on a private repository.
Zoom out: security is a property of the whole pipeline, not a gate at the end
You can turn on scanning and push protection. Now reason about what security does as a system, because a control bolted on at the end is a control teams learn to route around.
A late security review blocks a ready release, so teams learn to route around it, so security becomes the enemy of shipping and gets skipped. What moves the check early enough to help rather than block?
Every deploy depends on the weakest link — a leaked key, an unpatched base image, an over-broad role; defence in depth assumes each layer will sometimes fail.
The posture's ceiling is its worst-held secret and its most-forgotten patch; a high secure score with one public container is still a breach.
Push protection that blocks the 3am secret also blocks the emergency paste; the friction is the point, and the design is deciding where it is worth it.
A blameless-postmortem culture scales trust; a blame culture teaches people to hide incidents, which is how small ones quietly become large.
The engineer who ships is asked "is it secure?" The engineer who gets promoted is asked "and what happens the day a layer fails?" — and built the next layer to catch it.
Treating the scanner like a failing test
A dependency scanner flags a known-vulnerable library before the code ever ships. Because security moved left into the pipeline, the fix is a pull request on a Tuesday, not an incident in production. You treat the scanner's output like a failing test — because that is exactly what it is — and the vulnerability never reaches a customer.
Examination
Four drills, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored; this is between you and the page.
Flag known-bad dependencies, block secrets at the door, scan image layers. The two rejects mark the scanners' honest edges. All three tools work from databases of known problems — published CVEs, recognised credential shapes — so a zero-day in a dependency or an unusual secret format walks past them; "no alerts" means "nothing known found", never "nothing wrong". And detection is not remediation: a secret already in history is compromised the moment it landed, and the only fix is rotation — the scanners' job is making sure there is no next one, which is exactly the order the case file ran. Know what your tools cannot do; it is the half of the posture story that makes the other half credible.
C — identity and data never move, whatever the tier. Table 1 draws the line service model by service model: on App Service, Microsoft patches the guest OS and the runtime, and network configuration is only partly yours; identity and access, and the data and its exposure, sit on your side of the line at every tier — VM, PaaS, or SaaS. A, B, and D are exactly the layers PaaS takes off your plate, which is the entire appeal of PaaS over IaaS. The costly misreading this drill guards against: assuming a "managed" platform covers a layer it never claimed. A managed platform moves the line; it never erases it, and the two rows that never move are the two that matter most.
B — the misconfiguration half and the runtime half, in one pane. CSPM asks "is this configured well" — Defender's free posture tier and its secure score, unchanged since §1. CWPP asks "is this workload actually doing something malicious right now" — the paid per-workload plans, watching the living process rather than the config at rest. CNAPP is the fold: one pane where a posture finding and a runtime alert can be reasoned about together, and where the cloud security graph can connect them into an attack path. A, C, and D invent mechanics the acronym never claimed. Say it back this way in an interview and the acronym stops being jargon and starts being the thing you already built.
# review: AKS deployment gate
1. Azure Policy denies any storage account created with
public network access enabled.
2. Gatekeeper policies are written once at rollout and
left alone, since OPA enforces them automatically
from then on.
3. Gatekeeper rejects a pod at kubectl apply if it runs
privileged or omits resource limits.
4. The CI pipeline scans the Terraform plan with tfsec
before apply, failing the build on a high finding.
Line two — policy-as-code is not policy-set-once. "OPA enforces it automatically" is true and beside the point: automatic enforcement only guarantees the rule still runs, not that it is still the right rule. A policy written for last year's threat model, an exception nobody revisited, a typo that quietly widened what "privileged" means — none of these are caught by the engine that enforces them, only by a human reviewing the rule the way §5 asks you to review any other grant of power. The distractors are each wrong the other way: Azure Policy denying at creation is exactly what the ARM control plane does (A); Gatekeeper explicitly checks privilege, registry, and resource limits together (C); and IaC scanning belongs precisely in the pipeline, as a stage that fails the build like a test (D). Write the rule as code, then treat the code like code — reviewed, versioned, occasionally wrong.
First, explain the number. Forty-three percent is this scenario's starting value, not a normal score for every new subscription. It does not mean the estate is exactly 57 percent insecure. Open the recommendation details and confirm which resources are affected.
Then identify actual risk. Review privileged roles, public exposure, and sensitive data first, alongside the recommendation's score impact. A publicly reachable resource holding customer data may outrank a higher-point finding. Assign each confirmed issue an owner, a fix, and a way to verify that the setting changed.
Finally, report the trend with context. Separate fixes from documented exemptions and deferred work. Use a target based on risk and available capacity rather than promising a particular point gain. Recheck the resources and exemptions after Defender reassesses them; score changes can lag behind the work.
Answer the literal question honestly, not defensively. "Ninety-two percent means the estate matches a checklist of known-good configuration well; it does not mean 'secure' in the way the question implies." A single public endpoint above the shared-responsibility line, one exemption argued for convenience rather than necessity, or one path an attacker could actually walk — from an exposed VM, through an over-permissioned identity, to a storage account holding customer data — can all sit underneath a green dashboard, because the score aggregates checklist items, not the exploitable route between them.
Then show you know the frontier past the checklist. The move that separates a senior answer from a recitation is naming attack-path analysis: triaging the connected chain the cloud security graph draws, rather than trusting the flat eight percent still outstanding, is what actually tells you whether the headline number reflects reality. And name the exemption risk specifically — a high score built on liberal use of "does not apply" is a number, not a posture, and the two look identical on a dashboard.
Close with the residual risk, unprompted. "And the sentence I would add without being asked is the one that separates a real answer from a recitation — here is the thing that still worries me, and here is what bounds it." That is the answer that gets the nod: a number, its limits named before anyone else names them, and the risk you are still watching.
Five things worth carrying out of this class
- Defender's secure score makes posture legible: a baseline, a prioritised backlog, and exemptions-with-reasons. The score is the compass, the trend is the deliverable — first points come from identity and public exposure.
- Dependency, code, secret, and image scanners cover different risks. Verify each one is available, enabled, and actually running. Review the plan before enabling paid features. A secret that was exposed must be rotated.
- Defence in depth stacks the layers you own, because the shared-responsibility line moves with the service model but identity and data never cross it — a high score with one public endpoint above the line is still a breach.
- Zero Trust is three sentences, not a product: verify explicitly, use least privilege, assume breach. CNAPP folds CSPM and CWPP together so attack-path analysis can rank one exploitable chain above a hundred isolated findings.
- Policy-as-code (Azure Policy, Gatekeeper) and provenance (SBOM, signed artifacts, pinning) prove what runs is what you built — but the rule is still code someone must review, and the posture story ends with your residual risk, named out loud.
- Defender for Cloud's packaging shifts more than most Azure products — the free posture tier, the per-workload paid plans, and the names of both have all changed before and will again. As this class ships, the paid plans carry per-workload names — Defender for Servers, Defender for Containers, Defender for Storage, and their siblings — which are worth holding as interview nouns even if the labels have drifted by the time you say them. Treat the architecture as stable (free continuous posture assessment plus opt-in paid threat protection per workload type) and check current plan names and prices before quoting them in a meeting. The secure score's exact arithmetic also evolves; the direction — weighted, argue-able, trend-tracked — is the durable part. ↩
- Two honest limits on the compliance picture. The shared-responsibility table in §3 is a summary, not a contract — the authoritative split lives in Microsoft's shared-responsibility documentation, shifts by service, and moves over time, so read it for the service you actually run rather than trusting any tidy grid, this one included. And Defender's regulatory-compliance dashboard shows control coverage, not legal compliance: a screen full of green means you are ready to be audited against a framework, not that you have passed an audit, which still wants scope, evidence, and interviews the dashboard cannot produce. ↩
- This class covers the security work a platform engineer owns day to day; it is not a security curriculum. Threat modelling, penetration testing, SIEM operations (Microsoft Sentinel — which runs on the Class 28 workspace and speaks Class 29's KQL), and incident forensics are their own disciplines with their own careers. The honest boundary to know and say: you are building the estate that makes a security team's job possible, not replacing the team. ↩
Read a Defender secure score, and scan a dependency and a container image before they ship.
Play the lesson above to stamp this class.