A cloud-native security service that keeps watch over your resources, tells you what is risky, and warns you when something is under attack.

Starting with the word “cloud security”

When a company moves to the cloud, it rents computers, storage, and databases from a provider such as Microsoft Azure. Renting is fast and flexible, but it creates a new question: who keeps all of this safe? A storage account can be created in seconds, and if one setting is wrong, private files may become visible to the whole internet. A virtual machine can be started in a minute, and if nobody installs security updates, an attacker may walk in through an old, known hole.

Cloud security is the practice of protecting these rented resources, the data inside them, and the identities that control them. Doing it by hand across thousands of resources is impossible, so we use tools that check everything automatically.

What Defender for Cloud actually is

Microsoft Defender for Cloud is a Microsoft service, built into the Azure portal, that provides two kinds of help. The first is posture management: continuously examining your resources and settings, comparing them with good security practice, and giving you a prioritized list of fixes. The second is workload protection: watching the things you run, such as servers, containers, databases, and storage, for signs of real attacks, and raising alerts when something suspicious happens.

It is not limited to Azure. It can also look at resources in Amazon Web Services and Google Cloud, at servers in your own data center, and at code repositories and pipelines. This means a company with a mix of environments can see the whole picture in one place.

The cloud provider protects the building. You protect what you put inside it.

Who is responsible for what

A common and dangerous belief is “Microsoft runs the cloud, so Microsoft keeps me safe.” Only half of that is true. Cloud providers follow a shared responsibility model. The provider secures the physical data centers, the power, the network cables, and the core platform software. The customer secures their own data, accounts, settings, and the software they install. Where exactly the line falls depends on the kind of service you use.

Why mistakes are so common

Most cloud breaches do not involve movie-style hackers defeating clever technology. They involve ordinary mistakes: a storage container left open to the public, a database reachable from anywhere, a password left in a file, an administrator account without a second sign-in step. The cloud makes these mistakes easy because creating resources is quick and often done by many people in many teams. This is called configuration drift when settings slowly move away from the safe baseline as people make changes.

The speed problem

Attackers scan the internet all the time, looking for exposed resources. A newly misconfigured service can be found within minutes. A human review once a quarter is far too slow. You need automatic checks that run continuously, which is the core idea behind Defender for Cloud.

flowchart TD
    A["Cloud provider secures data centers and platform"] --> C["Together they make a safe cloud"]
    B["Customer secures data, identities, settings and code"] --> C
    B --> D["Mistakes here cause most incidents"]
    D --> E["Defender for Cloud checks and warns"]
    E --> B
    

Two abbreviations appear everywhere in Defender for Cloud. Once you know them, the whole product makes sense.

Job one: Cloud Security Posture Management (CSPM)

Cloud Security Posture Management, shortened to CSPM, asks the question: “Is my cloud set up safely?” It looks at settings, permissions, network exposure, and missing protections, and compares them with security best practice. It produces recommendations such as “turn on encryption for this disk” or “restrict public network access on this database”. CSPM is about prevention. It reduces the number of doors an attacker could try.

Job two: Cloud Workload Protection (CWPP)

A workload is something you run in the cloud to do real work, such as a server, a container application, a database, or a storage account full of files. Cloud Workload Protection Platform, shortened to CWPP, asks the question: “Is anyone attacking my workloads right now?” It looks at what is happening inside and around them, such as sign-in attempts, process activity, network traffic, and data access, and raises alerts about suspicious patterns. CWPP is about detection and response.

Why you need both

A house with perfect locks can still be broken into by a determined thief, and a house with only cameras lets anyone walk through open doors. Good posture lowers the number of attacks that succeed. Good detection catches the ones that get through. Defender for Cloud combines them in one console so findings from one side can inform the other. For example, a server that has risky open network ports (a posture finding) and is also receiving a flood of login guesses (a threat alert) should be treated as an emergency.

flowchart LR
    R["Your cloud resources"] --> P["Posture: CSPM checks settings"]
    R --> W["Protection: CWPP watches activity"]
    P --> REC["Recommendations and secure score"]
    W --> ALR["Security alerts and incidents"]
    REC --> ACT["Fix weaknesses"]
    ALR --> RESP["Investigate and respond"]
    ACT --> R
    RESP --> R
    

Defender for Cloud is not one switch. It is a set of plans, each protecting a certain kind of resource.

The free foundation

