Java / Microsoft Defender for Cloud Interview questions

Microsoft Defender for Cloud is Microsoft's cloud-native application protection platform (CNAPP). It helps you find misconfigurations, harden resources and detect threats across Azure, AWS, Google Cloud and on-premises or hybrid servers from a single console.

It brings together two jobs. Posture management continuously checks your resources against security standards and tells you what to fix. Workload protection adds threat detection for servers, containers, storage, databases and more. It was formed from Azure Security Center and Azure Defender, which Microsoft merged under one name.

Basic posture features (Foundational CSPM) switch on automatically for Azure subscriptions at no charge. The paid Defender plans are enabled per resource type.

A CNAPP (cloud-native application protection platform) is a single product that secures cloud applications from code to runtime, instead of making you stitch together separate scanners. Defender for Cloud is Microsoft's answer to this category.

The capabilities it unifies map to the usual CNAPP building blocks:

• CSPM - misconfiguration and compliance checks
• CWPP - runtime protection for servers, containers and databases
• DevSecOps - scanning code and infrastructure-as-code in GitHub, Azure DevOps and GitLab
• Permissions management - spotting over-privileged identities (CIEM)
• Data security posture - finding sensitive data and its exposure

The value is correlation: a vulnerable container image, the pipeline that built it and the cluster running it can be linked in one view.

CSPM is the practice of continuously checking cloud resources against security best practices and compliance rules, then reporting what is misconfigured. In Defender for Cloud it is the foundation everything else sits on.

Defender for Cloud evaluates resources against the Microsoft cloud security benchmark, produces recommendations, and rolls the results into a Secure Score. Typical findings are storage accounts open to the public internet, VMs with no endpoint protection, or databases without auditing.

There are two tiers: free Foundational CSPM and the paid Defender CSPM plan, which adds attack path analysis, agentless scanning, governance rules and more.

Secure Score is a percentage that summarises how well your environment follows the recommendations Defender for Cloud has assessed. A higher number means fewer open security gaps.

Recommendations are grouped into security controls, such as Enable MFA or Restrict unauthorized network access. Fixing every resource under a control earns that control's points. The score is shown per subscription, and you can view it across subscriptions to compare teams.

Treat it as a trend line, not a grade. It tells you where the biggest gaps are and lets you show progress to management over time.

A recommendation is an actionable finding that tells you which resource is misconfigured, why it matters, and how to fix it. Each one lists the affected resources, a severity, remediation steps and, for many, a Fix button that applies the change.

Resources show up as unhealthy, healthy or not applicable. You can assign an owner, set a due date, or exempt a resource if the risk is accepted.

In 2026 Microsoft moved the Azure portal to individual recommendations and scheduled the older grouped recommendation types for removal, so each finding is tracked and prioritised on its own.

The Microsoft cloud security benchmark (MCSB) is Microsoft's set of prescriptive security controls for cloud workloads. It is the default standard Defender for Cloud assigns to every onboarded subscription, which is why recommendations appear without any setup.

Controls are organised into domains such as network security, identity management, privileged access, data protection, logging and threat detection, posture and vulnerability management, and DevOps security. The benchmark is mapped to well-known frameworks like CIS, NIST and PCI DSS, so one fix can support several audits.

Version 2 of the benchmark appeared in preview in late 2025, so check the current status before quoting it in an interview.

Defender for Cloud covers more than Azure. The supported environments are:

• Azure - subscriptions and their resources, protected natively
• AWS - accounts or whole organizations, onboarded through a connector
• Google Cloud (GCP) - projects or organizations, onboarded through a connector
• On-premises and other clouds - servers connected through Azure Arc
• DevOps platforms - GitHub, Azure DevOps and GitLab through connectors

Azure resources need no connector. AWS and GCP use connectors in Environment settings, and non-Azure machines are brought in through Azure Arc.

Workload protection is sold as separate plans, each tied to a resource type. The main ones are:

