The four previous lessons have secured specific pieces: identities, permissions, secrets and perimeter. They all share one uncomfortable limitation: you had to know the problem existed in order to go and fix it. Nobody has yet checked whether vm-motor-disponibilidad-dev was left with port 22 open to the internet during the module 2 tests, whether some storage account still accepts unencrypted traffic, or whether somebody is trying to get into db-reservas from an IP in a country where Contoso Airlines does not have a single employee. That is what Microsoft Defender for Cloud does: it looks at the whole platform continuously, compares it against a catalog of best practices, says what is missing ranked by impact, and warns you when something behaves anomalously. It is the jump from point-in-time control to continuous security posture.

Important cost warning: the free assessment and recommendations tier costs nothing, but the Defender plans do, and substantially: on the order of €14 per server per month, €13 per million transactions in Storage, €13 per SQL instance per month, around €2 per container vCore and around €0.02 per 10,000 Key Vault operations. A mid-sized subscription with every plan turned on at once comfortably exceeds €1,000 a month. Turn them on per subscription and per plan, starting with the resources that hold sensitive data, and always use the cost estimate the portal itself shows before confirming.

1. CSPM and CWPP: the two halves of the problem
2. The secure score and how to actually use it
3. The free tier versus the paid plans
4. Turning Defender on in the production subscription
5. Recommendations: quick fix, exempt and deny
6. Contoso's first ten recommendations
7. Security alerts and investigation
8. Attack paths and the step up to Microsoft Sentinel
9. Regulatory compliance and the PCI DSS case
10. Other clouds and on-premises resources
11. Workflow automation
12. Common Mistakes and Tips
13. Exercises
14. Conclusion

Defender for Cloud is really two products under one dashboard, and confusing them leads to turning on what you do not need:

The practical distinction: foundational CSPM is free and you should turn it on today across every subscription, no argument, because it costs nothing and it uncovers half the real problems. There is also a paid Defender CSPM, which adds attack path analysis, queries over the cloud security graph and agentless machine scanning. CWPP — the per-resource plans — is turned on selectively and with judgement, because that is what gets billed.

The secure score sums up your posture as a percentage. It is calculated like this:

• Recommendations are grouped into security controls (for example, "Enable MFA", "Remediate vulnerabilities", "Restrict network access").
• Each control is worth a number of points (the most critical ones up to 10).
• A control only scores when every one of its resources complies, with partial credit proportional to the compliant resources.
• The final score is the total obtained over the maximum possible.

Contoso starts at 38%. And here comes the advice that saves the most time: the goal is not 100%. Chasing it leads to spending weeks on recommendations that are irrelevant to your context, or to enabling wildly expensive paid plans purely to move the scoreboard. The score is good for three things:

1. Prioritizing: tackle the controls with the most available points and the fewest affected resources first, which is where the effort pays off most.
2. Measuring the trend: a sustained month-on-month rise matters far more than the absolute figure.
3. Communicating: it is the metric management understands, and the one that justifies the security budget.

Contoso's practical rule: the quarterly target is 70%, with every high-severity control either resolved or formally exempted with a written justification.

An explicit warning: turning on all eight plans across Contoso's two subscriptions comfortably exceeds €1,000 a month, more than a good part of the infrastructure they protect costs. Plans are turned on per subscription and per plan, and that is the mechanism to use:

• In Contoso Airlines - Producción: SQL (it holds passengers' personal data and is the critical asset), Storage (boarding passes) and Key Vault (access to secrets). The Servers plan is turned on only for vmss-api-disponibilidad-pro, not everywhere.
• In Contoso Airlines - Desarrollo: the free tier only. The data is fictitious and the risk is low.

The 30-day free trial is useful for seeing the real volume of alerts before committing, but you have to put the end date in the calendar: if nobody turns it off, it starts billing without warning.

Step 3 is not optional in practice: without sending the data to the workspace in rg-contoso-seguridad-pro, alerts live only in the Defender dashboard, cannot be correlated with the Key Vault logs or with 04-04's WAF logs, and there is no history beyond the default retention. It is the same decision that was taken with the vault's audit trail in 04-03, and module 7 exploits it fully with KQL.

For servers it is also worth turning on automatic provisioning of the extensions, so that every new VM gets the agents with no manual intervention. It is a good example of why Defender and Azure Policy are inseparable: that provisioning is implemented, underneath, with DeployIfNotExists policies like the ones you will see in 04-06.

Every recommendation comes with a severity, the affected resources, the impact on the score and remediation steps. There are three ways to handle one:

On exemptions, two hygiene rules: always with a written justification and an expiry (six months, say), and reviewed when they expire. A permanent exemption with no documented reason is exactly the same as ignoring the recommendation, only it looks better on the dashboard. And deny is the mechanism that turns a recommendation into a rule: it is done with Azure Policy, which is the next lesson.

This is the real list Defender produces in the first week, with what the team decides in each case:

The pattern is worth noticing: out of ten recommendations, two were already met thanks to the work in the previous lessons, one is fixed with a click, one is better solved with a policy than case by case, and two are exempted with a justification and an expiry. That mix is what real security work looks like; a dashboard at 100% is not.

Alerts come out of the paid plans and are generated three ways: behavioral analysis (something deviates from the learned baseline), threat intelligence (an IP or a hash appears in known feeds) and each service's specific detections. Their severities are High, Medium, Low and Informational.

A realistic example at Contoso:

The investigation, step by step:

1. Context: it is 03:17, outside working hours. The identity is the application's, which should never be using sqlcmd: the application connects with its SDK. That is already two strong signals.
2. Correlate: search Log Analytics to see whether that IP appears in the WAF logs, in the Entra ID sign-ins or in the kv-contoso-pro audit trail in the preceding hours.
3. Determine the scope: SELECT * FROM dbo.Reservas with no filter points to mass exfiltration, not to an operational query. You look at the volume of data returned in the SQL audit (03-02).
4. Contain: if it is confirmed, revoke the identity's tokens, block the IP in the WAF and in the NSG, and isolate the compromised resource.
5. Eradicate and recover: work out how the access was obtained — a stolen token? an old connection string that survived 04-02? — close it, and restore from a clean copy if anything was modified.
6. Document: timeline, the scope of the data affected and, if passengers' personal data is involved, notification to the regulator within the GDPR's legal deadline.

In this specific case, the most likely cause is the most boring one: an old connection string left in a script that somebody ran from outside. The investigation ending in something trivial does not mean the alert was unnecessary; it means the process works.

An isolated alert says little. Defender groups related alerts into incidents and shows the attack path: chains of configurations that, combined, allow someone to reach sensitive data. For example: "a VM exposed to the internet → with an unpatched critical vulnerability → with a managed identity holding a data contributor role over sttarjetascontosopro". None of those three elements is alarming on its own; together they are a complete exfiltration path. That analysis belongs to the paid Defender CSPM and is probably what most justifies its price.

Microsoft Sentinel is the next step up: Azure's native SIEM and SOAR. While Defender for Cloud protects Azure resources, Sentinel correlates every source — Defender, Entra ID, Microsoft 365, firewalls, on-premises systems, third-party applications — applies analytics rules and automates the response with playbooks. It is billed per GB ingested, so deciding which logs to send is both a security and an economic decision. Contoso has it on its roadmap for when there is a dedicated security team: without somebody to work the incidents, a SIEM is an expense that generates alerts nobody looks at.

The regulatory compliance dashboard maps recommendations onto the controls of recognized standards:

Contoso processes card payments, so PCI DSS applies to it, and that has concrete consequences you have already been building without naming them: encryption in transit and at rest, segmentation of the network that touches cardholder data, identity-based access control with least privilege, auditing of all access (hence the Key Vault and SQL logs in Log Analytics), vulnerability management and log retention of at least a year.

Two serious warnings. First: the dashboard shows compliance with the technical controls Azure can evaluate automatically; a standard like PCI DSS also includes process, training, contractual and physical security controls that no tool measures. 100% on the dashboard is not a certification. Second, and this is why the warning is repeated: the compliance design must be validated by a qualified auditor or by your organization's compliance team before you consider it sound. The tool helps; it does not certify.

Defender for Cloud is not limited to Azure. It can connect AWS accounts and Google Cloud projects through a native agentless connector, assessing their configuration against the same criteria and showing everything in a single multicloud posture dashboard. And on-premises servers — including the Barcelona office AD and the legacy billing system — are brought in with Azure Arc, which projects them as Azure resources and applies plans, policies and recommendations to them. For Contoso it is the way to have a single security view without migrating the whole infrastructure first, which ties directly into the migration strategy in 09-04.

An alert that lands in an inbox nobody reads is worth nothing. Workflow automation triggers a Logic App (06-04) when an alert or a recommendation matching a filter is generated:

Contoso uses it for three things: notifying the on-call channel in Teams on High severity, automatically opening a ticket with the alert's context, and running simple, reversible containments, such as isolating by NSG a VM with a cryptocurrency mining alert. Aggressive automation is best reserved for very high confidence cases: a badly calibrated automatic containment is, in itself, a self-inflicted denial of service.

• Turning on every plan "to be safe". It is the fast route to a four-figure bill. One plan per resource type and per subscription, starting with the sensitive data.
• Letting the 30-day trial expire without noticing. It starts billing silently. Put it in the calendar the same day you turn it on.
• Chasing a 100% score. Prioritize high severity and real impact; the rest is scoreboard.
• Exempting with no justification and no expiry. That is ignoring the problem with better presentation. Justify it in writing and review it when it expires.
• Applying quick fix in production without thinking. Some fixes change networking or access and can cut off the service. Test them in development.
• Confusing the compliance dashboard with a certification. It only measures technical controls that can be automated.
• Not connecting Defender to Log Analytics. Without that there is no correlation, no history and no queries.
• Tip: review the score and the new recommendations in a fixed 30-minute monthly meeting. Security posture degrades on its own if nobody looks at it.
• Tip: always turn on the free tier in every subscription, including development and test ones. It costs nothing and that is where the slips show up.

Contoso Miles (centro-coste=CC-2077) has €400/month for security. Its subscription contains: 6 virtual machines, 1 SQL database with personal data, 2 storage accounts with 30 million transactions a month, 1 Key Vault and 1 public App Service.

1. Estimate the cost of turning on every plan and compare it with the budget.
2. Propose a justified selection that fits in €400 and state what is left uncovered.
3. What would you turn on for free in any case, and why?

Defender produces four recommendations about Contoso Bookings: (a) management ports open on two development VMs; (b) secure transfer disabled on a storage account; (c) DDoS Standard not enabled; (d) diagnostic logs disabled on 14 resources.

1. For each one, state whether it should be fixed, exempted or denied, and with what mechanism.
2. Which one would you solve with Azure Policy rather than one by one, and why?
3. What information would you write into the exemption you propose?

A High severity alert arrives: "A mass blob extraction operation was detected" on sttarjetascontosopro, with the identity app-contoso-reservas-pro as the source, 40,000 blobs downloaded in 12 minutes, from an IP belonging to a different cloud provider, at 04:30.

1. List the first three checks you would make and what you would look for in each.
2. What containment measures would you apply, in what order, and with what risk?
3. Knowing what was done in 04-02 and 04-03, what root cause hypotheses would you work with?

Solution 1:

1. Servers: 6 × 14 = €84. SQL: €13. Storage: 30 million transactions ≈ €390. Key Vault: a few euros. App Service: €13. Approximate total: €500–510/month, 25% over budget.
2. Priority by sensitive data and exposure: SQL (€13), App Service (€13, it is the public one), Key Vault (about €2) and Servers (€84) come to about €112. With the rest you can cover Storage partially if the accounts are split and only the one holding personal data is protected; if the 30 million transactions belong to the sensitive account, you have to choose between covering it (€390, total ~€500, over budget) or leaving it with free CSPM. What is left uncovered is malware and exfiltration detection in storage, a risk that must be documented and formally accepted.
3. Foundational free CSPM across every subscription, including the development ones, plus sending logs to Log Analytics. It costs zero, it detects misconfigurations, and development is precisely where the open ports and forgotten public access show up.

Solution 2:

1. (a) Fix: close the NSGs and use Bastion; in development it is tempting to exempt, but port 22 open to the internet is one of the most exploited vectors there is. (b) Immediate quick fix: it is one click, it breaks nothing and it is a PCI DSS requirement. (c) Exempt, documented with an annual expiry, referring to the cost decision from 04-04. (d) Fix with Azure Policy, not manually.
2. (d). Fourteen resources today, and twenty tomorrow: a DeployIfNotExists policy configures them and, above all, also configures the future ones, which manual remediation never achieves. It is exactly the use case for 04-06.
3. In the exemption for (c): the affected resource or scope, the category "risk accepted", the justification (traffic comes in through fd-contoso-global, which already absorbs volumetric attacks at the edge; the cost of Network Protection is ~€32,000/year against the estimated residual risk), who approves it (the security lead and the CFO), an expiry date twelve months out and the condition for an early review (publishing a critical public IP of its own).

Solution 3:

1. (a) The storage audit trail in Log Analytics: which specific blobs, with what pattern and with what token; you look at whether the token came from the managed identity or from an old SAS or key. (b) The application's normal behavior: 40,000 downloads in 12 minutes at 04:30 does not fit boarding pass issuing, which follows the flight schedule. (c) The origin: an IP belonging to another cloud provider is incompatible with the fact that the application runs in App Service in West Europe.
2. Order: first revoke the access of the identity involved (remove the role assignment on the container) and check that --allow-shared-key-access is still false; then block the IP in the account firewall and in the WAF; then rotate any related credential in kv-contoso-pro. Risk: removing the role leaves the application unable to issue boarding passes, so operations has to be told beforehand; the less disruptive alternative is to restrict the network first and watch whether the access stops.
3. Hypotheses in order of likelihood: (a) an old SAS or account key issued in module 2 that is still valid — instantly checkable, since shared key access was turned off in 04-02; if it really is false, this hypothesis falls; (b) a stolen token from the managed identity, exfiltrated from the application process, which would imply the code or a dependency is compromised; (c) a deployment service principal with excessive permissions whose secret leaked in the repository, which is exactly what Key Vault and managed identities were there to eliminate and which would confirm something was left unmigrated.

Contoso has moved from point-in-time control to continuous posture. You can tell Defender for Cloud's two halves apart: CSPM, which relentlessly assesses whether the configuration is correct and produces recommendations, and CWPP, which detects at runtime and produces alerts. You know that foundational CSPM is free and should be turned on across every subscription today, and that the paid plans are chosen per subscription and per plan because turning them all on comfortably exceeds €1,000 a month. You understand how the secure score is calculated and, more importantly, how it is used: to prioritize by impact, measure the trend and communicate to management, never to chase 100%.

You have turned on the SQL, Storage and Key Vault plans in production, sent everything to Log Analytics in rg-contoso-seguridad-pro and walked through the first ten recommendations, seeing the real pattern of security work: two were already met by the previous lessons, one is solved with a quick fix, another calls for a policy instead of fixing resource by resource, and two end in an exemption with a justification and an expiry. You know how an alert is generated, you have investigated an anomalous access to db-reservas step by step — context, correlation, scope, containment, eradication and documentation, with the GDPR deadline hanging over it — and you know the attack path that chains together configurations that are harmless in isolation, and Microsoft Sentinel as the next step up once there is a team to work the incidents. The lesson closes with regulatory compliance and the PCI DSS that applies to Contoso because it processes payments — and the warning that the dashboard is not a certification — coverage of AWS, Google Cloud and on-premises servers with Azure Arc, and automation with Logic Apps so that no serious alert is left sitting in an unread inbox.

One crack remains, and it has appeared twice in this lesson. Defender detects after the fact: it says there are fourteen resources with no diagnostics, that a VM has an open port or that an account allows public access, but all of that has already been created, has already been exposed and somebody has had to go and fix it. What is missing is preventing it from coming into existence at all. In the module's last lesson, Governance and Compliance with Azure Policy, you will see the essential difference between RBAC — who can do something — and Policy — what can be done, you will write definitions with their effects, build Contoso's set of policies (permitted regions, mandatory tags, no public access, minimum TLS, VM sizes and automatic diagnostics deployment) and fix what already exists with remediation tasks, all on top of a management group hierarchy.