Every Azure subscription gets a basic level of posture management at no extra charge. It is often called the foundational CSPM capability. It continuously assesses your resources against Microsoft’s security baseline, produces recommendations, and calculates a secure score. For many small teams, simply reading and acting on these free recommendations is the best first step.

The paid posture plan

A paid posture plan, commonly called Defender CSPM, adds advanced capabilities on top of the free foundation. These include a map of how resources are connected, attack path analysis, scanning of workloads without installing anything on them, data discovery, and deeper governance features. The details of exactly which features are free or paid can change, so always confirm on Microsoft’s current pages.

Workload protection plans

For threat detection, you enable Defender plans per resource type. Each plan is tuned to the specific attacks that target that kind of resource.

Choosing what to turn on

A practical order is: first read free recommendations, then enable protection for the resources that hold your most important data or face the internet, and then expand. Not every resource needs the most expensive protection. A test virtual machine with no data matters less than a production database.

The moving parts behind the portal pages, from data collectors to dashboards.

The main building blocks

flowchart TD
    subgraph SRC["Where signals come from"]
      A1["Azure resources and control plane"]
      A2["Machines with agents or extensions"]
      A3["Agentless snapshots and scans"]
      A4["AWS and Google Cloud connectors"]
      A5["Code repositories and pipelines"]
    end
    SRC --> ENG["Defender for Cloud analysis engine"]
    ENG --> POL["Policy and standards checks"]
    ENG --> TI["Threat intelligence and detections"]
    POL --> OUT1["Recommendations and secure score"]
    TI --> OUT2["Alerts and incidents"]
    OUT1 --> UI["Portal, workbooks and APIs"]
    OUT2 --> UI
    UI --> EXP["Export to SIEM, tickets and automation"]
    

Agent-based versus agentless

An agent is a small program installed on a machine that reports what it sees. Agents give deep, real-time insight, such as which processes run. An agentless approach instead takes a copy (a snapshot) of the machine’s disk from the cloud side and scans that copy, without touching the machine. Agentless is easier to roll out and cannot be broken by a misconfigured agent, though it offers a snapshot in time rather than live behavior. Many deployments use both: agentless for broad coverage, agents where deep, real-time detection is needed.

The control plane and the data plane

Azure has two layers. The control plane is where you create and manage resources, such as “create a database”. The data plane is where the resources do their work, such as “read a row from the database”. Defender for Cloud watches both. Posture checks mostly read the control plane, since settings live there. Threat detection often looks at data plane activity, since attacks usually try to read or change data.

How Defender for Cloud turns thousands of checks into a clear list and a single number.

What is a recommendation?

A recommendation is a specific finding with a suggested fix. Each one names the weakness, explains the risk, lists the affected resources, and usually offers steps to remediate. Some can be fixed with a single button, called a quick fix. Others require changes by an application team.

What is the secure score?

The secure score is a percentage that summarizes your posture. The more recommendations you complete, the higher it goes. Each recommendation is grouped under a security control, which is a category of protection such as “enable encryption” or “restrict network access”, and fixing all items in a control earns its points. Because controls carry different weights, fixing high-impact issues raises the score more than fixing small ones.

Security standards and initiatives

The checks come from a security standard, a published list of good practices. By default Defender for Cloud uses the Microsoft cloud security benchmark, a collection of recommended controls across areas such as identity, networking, data protection, logging, and posture management. You can add industry and legal standards, for example ones relating to payment card data, healthcare privacy, or general information security frameworks. Technically, these standards are delivered through Azure Policy, which is the Azure service that defines and evaluates rules about how resources must be configured.

Regulatory compliance dashboard

When you add a standard, a dashboard shows each requirement and whether your resources meet it. This helps with audits because you can see passing and failing items and export evidence. Be careful, though: passing the automated checks does not equal being fully compliant. Compliance also depends on processes, people, and documents that no tool can check.

Instead of a flat list of problems, advanced posture shows how problems connect into real routes an attacker could follow.

The problem with long lists

A large company may have tens of thousands of recommendations. Fixing them all is not realistic. Teams need to know which few matter most right now. Two findings that look minor alone can be dangerous together. For example, a virtual machine that is reachable from the internet is one finding. That same machine having a powerful identity that can read a database full of customer data is another. Together they form a path: internet to machine to identity to data.

The cloud security graph

The paid posture plan builds a cloud security graph, a map in which every resource, identity, network link, and permission is a point or a line. Because the relationships are recorded, the system can answer questions such as “which internet-facing resources can reach sensitive data?”

Attack path analysis