Plans are enabled per subscription, so you only pay for the resource types you actually run.

Defender for Servers is the plan that protects Windows and Linux machines, whether they run in Azure, AWS, GCP or on-premises through Azure Arc. It adds threat detection and vulnerability management on top of the free posture checks.

It comes in two tiers. Plan 1 focuses on endpoint detection and response through the integrated Microsoft Defender for Endpoint. Plan 2 includes Plan 1 and adds extras such as just-in-time VM access, file integrity monitoring, agentless scanning and a free Log Analytics ingestion allowance per server.

Billing is per server per month, and you can set the plan on individual machines using resource-level configuration.

Defender for Containers secures Kubernetes environments end to end: AKS, Amazon EKS, Google GKE and Arc-enabled clusters, plus the registries that hold your images.

It covers three areas: image vulnerability scanning in registries such as ACR, ECR and Google Artifact Registry, runtime threat detection on nodes and clusters, and hardening recommendations for cluster configuration. Alerts include things like a shell opened in a pod or a crypto-mining image.

Because it spans build, registry and runtime, it can show that a vulnerable image is both stored in a registry and currently running, which makes triage much easier.

Defender for Storage detects threats against Azure Storage accounts, including Blob Storage, Azure Files and Data Lake Storage. It is priced per storage account, with add-ons for malware scanning and sensitive data discovery.

Its three main capabilities are:

• Activity monitoring - unusual access, such as access from a Tor exit node or a sudden spike in data extraction
• Malware scanning - files are scanned as they are uploaded
• Sensitive data threat detection - flags access patterns involving data classed as sensitive

Defender for Databases bundles protection for several database types: Azure SQL Database and Managed Instance, SQL Server on machines (Azure, AWS, GCP and on-premises), open-source relational databases such as PostgreSQL, MySQL and MariaDB, and Azure Cosmos DB. In June 2026 Microsoft announced general availability for open-source relational databases on AWS RDS as well.

It detects behaviours such as SQL injection attempts, brute-force logins, access from unusual locations and potentially harmful queries, and raises alerts. SQL plans also include vulnerability assessment to find misconfigurations like excessive permissions or missing auditing.

Defender for Resource Manager watches the Azure management plane, meaning every operation sent through Azure Resource Manager from the portal, CLI, PowerShell, REST APIs or templates.

It looks for suspicious management activity, for example operations from anonymising IP addresses, use of known attack toolkits like MicroBurst, or sudden creation of many resources that suggests an attacker is establishing persistence. It is enabled at the subscription level and does not need an agent.

The alerts are especially useful for spotting an attacker who has stolen credentials, since their first moves, such as listing keys or changing permissions, show up as management operations.

Defender for APIs protects APIs published through Azure API Management. It discovers and inventories your APIs, highlights posture problems and detects attacks aimed at them.

Typical findings include APIs that accept unauthenticated calls, APIs that are inactive but still exposed, and endpoints that return sensitive data. Threat detection uses machine learning to flag unusual patterns such as sudden spikes in calls or data exfiltration. Pricing is tiered by the volume of API calls, with overage charges beyond the plan limit.

Agentless scanning inspects virtual machines without installing anything on them. Defender for Cloud takes a snapshot of the VM's disks, analyses the copy in a Microsoft-managed environment and then deletes it.

It finds installed software and known vulnerabilities, secrets stored on disk such as keys or passwords, and (with Defender for Servers Plan 2) malware. Because the workload is never touched, there is no performance impact and no agent to deploy or keep healthy. It works for Azure VMs, AWS EC2 and GCP instances, and is available through Defender CSPM and Defender for Servers Plan 2.

Just-in-Time (JIT) access keeps management ports like RDP (3389) and SSH (22) closed by default and opens them only when someone requests access, for a limited time and from a specific IP address.