An attack path is a chain of weaknesses that could let an attacker move from an entry point to something valuable. Attack path analysis searches the graph for such chains and ranks them by risk. Instead of 5,000 separate to-dos, you see “these ten paths lead to your most sensitive data”, and fixing one weak link may break many paths at once.

flowchart LR
    NET["Internet"] -->|"open management port"| VM["Virtual machine"]
    VM -->|"has strong identity"| ID["Managed identity with wide rights"]
    ID -->|"can read"| DB["Database with customer data"]
    VM -.->|"fix: close port"| X1["Path broken"]
    ID -.->|"fix: reduce rights"| X2["Path broken"]
    

Related capabilities

• Sensitive data discovery: finding storage and databases that hold personal or financial data, so protection can focus on them.
• Internet exposure insight: showing which resources can actually be reached from outside.
• Permissions analysis: highlighting identities with more access than they need.
• Agentless vulnerability and secret scanning: finding missing patches and leaked passwords on machines and containers without installing agents.

A closer look at what the main protection plans watch for, and why each resource type needs its own specialist.

Why specialist plans?

Attacks against a database look nothing like attacks against a container. A guard who understands bank vaults is not the best person to watch a warehouse. Defender plans are built around the typical attack steps for each resource type, so alerts are more accurate and more useful.

Servers

Servers are the classic target. Attackers guess passwords on remote login ports, install malware, run hidden programs, and then spread to neighboring machines. The servers plan combines several things. It runs vulnerability assessment to find missing patches and weak software. It uses Microsoft’s endpoint protection technology to detect malicious files and behavior. It can offer just-in-time access, a feature that keeps management ports closed and opens them only for a short approved time. It can also watch important files for unexpected changes.

Containers

A container is a lightweight package holding an application and everything it needs, and Kubernetes is the system that runs and manages many containers. The containers plan looks at three areas. It scans container images in registries for known vulnerabilities, it checks the cluster configuration for risky settings, and it watches running containers for suspicious behavior, such as a shell started inside a production container where nobody normally logs in.

Storage

Storage accounts hold files, backups, and logs. The storage plan looks for unusual access patterns, such as downloads from a never-seen location, access from anonymous users where it was not expected, or a sudden large data transfer. It can also scan uploaded files for malware and help detect sensitive data. Because storage is a favorite place to steal data, early warnings here matter.

Databases

The database plans look for SQL injection, a trick where an attacker types special text into a web form so the database runs commands the developer never intended. They also notice unusual sign-ins, such as a login from a strange place or a burst of failed password attempts, and suspicious query patterns, such as someone suddenly reading every customer row.

Vulnerabilities, patches, and why they matter

A vulnerability is a flaw in software that an attacker can exploit. When the maker of the software discovers a flaw, they publish a fix called a patch and the flaw gets a public identifier so everyone can talk about it. From that moment, attackers know the flaw exists too, and a race begins between those who patch and those who exploit. Machines that stay unpatched are easy targets because the attacker already has the instructions. Vulnerability assessment in Defender for Cloud lists missing patches and risky software on your machines and images, ranks them by severity, and shows which are most likely to be used by attackers. Fixing the severe, easily reachable ones first closes the doors that are being tried most.

A related idea is the software bill of materials, a list of the ingredients inside an application. If a famous flaw is announced in a popular library, a company with an up-to-date list can answer “are we affected?” in minutes. Container image scanning and code scanning support this by recording what each image and repository contains.

What an alert looks like, how alerts combine, and how to read them without panic.

What is a security alert?

A security alert is a notification that something suspicious or malicious has been detected. A good alert says what happened, which resource was involved, when, how severe it is, and what to do next. Severity levels are typically high, medium, low, and informational, so you can sort your attention.

From many alerts to one incident

A real attack often triggers many alerts: a suspicious login, then a strange process, then unusual data access. Reading them one by one is tiring and can hide the story. Defender for Cloud can combine related alerts into a single incident, a bundle that tells the whole story in one place. That saves time and shows how far the attacker progressed.

Kill chain thinking

Security teams describe attacks as steps, often called a kill chain: reconnaissance (looking around), initial access (getting in), execution (running code), persistence (staying in), privilege escalation (gaining more power), lateral movement (spreading), and exfiltration or impact (stealing or damaging). Alerts in Defender for Cloud are often labeled with a stage from the widely used MITRE ATT&CK framework, a public catalog of attacker techniques. Knowing the stage tells you how urgent the situation is. An alert at the reconnaissance stage is a warning, while one at the exfiltration stage means data may be leaving now.

flowchart LR
    S1["Reconnaissance"] --> S2["Initial access"]
    S2 --> S3["Execution"]
    S3 --> S4["Persistence"]
    S4 --> S5["Privilege escalation"]
    S5 --> S6["Lateral movement"]
    S6 --> S7["Exfiltration or impact"]
    

Responding to an alert

False alarms and tuning

Not every alert is an attack. A security scanner run by your own team can look like an intruder. You can suppress known harmless alerts with rules, but do this with care, narrowly and with an expiry date, so a real attack does not hide behind a broad exception.

Reading an alert like a detective

Every good alert answers five simple questions. Who did it: which account, address, or program was involved. What happened: the action, such as a login, a file download, or a started program. Where it happened: which resource, region, and subscription. When it happened, and whether it is still happening. Why it matters: what the attacker could gain. When you read an alert, write short answers to these five questions before doing anything else. This habit stops hurried mistakes, such as shutting down the wrong server, and it makes your notes useful for the next person who handles a similar case.

Next, look for context around the alert. Was there a recent change to the resource, such as a new firewall rule or a new administrator? Did the same address appear in other alerts? Does the user normally work at this hour and from this place? A login from a far-away country is alarming for an office worker who never travels, but ordinary for a salesperson on a business trip. Context turns a raw signal into a decision.

Follow a single risky setting and a single attack as they move through Defender for Cloud.

sequenceDiagram
    participant R as Azure resource
    participant D as Defender for Cloud
    participant T as Security team
    participant A as Automation
    participant X as Attacker
    R->>D: Configuration data and activity signals
    D->>D: Compare with standards and detections
    D-->>T: Recommendation: public access enabled
    T->>R: Fix setting and restrict access
    X->>R: Tries to log in with guessed passwords
    R->>D: Failed login activity
    D->>D: Match with brute force pattern
    D-->>T: Security alert with severity
    D->>A: Trigger workflow
    A->>R: Block address or open ticket
    

Path one: a posture finding

• Collect: Defender for Cloud reads configuration from the resource through Azure’s management interfaces.
• Evaluate: Each setting is compared with the active standards. A failed rule marks the resource as unhealthy.
• Present: A recommendation appears with severity, affected resources, and steps.
• Assign: Governance features can give it an owner and a due date.
• Remediate: The owner fixes it manually, with a quick fix, or through automation. The next evaluation marks the resource healthy.

Path two: a threat alert

• Observe: Signals such as sign-in logs, process events, network flows, and data access are gathered.
• Detect: Detection logic and Microsoft’s threat intelligence look for known attack patterns and unusual behavior.
• Raise: An alert, or an incident bundle, is created with details and suggested response steps.
• Notify and route: Email, ticketing, or a security operations platform receives it.
• Respond: People or automation contain and fix the issue, and the alert is closed with notes.

How fresh is the data?

Posture assessments run periodically, not instantly. After you fix a setting, the recommendation may take some time to turn healthy. Threat alerts are generally raised much faster than posture changes appear, because detection works on live activity. Do not worry if the portal lags behind your change; wait for the next evaluation cycle before assuming the fix failed.

Humans cannot answer every alert by hand. Automation lets Defender for Cloud trigger actions and share data with the tools you already use.

Workflow automation

Defender for Cloud can start an automated workflow when an alert, a recommendation, or a compliance change occurs. The workflow is usually built with Azure Logic Apps, a low-code service that connects steps like “when X happens, do Y”. Typical actions include sending a message to a chat channel, creating a ticket, adding a tag to a resource, or starting an investigation process.

Continuous export

You can continuously export alerts, recommendations, and secure score data to a Log Analytics workspace, an event hub, or storage. A Log Analytics workspace is a searchable store for logs in Azure Monitor. An event hub is a high-speed stream that other systems can read. Exporting lets long-term analysis, reporting, and integration with outside tools.

Microsoft Sentinel and the wider Defender family

Microsoft Sentinel is Microsoft’s cloud SIEM and SOAR platform. A SIEM (security information and event management) system collects security data from everywhere into one place for searching and correlation, while SOAR (security orchestration, automation, and response) automates replies. Defender for Cloud alerts can flow into Sentinel, where security analysts combine them with data from identity systems, email, and networks. Microsoft also offers a unified security operations experience across its Defender products. Check current documentation for how these experiences are combined, since the packaging evolves.