Defender for Cloud does this by adding temporary allow rules to the network security group or Azure Firewall. When the window ends, the rule is removed automatically. This shrinks the attack surface that brute-force and port-scanning attacks rely on. JIT requires Defender for Servers Plan 2.

The regulatory compliance dashboard shows how your environment measures up against a chosen standard, such as the Microsoft cloud security benchmark, PCI DSS, ISO 27001, SOC 2 or NIST SP 800-53.

Each standard is broken into controls, and each control is linked to the recommendations that support it. You see which controls pass, which fail, and which still need manual evidence. You can also download audit reports. Adding standards beyond the default usually requires a Defender plan, so confirm current licensing before relying on it.

A security alert is a notification that Defender for Cloud has detected suspicious activity against one of your resources. Alerts come from the paid Defender plans, not from the free posture checks.

Each alert has a severity, a description of what happened, the affected resource, the related MITRE ATT&CK tactic and recommended response steps. Examples include a possible brute-force attack on an SSH server, a suspicious process on a Linux node, or access to a storage account from a Tor exit node.

Workflow automation runs an Azure Logic App automatically when something happens in Defender for Cloud. You pick a trigger, a scope and the Logic App to run.

Supported triggers are a new security alert, a new or changed recommendation, and a change in regulatory compliance status. Common uses are posting a message to Microsoft Teams, opening a ServiceNow or Jira ticket, or emailing a resource owner. It saves analysts from copying details between tools by hand.

You can create the automation at subscription or management group scope, and it fires every time a matching event appears, so it works well for routing high-severity alerts to the on-call team.

Foundational CSPM is already on for Azure subscriptions. To add paid protection, open Defender for Cloud > Environment settings, choose the subscription, switch the plans you need to On, and save.

For automation, use the CLI, Azure Policy or infrastructure as code. This example turns on Defender for Servers Plan 2:

az security pricing create --name VirtualMachines --tier Standard --subplan P2

Some plans have extensions, for example agentless scanning or malware scanning, that you can toggle separately in the same screen.

Foundational CSPM is free and gives you the basics: continuous assessment, recommendations, Secure Score and the Microsoft cloud security benchmark. Defender CSPM is a paid plan that adds the context needed to prioritise risk and trace it back to code.

Pick Foundational CSPM to learn what is wrong. Pick Defender CSPM when you need to know which problems an attacker could actually chain together.

Plan 1 is the leaner option built around Defender for Endpoint. Plan 2 contains everything in Plan 1 and adds cloud-specific hardening and scanning features.

Microsoft adjusts the feature split over time, so confirm the current plan comparison page before choosing. A common pattern is Plan 2 for production servers and Plan 1 for dev and test.

Defender for Cloud uses the cloud provider's snapshot APIs, so nothing runs inside the guest operating system. The flow is:

flowchart LR
  A["VM disks"] --> B["Snapshot taken"]
  B --> C["Copy to Microsoft-managed account in same region"]
  C --> D["Scan: software, vulnerabilities, secrets, malware"]
  D --> E["Findings sent to Defender for Cloud"]
  C --> F["Snapshot copy deleted"]

The snapshot is analysed in the same region as the VM, so data does not leave its geography. For AWS the equivalent is EBS snapshots, and for GCP it is disk snapshots. Results appear as recommendations and feed attack path analysis. Encrypted disks may need extra key permissions before the scanner can read them.

Both clouds use security connectors created under Environment settings > Add environment. You choose the account or organization, select the plans, then run a generated template that creates the required access.

Once connected, posture assessment starts without agents. For workload protection on EC2 or GCE machines, Defender for Servers uses Azure Arc, and the connector can auto-provision it. Onboarding at organization level means new accounts are picked up automatically.

On-premises and other-cloud servers are projected into Azure with Azure Arc. You install the Connected Machine agent, and the server becomes an Arc-enabled resource in a subscription and resource group.