flowchart TD
    DFC["Defender for Cloud"] --> WF["Workflow automation with Logic Apps"]
    DFC --> EXP["Continuous export"]
    WF --> TKT["Ticketing system"]
    WF --> CHAT["Chat notification"]
    WF --> FIX["Automatic remediation step"]
    EXP --> LAW["Log Analytics workspace"]
    EXP --> EH["Event hub"]
    LAW --> SENT["Microsoft Sentinel"]
    EH --> OTHER["Third party security tools"]
    

Fixing at scale

Azure Policy can also fix problems automatically. A policy with a “deploy if not exists” effect can add a missing setting, such as turning on diagnostic logs, to all resources of a type, including new ones. A policy with a “deny” effect can prevent creating non-compliant resources at all. These are powerful, so test them in a small scope first.

Real companies rarely live in one place, and security must start before code reaches production.

Connecting AWS and Google Cloud

Defender for Cloud uses connectors to bring other clouds into view. You grant a read-oriented role in the other cloud, the connector discovers resources, and recommendations and alerts appear next to your Azure ones. Resources are measured against standards for that cloud, and a combined secure score is possible. This helps teams avoid separate dashboards and different rules in each environment.

On-premises and hybrid servers

Servers in your own data center can be connected using Azure Arc, a service that projects non-Azure machines into Azure so they can be managed with Azure tools. Once connected, they can use the same protection plans as cloud servers.

DevSecOps: security in the build pipeline

DevSecOps means building security into every step of software creation instead of testing it at the end. Defender for Cloud can connect to source code repositories and build pipelines to scan for issues early. It can find insecure infrastructure templates, vulnerable dependencies, and leaked secrets in code, and show which risky code ends up running in which cloud resource. Fixing a problem in code before release is far cheaper than fixing it in production.

flowchart LR
    CODE["Write code"] --> SCAN1["Scan code, templates and secrets"]
    SCAN1 --> BUILD["Build and package"]
    BUILD --> SCAN2["Scan images and dependencies"]
    SCAN2 --> DEPLOY["Deploy to cloud"]
    DEPLOY --> RUN["Posture and threat protection at runtime"]
    RUN -.->|"findings guide developers"| CODE
    

Tools that see everything must themselves be tightly controlled.

Governance: giving findings an owner

A list of recommendations helps nobody if nobody feels responsible. Governance rules let you assign an owner and a due date to recommendations automatically, for example by resource tag, team, or subscription. Reports then show overdue items and progress. This turns security from “the security team’s problem” into shared work with deadlines.

Who can do what

Use the principle of least privilege: give each person the smallest set of rights they need. Assign roles to groups rather than individuals, and prefer time-limited elevation, such as privileged identity management, for powerful rights.

Protecting the protector

• Require multi-factor sign-in for anyone with security roles.
• Watch the activity log for changes to Defender settings, such as plans being turned off or alerts being suppressed. An attacker who gains access may try to blind the guards first.
• Use management group level policies so that individual subscription owners cannot silently disable key protections.
• Review exemptions regularly, and require an expiry date and a reason for each.

Data and privacy

Defender for Cloud processes metadata about your resources and security events. Choose workspace locations and retention that match your legal obligations, and read Microsoft’s current data handling documentation if you work under strict residency rules.

No single tool makes you safe. Layers do.

Defense in depth means placing several independent protections one behind another, so that when one fails another still stops the attacker. Defender for Cloud is not a replacement for other protections. It is the layer that checks them and watches for the attacks that still get through.

flowchart TD
    L1["Identity: strong sign-in and least privilege"] --> L2["Network: firewalls, private connections, segmentation"]
    L2 --> L3["Compute: patching, hardening, endpoint protection"]
    L3 --> L4["Application: secure code, web protection"]
    L4 --> L5["Data: encryption, access control, backups"]
    L5 --> L6["Monitoring: Defender for Cloud, logs, SIEM"]
    L6 -.->|"checks and feeds back into every layer"| L1
    

Keeping Defender for Cloud itself healthy, trustworthy, and affordable.

What to monitor about the monitor

Useful measures

• Mean time to detect: how long an attack lasts before anyone notices.
• Mean time to respond: how long from noticing to containing.
• Recommendation age: how long high-severity items stay open.
• Coverage percentage: share of resources protected by the right plans.
• Exemption count: a rising number often signals hidden risk.

Logging and retention

Alerts and recommendations shown in the portal have limited history. If you need long retention for audits or investigations, export them to a workspace or storage with a retention period that matches your rules. Also keep resource logs, such as sign-in and activity logs, because investigators will need them to rebuild what happened.

Reliability

Defender for Cloud is a managed Microsoft service, so you do not run its servers. Your reliability tasks are different: keep connectors authorized, keep agent extensions healthy, and make sure alert routing does not depend on a single mailbox or a single person. A great detection that emails someone on holiday is not a detection at all.

Cost awareness

Defender plans are billed by the type and amount of resource protected, for example by server, by storage account, or by usage. Exact prices, billing units, and free trial periods change, so use the official pricing pages and the portal’s cost estimates. What stays stable are the cost drivers and the ways to control them.

Approaches that mature teams repeat, and traps they learned to avoid.

Pattern: management group baseline

Apply core settings, standards, and plans at the top management group so every current and future subscription starts protected. Individual teams can add more, but cannot go below the floor.

Pattern: central security, distributed ownership

A central security team defines standards and watches alerts. Application teams own the fixes for their resources, assisted by governance rules that assign owners and due dates.

Pattern: risk-based prioritization

Rank work by attack paths, internet exposure, and data sensitivity, not by raw recommendation count.

Pattern: prevent, detect, respond

Use policy to prevent known bad settings, Defender plans to detect what still happens, and automation plus playbooks to respond consistently.

flowchart TD
    MG["Top management group: baseline standards and plans"] --> S1["Production subscriptions"]
    MG --> S2["Development subscriptions"]
    MG --> S3["Connected AWS and Google accounts"]
    S1 --> CENT["Central security team watches alerts"]
    S2 --> CENT
    S3 --> CENT
    S1 --> OWN1["Application teams own fixes"]
    S2 --> OWN2["Application teams own fixes"]
    

Anti-patterns

A rollout plan you can start on day one, followed by the mistakes that trip up many teams.

A practical rollout

Common mistakes

Growing the practice over time

Security maturity is a ladder, and it is fine to climb one rung at a time. At the first rung, a team simply looks at recommendations when someone remembers. At the second rung, there is a weekly meeting where owners report progress on high-severity items. At the third rung, alerts are routed to named responders with response guides, and drills are held. At the fourth rung, policy prevents known bad settings, and automation handles routine responses. At the fifth rung, the team measures detection and response times, studies every incident for lessons, and uses attack path analysis to decide what to build next. Knowing your rung helps you choose the next sensible step instead of trying to do everything at once.

It also helps to keep a small written playbook for the most likely incidents: an exposed storage container, a compromised account, a server under brute-force attack, and a leaked secret. For each one, write who decides, who acts, what is done first, how to confirm the problem is gone, and who must be told. A one-page playbook that people have actually read is worth more than a hundred-page manual nobody opens during a crisis.

Finally, remember the human side. Developers who are told “your resource failed a check” with no explanation feel blamed and tend to ignore the message. Developers who are shown the risk, given the fix steps, and thanked for improvements become partners. Celebrate progress, share simple charts of improving trends, and explain the reason behind every rule. Good security culture is built from small, respectful, repeated habits.

These are composite examples that show typical situations. They are illustrations, not reports about specific companies.

Microsoft security names can be confusing. This table explains who does what.

flowchart TD
    Q["What do you need"] --> A{"Check cloud settings and protect workloads"}
    A -->|"yes"| DFC["Defender for Cloud"]
    Q --> B{"Collect and correlate all security data"}
    B -->|"yes"| SEN["Microsoft Sentinel"]
    Q --> C{"Enforce rules on new resources"}
    C -->|"yes"| POL["Azure Policy"]
    Q --> D{"Manage who can sign in"}
    D -->|"yes"| ENT["Microsoft Entra ID"]
    

Defender for Cloud turns a huge, changing cloud into something you can see, improve, and defend.

We began with an apartment building where a security company inspects the doors and also watches the cameras. That picture holds the whole story. Defender for Cloud inspects (posture management) and it watches (workload protection). It collects signals from your resources, compares them with security standards, builds a score and a to-do list, and uses specialized detections to raise alerts when real attacks appear. Advanced posture features connect findings into attack paths so you fix what matters most, and automation, governance, and integrations make sure findings reach the right people and lead to action.

The deeper lesson is that cloud security is a habit, not a product. The service shows what is wrong and what is happening, but only people and processes close doors, answer alarms, and learn from incidents. Start simple, protect what is most valuable, give every finding an owner, and keep improving.