After that, Defender for Servers treats it much like an Azure VM: recommendations, Defender for Endpoint onboarding, vulnerability assessment and alerts all apply. Arc-enabled SQL Servers can be covered with the Defender for SQL on machines plan. The main requirement is outbound connectivity from the server to the Azure Arc and Defender endpoints.

This keeps one consistent view across hybrid estates, so a datacenter server and a cloud VM share the same Secure Score and recommendation workflow.

Each security control has a maximum score. A control's earned points depend on how many applicable resources are healthy:

Control score = max score x (healthy resources / total applicable resources)

The overall Secure Score is the sum of earned control points divided by the sum of the maximum points, shown as a percentage. For example, a control worth 6 points with 8 healthy resources out of 10 earns 4.8 points.

Resources marked not applicable or exempted are removed from the calculation, so exemptions can raise the score. Points are earned only when every recommendation in a control is fully addressed for a resource, which is why a partly fixed control shows little movement.

Defender CSPM builds a cloud security graph that records resources, identities, permissions, network exposure and vulnerabilities as connected nodes. Attack path analysis queries that graph for routes an attacker could realistically follow, starting at an entry point such as an internet-exposed VM and ending at something valuable, such as a database with sensitive data.

flowchart LR
  A["Internet-exposed VM"] --> B["Known vulnerability"]
  B --> C["Managed identity with broad rights"]
  C --> D["Storage account with sensitive data"]

Instead of hundreds of unrelated recommendations, you see one path and fixing any link, such as patching the VM or narrowing the identity, breaks it. Paths are ranked by risk so teams start with the ones that matter most. The feature requires the Defender CSPM plan.

The cloud security explorer is a query builder on top of the cloud security graph. You build searches by picking resource types and conditions from menus, with no query language needed, and it returns matching resources.

It helps with hunting and investigation questions that recommendations alone cannot answer, such as:

• Which internet-exposed VMs have high-severity vulnerabilities?
• Which identities can read this Key Vault?
• Which container images with critical findings are running in production clusters?

You can start from built-in templates and save your own. It is available with Defender CSPM.

It also acts as a quick incident-response aid: after a breach you can ask which resources an affected identity could reach, and scope the damage within minutes.

They solve related but different problems. Azure Bastion gives browser-based RDP and SSH through a managed service, so the VM needs no public IP at all. JIT access keeps the VM's own management ports closed and opens them briefly for a named requester.

Use JIT when you must keep using native RDP or SSH clients and want time-limited, audited access. Use Bastion when you can remove public exposure entirely. They can also be combined.

Open the recommendation, select the affected resources and choose Exempt. You give a reason, either Waiver (risk accepted) or Mitigated (handled by another control), add an optional expiry date and save.

Exemptions can be scoped to a single resource, a resource group, a subscription or a management group. Once applied, the resource moves to not applicable for that recommendation, so it stops lowering your Secure Score and drops off the open list. The exemption is recorded for audit, and an expiry date makes sure it is reviewed later instead of lasting forever.

A common example is a legacy VM that cannot take an endpoint agent for compatibility reasons but sits behind compensating network controls. Record that justification in the exemption comment.

Continuous export streams Defender for Cloud data out of the portal to a destination you control. Configure it under Environment settings, choose the subscription, then pick the data types and the target.

• Data types: security alerts, recommendations, Secure Score and regulatory compliance data
• Targets: a Log Analytics workspace or an Azure Event Hub
• Mode: streaming as events happen, or periodic snapshots of recommendation state

Log Analytics lets you query and build workbooks, while Event Hubs is the route to third-party SIEM tools such as Splunk. Because it is a policy-based setting, you can deploy it at scale with Azure Policy.

Sentinel needs Defender for Cloud's alerts and incidents so analysts can investigate them next to other data. Microsoft's current direction is to bring them in through the Defender XDR connector, which carries Defender for Cloud incidents with their correlated alerts. Older subscription-based and tenant-based Defender for Cloud connectors still exist in many workspaces.

Steps in practice:

1. Enable the Defender for Cloud plans you need.
2. In Sentinel, enable the relevant data connector.
3. Check that alerts appear in the SecurityAlert table.
4. Build analytics rules, automation rules and playbooks on top.

Avoid enabling several overlapping connectors, which creates duplicate incidents.

Once alerts flow, you can write analytics rules that combine them with identity or firewall logs, for example a Defender for Cloud brute-force alert plus a successful sign-in from the same IP address.

Protection is layered across the container lifecycle:

1. Discovery and posture: clusters are found agentlessly, and configuration issues become recommendations.
2. Registry scanning: images in ACR, ECR, Google Artifact Registry and Docker Hub are scanned for vulnerabilities when pushed and rescanned as new CVEs appear.
3. Runtime protection: a Defender sensor deployed as a DaemonSet watches node and pod behaviour and raises alerts.
4. Admission control: Azure Policy for Kubernetes can enforce rules, such as blocking privileged containers, at deployment time.

This is why it reports both what could go wrong (image CVEs, risky configuration) and what is going wrong (a reverse shell in a running pod).

When malware scanning is enabled, Defender for Storage scans blobs as they are uploaded using Microsoft Defender Antivirus technology. On-demand scanning is also available for existing data.

Each scan produces a verdict. You can see it as a blob index tag, as an Event Grid event or in Log Analytics, and a security alert is raised for malicious files. This lets you build a pipeline that automatically moves or deletes infected files. Scanning is configured per storage account and can be capped by a monthly gigabyte limit to control cost.

Remember that scanning covers content as it arrives, so pair it with least-privilege access and private endpoints rather than treating it as the only line of defense.

An alert is a single detection, such as a suspicious process on one VM. An incident groups related alerts into one attack story, so an analyst sees the full chain rather than isolated events.

For example, a brute-force alert followed by a suspicious sign-in, then a new admin account, might be merged into one incident. Correlation reduces noise and shortens triage time.

In an interview, mention that you triage at the incident level and use individual alerts only for evidence, since that is how most SOC teams actually work.

Governance rules let you stop chasing owners by hand. A rule says: for recommendations matching these criteria in this scope, automatically assign this owner and require a fix by this date. They are part of Defender CSPM.

A rule defines:

• Scope - subscriptions, AWS accounts, GCP projects or a connector
• Criteria - by severity, by specific recommendations or by security control
• Owner - a named person or an owner taken from a resource tag
• Remediation timeframe - a due date relative to assignment, with an optional grace period during which the item does not hurt the score

Owners and their managers receive email notifications and reminders, and a weekly digest lists overdue items. Rules are evaluated in priority order, so a specific rule for production should rank above a catch-all rule. The result is a clear accountability trail: every open recommendation has an owner and a deadline, and the Secure Score trend now reflects real team behaviour rather than a central team's effort.

It extends posture management to the pipeline so problems are caught before deployment. You connect GitHub, Azure DevOps or GitLab with a DevOps security connector, and Defender for Cloud starts scanning.

• Infrastructure-as-code scanning for Terraform, ARM, Bicep, CloudFormation and Kubernetes manifests, with tools such as Checkov
• Code and dependency scanning through GitHub Advanced Security or partner integrations
• Pull request annotations that show developers the finding where they work
• Code-to-cloud mapping that links a runtime resource back to the repository and pipeline that created it

Code-to-cloud mapping is the real payoff. When a container in production has a critical vulnerability, the finding can point to the exact repository and owner, so remediation goes to the team that can fix the source rather than only patching the running instance. Some of these capabilities need the Defender CSPM plan, so confirm licensing for your setup.

Two angles apply: posture and threat protection.

AI security posture management discovers generative AI resources and pipelines, such as Azure OpenAI and Azure AI services and, on AWS, Bedrock, then raises recommendations and includes them in attack path analysis. Threat protection for AI services raises alerts on abuse such as jailbreak attempts, prompt injection, credential theft and suspicious data access, with alerts flowing into Defender XDR.

Be aware that this area moves quickly. Reporting from July 2026 says that agent-focused capabilities, including discovery and posture for Microsoft Foundry agents, moved to the separate Agent 365 service from July 1, 2026, with different licensing. In an interview, say what you know and mention that you would verify the current licensing split before advising a customer.

Costs follow what you protect, so tuning is mostly about scoping and plan choice, not turning protection off.

1. Match plan to risk. Use Defender for Servers Plan 2 for production and Plan 1, or none, for short-lived dev and test machines. Set the plan per resource with tags or resource-level configuration.
2. Use the included benefits. Plan 2 includes a daily Log Analytics ingestion allowance (500 MB per server), so route Defender data there and avoid paying for it twice.
3. Scope Defender CSPM. It is billed on billable resources, so apply it to production subscriptions first.
4. Cap storage scanning. Set a monthly gigabyte limit for malware scanning and avoid enabling it on high-volume accounts without need.
5. Pre-purchase commit units. The one-year pre-purchase plan gives discounts of up to 22 percent against pay-as-you-go prices.
6. Review regularly. Remove protection for decommissioned subscriptions and orphaned resources.

Never cut cost by disabling a plan on critical assets. Reduce scope on low-risk ones instead.

Neither is better, because they do different jobs and work best together.

Defender for Cloud tells you what is weak and detects attacks on workloads. Sentinel collects signals from everywhere, including firewalls, identity and SaaS, to correlate across your whole estate. A typical design feeds Defender for Cloud alerts into Sentinel. Choosing one only makes sense for a very small environment.

If an interviewer asks for a one-liner: Defender for Cloud is the sensor and posture engine for your cloud estate, while Sentinel is the central analysis and response layer.

Work from licensing outward to the machine:

1. Plan and setting: confirm Defender for Servers is on for the subscription and the Defender for Endpoint integration is enabled.
2. Extension: on Azure and Arc machines check that the MDE extension is installed and healthy.
3. Operating system: verify the OS version is supported, as older Windows Server versions need the unified solution.
4. Connectivity: make sure the server can reach the Defender endpoints through any proxy or firewall.
5. Conflicts: look for another antivirus product, especially on Linux.
6. Portal view: check the device appears in the Defender portal device inventory.

A quick extension check on an Azure VM:

az vm extension list --resource-group rg-prod --vm-name vm01 --query "[].{name:name,state:provisioningState}" -o table

If the extension shows Failed, review its logs and reinstall after fixing the network or OS issue.

An alert passes through five stages:

flowchart LR
  A["Telemetry collected"] --> B["Detection: analytics, ML, threat intelligence"]
  B --> C["Alert raised with severity and MITRE tactic"]
  C --> D["Correlated into an incident"]
  D --> E["Notify or automate: email, Logic App, Sentinel"]
  E --> F["Investigate, contain, remediate, close"]

Detection runs on signals from agents, platform logs and snapshots, using behavioural analytics, machine learning and Microsoft threat intelligence. The alert then carries severity, affected resources and recommended steps.

Related alerts are merged into an incident, and notifications or workflow automations start the response. Analysts investigate, contain the threat, for example by isolating a machine or revoking a key, and then fix the root cause, which often links back to a recommendation. Closing the alert with a classification, such as true or false positive, helps tune detection later.

They are three levels of response to a misconfiguration, and they act on different timelines.

Fix is a quick clean-up for resources that already exist. Enforce relies on a deploy if not exists Azure Policy, so new resources get corrected automatically. Deny uses an Azure Policy deny effect and stops bad resources entering your environment.

Deny is the strongest and can break pipelines, so try it in audit mode first. Not every recommendation supports all three options.

Defender CSPM discovers where sensitive data lives and uses that fact to rank risk. Sensitive data discovery covers Azure storage and databases and, for multicloud, resources such as AWS S3 buckets and RDS databases.

The scanner samples data in place and identifies sensitive information types, such as credit card or national ID numbers, and can use sensitivity labels from Microsoft Purview. Results do not require copying the data out of your environment. The findings appear as recommendations and, crucially, feed the security graph.

A storage account with sensitive data and public access ranks above one with no sensitive data, and an attack path ending at it is rated higher. This turns a long list of misconfigurations into a priority order based on the value of what is at stake.

The approach depends on the cloud.

This is useful when your company has a rule the benchmark does not cover, for example every storage account must carry a cost-centre tag, or only approved regions are allowed. The custom item then appears in the dashboard and compliance view like a built-in one, and can be assigned owners by governance rules. Check current documentation for the exact licensing and preview status of the multicloud KQL feature.

Defender for Cloud's alerts and incidents flow into Microsoft Defender XDR, where they are correlated with endpoint, identity, email and app signals. This gives a single incident for an attack that spans, say, a phishing email and a compromised cloud VM.

Defender XDR advanced hunting also exposes cloud data, including tables for cloud storage events, so you can hunt with KQL across domains. Since a preview announced in late 2025, the cloud security experience has been moving into the unified Defender portal as well, while the Azure portal view continues to exist.

Practically, SOC teams work the incident queue in the Defender portal, and cloud posture teams still use Defender for Cloud for recommendations and plan management. Check the current rollout state before describing where each feature lives.

Defender for Cloud writes its assessments, alerts and Secure Score into the securityresources table in Azure Resource Graph, so you can query them across all subscriptions in seconds with KQL. This example counts unhealthy assessments by recommendation name:

securityresources
| where type == "microsoft.security/assessments"
| extend status = tostring(properties.status.code)
| where status == "Unhealthy"
| summarize count() by tostring(properties.displayName)
| order by count_ desc

Run it in the Azure portal Resource Graph Explorer or with az graph query. It is handy for custom reports and compliance evidence. Sub-assessments, such as individual vulnerability findings, have their own type under the same table.

You can also join assessments with the resources table to add tags or resource names, which makes reports for specific application owners straightforward.

With Defender CSPM, recommendations are ranked by risk level rather than only by static severity. Risk takes into account how likely a weakness is to be exploited and how much damage would follow.

Factors include whether the resource is exposed to the internet, whether a known vulnerability is exploitable, how valuable the resource is (for example, it holds sensitive data), and whether it has privileged access or a path to other assets. A medium-severity issue on an exposed server with sensitive data can outrank a high-severity one on an isolated test machine.

The practical benefit is a short, ordered work queue. Teams fix the handful of items that open real attack paths first, instead of working through a Secure Score checklist item by item.

Avoid clicking through each subscription. Standardise through management groups and code.

Pilot on a few subscriptions, review the cost and alert volume, then widen the scope. Keep the configuration in Bicep or Terraform so drift is easy to detect. Plans that need extensions, such as agentless scanning, should be set in the same code.

Tune, do not switch off. The steps in order are:

1. Investigate first. Confirm the alert really is benign, for example a known admin tool or a penetration test.
2. Create a suppression rule scoped as tightly as possible: one alert type, specific entities such as a host or account, and an expiry date.
3. Fix the cause. If a vulnerability scanner triggers port-scan alerts, allow-list that scanner's address in the suppression rule rather than ignoring the alert type everywhere.
4. Classify alerts as false positive or benign true positive when closing them, which gives you data to tune later.
5. Review regularly. Expired or stale suppression rules should not hide real attacks.

Never suppress by severity alone or tenant-wide. In Sentinel or Defender XDR, automation rules can auto-close known-benign patterns with an audit trail. A broad suppression is the quickest way to create a blind spot an attacker can use.