This chapter covers Microsoft Defender for Cloud agents and extensions, which are critical for collecting security telemetry from workloads across Azure, on-premises, and multi-cloud environments. Understanding which agents to deploy, how they work, and how to manage them is essential for the SC-200 exam, as approximately 15-20% of questions in the 'Cloud Security' domain (Objective 3.1) test this knowledge. We will explore the Log Analytics agent, Azure Monitor Agent, Defender for Endpoint integration, vulnerability assessment solutions, and Kubernetes extensions, including deployment methods, configuration, and troubleshooting.
Jump to a section
Think of a modern office building with a sophisticated security system. The building has a central security operations center (SOC) that monitors everything. However, the SOC cannot see inside individual offices or server rooms unless it deploys sensors: motion detectors, door sensors, smoke detectors, and cameras. Each sensor is specifically designed for a certain type of detection — a motion detector cannot detect smoke. These sensors must be physically installed, connected to the network, and configured to report back to the SOC. Some sensors are built into the building's infrastructure (like smoke detectors in the HVAC system), while others are added later (like a standalone camera in a high-value area). The SOC relies on the data from these sensors to detect intrusions, fires, or unauthorized access. If a sensor is missing or misconfigured, the SOC has a blind spot. Similarly, Microsoft Defender for Cloud uses agents and extensions as sensors that collect security telemetry from your Azure, on-premises, and multi-cloud resources. These agents must be deployed, configured, and maintained to provide visibility into vulnerabilities, suspicious activities, and compliance drift. Just as a building's sensor network must be tailored to the specific risks of each room, Defender for Cloud agents are chosen based on the workload type (VM, Kubernetes, SQL) and the security needs (threat detection, vulnerability assessment, compliance monitoring). Without the right agents, Defender for Cloud cannot protect what it cannot see.
What Are Defender for Cloud Agents and Extensions?
Microsoft Defender for Cloud is a Cloud Security Posture Management (CSPM) and Cloud Workload Protection Platform (CWPP) that provides unified security management across hybrid and multi-cloud environments. To deliver threat detection, vulnerability assessment, and compliance monitoring, Defender for Cloud relies on data collected from workloads. This data is gathered by agents and extensions — software components installed on virtual machines, containers, databases, and other resources. Agents run as processes on the operating system, collecting events, logs, and performance data. Extensions are Azure VM extensions that add capabilities such as vulnerability scanning or endpoint detection and response (EDR).
Why Agents Are Necessary
Defender for Cloud can assess the security state of a resource without an agent by analyzing the resource's configuration (e.g., via Azure Resource Manager). However, agent-based monitoring provides deep visibility into runtime behavior, file system changes, network connections, process activity, and security events. For example, detecting a fileless attack or a credential dumping attempt requires an agent that can hook into the OS kernel or monitor ETW (Event Tracing for Windows) events. The SC-200 exam emphasizes that agent-based monitoring is required for many Defender plans, such as Defender for Servers, Defender for SQL on machines, and Defender for Containers.
Types of Agents and Extensions
#### 1. Log Analytics Agent (MMA – Microsoft Monitoring Agent)
Purpose: Collects log data and performance metrics from Windows and Linux machines and sends it to a Log Analytics workspace. Used by Defender for Cloud for security event collection (e.g., Windows Security Events, Syslog).
Deployment: Can be installed via Azure VM extension, Azure Arc, or manually. For Azure VMs, the Log Analytics agent VM extension is typically deployed automatically by Defender for Cloud when the 'Auto Provisioning' setting is enabled.
Data Collected: Windows Event Logs (Security, System, Application), Syslog, IIS logs, custom logs, performance counters, ETW events.
Limitations: Being deprecated in favor of Azure Monitor Agent (AMA). It uses the OMS (Operations Management Suite) pipeline and has a maximum data ingestion rate of 500 MB per day per workspace (soft limit).
Default Timers: Heartbeat is sent every 5 minutes. If no heartbeat for 15 minutes, the agent is considered disconnected.
#### 2. Azure Monitor Agent (AMA)
Purpose: The next-generation agent that replaces Log Analytics agent and Diagnostics extension. It collects data from VMs, Virtual Machine Scale Sets, and Azure Arc-enabled servers and sends it to Azure Monitor, Log Analytics workspaces, and other destinations.
Deployment: Via Azure Policy, VM extension, Azure Arc, or manual installation. Defender for Cloud can auto-deploy AMA when the 'Auto Provisioning' setting is enabled for Azure Monitor Agent.
Data Collected: Similar to Log Analytics agent but with improved performance, better network bandwidth usage, and support for data collection rules (DCRs) that define what data to collect and where to send it.
Key Feature: AMA uses Data Collection Rules (DCRs) to configure data sources and destinations, making it more flexible and scalable.
Default Timers: Heartbeat every 5 minutes. Disconnected status after 15 minutes of missing heartbeats.
Exam Note: SC-200 expects you to know that AMA is the recommended agent for new deployments and that Log Analytics agent is on a deprecation path. However, many existing environments still use MMA.
#### 3. Microsoft Defender for Endpoint (MDE) Integration
Purpose: Provides endpoint detection and response (EDR) capabilities on servers. When MDE is integrated with Defender for Cloud, it enables advanced threat detection, investigation, and response.
Deployment: MDE sensor is installed on the server. For Azure VMs, Defender for Cloud can automatically deploy the MDE extension when the 'Auto Provisioning' setting for MDE is enabled.
How It Works: The MDE sensor collects telemetry at the kernel level (using drivers like wdnisdrv.sys and wdboot.sys on Windows). It sends data to the MDE cloud service, which correlates with Defender for Cloud alerts.
Prerequisites: The Log Analytics agent or AMA must also be installed on the same machine for Defender for Cloud to receive MDE alerts and correlate them with other data.
Default Timers: MDE sensor sends heartbeats every 5 minutes. If no heartbeat for 30 minutes, the sensor is considered inactive.
#### 4. Vulnerability Assessment Solutions
Built-in Qualys VA: Defender for Cloud includes a built-in vulnerability assessment powered by Qualys. It deploys the Qualys agent as a VM extension (Windows or Linux). The agent scans for vulnerabilities and sends results to the Qualys cloud, which then reports back to Defender for Cloud.
Microsoft Defender Vulnerability Management: An alternative VA solution that uses the MDE sensor to assess vulnerabilities without an additional agent. It is part of MDE and is available for servers with MDE integration.
BYOL (Bring Your Own License): You can use your own Qualys or Rapid7 licenses and deploy their agents.
Default Timers: Qualys agent scans every 12 hours by default. The scan can be triggered manually via API or portal.
#### 5. Kubernetes Extensions
- Defender for Containers: Protects Azure Kubernetes Service (AKS), Azure Arc-enabled Kubernetes, and Amazon EKS / Google GKE (via Arc). It uses an agent that runs as a DaemonSet on each node to collect audit logs, security events, and runtime activity. - Components: - Defender profile: A DaemonSet that collects kernel-level events using eBPF (on Linux) or ETW (on Windows) and sends them to the Defender for Cloud backend. - Azure Policy for Kubernetes: An add-on that enforces security policies (e.g., disallowing privileged containers) and reports compliance. - Deployment: Automatically enabled when you enable Defender for Containers on the subscription. The extension is installed via Helm chart or Azure Policy. - Default Timers: Heartbeat every 5 minutes. If no heartbeat for 15 minutes, the node is considered unhealthy.
How Agents Work Internally
When an agent is installed on a VM, it registers with the Log Analytics workspace (or Azure Monitor) and begins collecting data based on configuration. For security events, the Log Analytics agent on Windows subscribes to the Windows Event Log (Security channel) and forwards events that match specified event IDs (e.g., 4624 for logon, 4688 for process creation). The events are formatted in JSON and sent via HTTPS to the workspace ingestion endpoint. The agent uses a certificate for authentication and encrypts data in transit. Data is batched and sent every few seconds to minimize overhead. The agent also caches data locally if the network is unavailable, up to a maximum of 8 GB.
For MDE integration, the MDE sensor communicates directly with the MDE cloud service using a separate channel. It sends rich telemetry including process trees, file operations, network connections, and registry changes. Defender for Cloud then correlates MDE alerts with other data to provide a unified security alert.
Configuration and Verification Commands
- Check Log Analytics agent status on Windows:
Get-Service -Name 'HealthService'- Check Log Analytics agent status on Linux:
sudo /opt/microsoft/omsagent/bin/omsadmin.sh -l- View agent logs on Windows: %ProgramFiles%\Microsoft Monitoring Agent\Agent\Health Service State\
- View agent logs on Linux: /var/opt/microsoft/omsagent/log/
- Deploy Log Analytics agent via Azure CLI:
az vm extension set --resource-group myRG --vm-name myVM --name OmsAgentForLinux --publisher Microsoft.EnterpriseCloud.Monitoring --settings '{"workspaceId":"myWorkspaceId"}' --protected-settings '{"workspaceKey":"myWorkspaceKey"}'- Deploy Azure Monitor Agent via Azure CLI:
az vm extension set --resource-group myRG --vm-name myVM --name AzureMonitorLinuxAgent --publisher Microsoft.Azure.Monitor --settings '{"workspaceId":"myWorkspaceId"}'- Verify MDE sensor status:
Get-MpComputerStatus Look for AMRunningMode = Normal and AMProductVersion.
Interaction with Related Technologies
Defender for Cloud agents work in concert with Azure Policy, Azure Arc, and Azure Monitor. Azure Policy can enforce agent installation via built-in policies like "Deploy Log Analytics agent on Windows VMs" or "Configure Azure Monitor Agent on Azure Arc-enabled servers." Azure Arc extends agent management to on-premises and multi-cloud servers, enabling the same Defender for Cloud protections. Agents also integrate with Azure Sentinel (SIEM) by forwarding security events to the Log Analytics workspace used by Sentinel.
Exam Focus on Defaults and Timers
The SC-200 exam frequently tests default values such as the Qualys scan interval (12 hours), MDE sensor heartbeat (5 minutes), and Log Analytics agent heartbeat (5 minutes). You should also know the deprecation timeline: Log Analytics agent will be retired by August 2024, and AMA is the replacement. The exam may present scenarios asking which agent to use for a new deployment — the answer is Azure Monitor Agent.
Enable Defender for Cloud on Subscription
First, you must enable Microsoft Defender for Cloud on the Azure subscription. This is done via the Azure portal under Defender for Cloud > Environment Settings. You select the subscription and toggle the Defender plans you need (e.g., Defender for Servers, Defender for SQL, Defender for Containers). This activation is a prerequisite for auto-provisioning agents. Without enabling the plan, the auto-provisioning settings are not available. The exam expects you to know that enabling a Defender plan triggers the ability to auto-deploy agents. For example, enabling Defender for Servers Plan 2 allows auto-provisioning of Log Analytics agent (or AMA) and MDE sensor.
Configure Auto-Provisioning for Agents
In Defender for Cloud, go to Environment Settings > (subscription) > Auto provisioning. Here you can enable automatic installation of the Log Analytics agent, Azure Monitor Agent, and MDE sensor. When enabled, Defender for Cloud will deploy the corresponding VM extension on existing and new VMs that match the criteria (e.g., all VMs in the subscription, or VMs in specific resource groups). The auto-provisioning process uses Azure Policy to audit and remediate non-compliant VMs. The exam may test that auto-provisioning for MDE requires the Log Analytics agent or AMA to be installed first.
Deploy Agents Manually or via Policy
If auto-provisioning is not used, you can deploy agents manually through the VM extension blade, Azure CLI, or PowerShell. Alternatively, use Azure Policy to enforce agent installation across the environment. Built-in policies exist for deploying Log Analytics agent, AMA, and MDE. These policies can be assigned at management group, subscription, or resource group scope. The exam often presents a scenario where you need to ensure all VMs have the Log Analytics agent; the correct answer is to assign the built-in policy 'Deploy Log Analytics agent on Windows VMs'.
Verify Agent Installation and Connectivity
After deployment, verify that the agent is running and communicating with the Log Analytics workspace or MDE cloud. For Log Analytics agent, check the service status (HealthService on Windows, omsagent on Linux). For MDE, use Get-MpComputerStatus on Windows. In the Azure portal, you can view the VM's extensions blade to see the provisioning state. The agent's heartbeat should appear in the Log Analytics workspace under Heartbeat table. If the agent fails to connect, check network connectivity to the workspace endpoints (e.g., *.ods.opinsights.azure.com, *.oms.opinsights.azure.com, and for MDE: *.dm.microsoft.com).
Monitor and Troubleshoot Agent Issues
Common issues include agent not sending data, workspace key mismatch, or network restrictions. For Log Analytics agent, examine the agent logs: on Windows, look in %ProgramFiles%\Microsoft Monitoring Agent\Agent\Health Service State\Service.log. On Linux, check /var/opt/microsoft/omsagent/log/omsagent.log. For MDE, use the Microsoft Defender for Endpoint client analyzer tool. Defender for Cloud provides a 'Log Analytics agent health' workbook that shows agent status, missing heartbeats, and configuration errors. The exam may ask about troubleshooting steps, such as checking that the workspace ID and key are correct, or that the VM has outbound HTTPS access to the required endpoints.
Scenario 1: Large Enterprise Migration from MMA to AMA
A financial services company has 10,000 VMs across multiple Azure subscriptions and on-premises servers connected via Azure Arc. They have been using the Log Analytics agent (MMA) for years with Defender for Cloud. However, Microsoft announced the deprecation of MMA, so they need to migrate to Azure Monitor Agent (AMA). The challenge is to perform this migration without interrupting security monitoring. The solution involves deploying AMA alongside MMA initially, using Data Collection Rules (DCRs) to collect security events, and then uninstalling MMA after validation. The company uses Azure Policy to deploy AMA with a DCR that collects the same security events as before. They also enable auto-provisioning for AMA in Defender for Cloud to ensure new VMs get the agent automatically. Performance considerations: AMA uses less CPU and memory than MMA, but the dual-agent period increases resource usage temporarily. The migration is phased over several months to avoid impact. Common misconfiguration: not updating DCRs to include all necessary event IDs, leading to missing security alerts.
Scenario 2: Multi-Cloud Kubernetes Protection
A technology company runs containers on AKS, Amazon EKS, and Google GKE. They enable Defender for Containers on their Azure subscription and connect their EKS and GKE clusters via Azure Arc. Defender for Containers automatically deploys the Defender profile DaemonSet on each node. However, they notice that some nodes on EKS are not showing up as protected. After investigation, they find that the necessary eBPF kernel modules are not available on the custom AMI used for those nodes. The fix is to use a standard Amazon Linux 2 AMI that supports eBPF. They also need to ensure that the cluster has outbound connectivity to the Defender for Cloud endpoints. The exam may test that Defender for Containers requires a supported Kubernetes version (e.g., 1.20+) and that the Defender profile uses eBPF on Linux and ETW on Windows.
Scenario 3: Vulnerability Management with Qualys Agent
A healthcare organization needs to comply with HIPAA and must scan all servers for vulnerabilities. They enable Defender for Servers Plan 2, which includes the built-in Qualys vulnerability assessment. The Qualys agent is auto-deployed to all Azure VMs and Azure Arc-enabled servers. However, they discover that some servers are not being scanned because the Qualys agent fails to communicate with the Qualys cloud due to firewall rules blocking *.qualys.com. They create an allowlist for the required URLs. They also set up a schedule to trigger scans every 12 hours (default). One issue they encounter is that the Qualys agent consumes significant CPU during scans (up to 30% on small VMs), so they schedule scans during off-peak hours. The exam may test that the Qualys agent scans every 12 hours by default and that you can trigger a manual scan via the Defender for Cloud API.
What SC-200 Tests on This Topic (Objective 3.1)
The SC-200 exam tests your ability to deploy, configure, and manage agents and extensions for Defender for Cloud. Specific areas include: - Auto-provisioning settings: Know how to enable auto-provisioning for Log Analytics agent, Azure Monitor Agent, and MDE sensor. Understand that auto-provisioning for MDE requires the Log Analytics agent or AMA to be installed first. - Agent types and their purposes: Differentiate between Log Analytics agent, Azure Monitor Agent, MDE sensor, Qualys agent, and Defender for Containers profile. - Deployment methods: Azure Policy, VM extension, Azure Arc, manual installation. Know the built-in policy names. - Troubleshooting: Common issues like missing heartbeats, workspace key mismatch, network connectivity, and how to check agent logs. - Integration with other services: How agents feed data to Defender for Cloud, Azure Sentinel, and Azure Monitor.
Common Wrong Answers and Why Candidates Choose Them
Confusing Log Analytics agent with Azure Monitor Agent: Candidates often think MMA is the modern agent. The exam expects you to know that AMA is the replacement and that MMA is deprecated. Wrong answer: 'Use Log Analytics agent for new deployments.' Correct: 'Use Azure Monitor Agent.'
Choosing MDE sensor as standalone: Some think MDE sensor alone provides full Defender for Cloud protection. Wrong: 'Install only the MDE sensor to get vulnerability assessment.' Correct: MDE sensor provides EDR, but vulnerability assessment requires the Qualys agent or Microsoft Defender Vulnerability Management (which uses MDE sensor but is a separate plan).
Assuming auto-provisioning covers all scenarios: Candidates may think enabling auto-provisioning automatically deploys agents to all existing VMs instantly. Reality: Auto-provisioning uses Azure Policy, which may take up to 24 hours to remediate non-compliant VMs. The exam may ask about timing.
Mixing up container protection agents: For AKS, some think you need to install a VM extension on each node. Actually, Defender for Containers uses a DaemonSet (Defender profile) that is deployed via Helm chart or Azure Policy. Wrong answer: 'Deploy the Log Analytics agent on each AKS node.'
Specific Numbers and Terms
Qualys scan interval: 12 hours.
Agent heartbeat interval: 5 minutes (both MMA and AMA).
MDE sensor heartbeat: 5 minutes, but considered inactive after 30 minutes.
Log Analytics agent data cache: up to 8 GB.
Required ports: HTTPS (443) to *.ods.opinsights.azure.com, *.oms.opinsights.azure.com, and for MDE: *.dm.microsoft.com.
Built-in policy names: 'Deploy Log Analytics agent on Windows VMs', 'Configure Azure Monitor Agent on Windows VMs', 'Deploy Microsoft Defender for Endpoint on Windows VMs'.
Edge Cases and Exceptions
Azure Arc-enabled servers: Agents can be deployed to on-premises and multi-cloud servers via Azure Arc. The same auto-provisioning settings apply.
Windows vs. Linux differences: The Log Analytics agent on Linux uses syslog instead of Event Log. MDE sensor on Linux uses eBPF for kernel monitoring.
Virtual Machine Scale Sets: Agents can be deployed via VM extension on VMSS instances, but auto-provisioning may not apply to all instances immediately.
Network restrictions: If VMs are in a private network with no internet access, you need a Log Analytics gateway or use Azure Monitor Private Link Scope (AMPLS) to connect agents to the workspace.
How to Eliminate Wrong Answers
Use the underlying mechanism: For example, if a question asks which agent provides vulnerability assessment, eliminate MDE sensor if the scenario does not mention Microsoft Defender Vulnerability Management. If the question asks about collecting Windows Security Events, eliminate MDE sensor because it collects endpoint telemetry but not raw security events; that requires Log Analytics agent or AMA. If the question mentions a Linux server, ensure the agent supports Linux (all major agents do, but some extensions are OS-specific).
The Log Analytics agent (MMA) is deprecated; use Azure Monitor Agent (AMA) for new deployments.
Auto-provisioning in Defender for Cloud uses Azure Policy to deploy agents; it may take up to 24 hours to remediate all VMs.
MDE sensor provides EDR but does not collect Windows Security Events; the Log Analytics agent or AMA is still needed for those.
Built-in Qualys vulnerability assessment scans every 12 hours by default.
Defender for Containers uses a DaemonSet (Defender profile) that monitors kernel events via eBPF (Linux) or ETW (Windows).
All agents send heartbeats every 5 minutes; missing heartbeats for 15 minutes indicates a disconnected agent.
For on-premises or multi-cloud servers, use Azure Arc to enable agent deployment and Defender for Cloud protection.
Network connectivity to *.ods.opinsights.azure.com and *.oms.opinsights.azure.com (for MMA/AMA) and *.dm.microsoft.com (for MDE) is required.
You can verify MDE sensor status with Get-MpComputerStatus (Windows) or mdatp health (Linux).
When migrating from MMA to AMA, run both agents in parallel to avoid monitoring gaps.
These come up on the exam all the time. Here's how to tell them apart.
Log Analytics Agent (MMA)
Legacy agent, deprecated after August 2024
Uses OMS pipeline and workspace configuration
Maximum data ingestion of 500 MB/day per workspace (soft limit)
No support for Data Collection Rules; configuration is workspace-based
Heartbeat every 5 minutes; disconnected after 15 minutes
Azure Monitor Agent (AMA)
Current recommended agent, replaces MMA
Uses Data Collection Rules (DCRs) for flexible data routing
Higher throughput and lower resource usage
Supports multiple destinations (Log Analytics, Azure Monitor, Event Hubs)
Heartbeat every 5 minutes; disconnected after 15 minutes
Mistake
The Log Analytics agent is the only agent needed for Defender for Cloud.
Correct
While the Log Analytics agent collects security events and performance data, advanced protections like EDR require the MDE sensor, and vulnerability assessment requires the Qualys agent or Microsoft Defender Vulnerability Management. Depending on the Defender plan, you may need multiple agents.
Mistake
Azure Monitor Agent (AMA) is just a renamed Log Analytics agent.
Correct
AMA is a completely new agent built on a different technology stack. It uses Data Collection Rules (DCRs) for configuration, supports multiple destinations, and has better performance and lower resource usage. It is not a direct upgrade of MMA; you must migrate by deploying AMA and then removing MMA.
Mistake
Auto-provisioning installs agents immediately on all VMs.
Correct
Auto-provisioning uses Azure Policy assignments that are evaluated and remediated periodically. It can take up to 24 hours for all VMs to receive the agent, especially in large environments. You can speed up remediation by triggering a policy remediation task manually.
Mistake
The MDE sensor can replace the Log Analytics agent for security event collection.
Correct
The MDE sensor collects endpoint detection telemetry (processes, network connections, file events) but does not collect Windows Security Events (like 4624, 4688) or syslog. Defender for Cloud relies on the Log Analytics agent or AMA for those events. Both agents are needed for full visibility.
Mistake
Defender for Containers requires the Log Analytics agent on each node.
Correct
Defender for Containers uses a dedicated DaemonSet (Defender profile) that runs as a container on each node. It does not require the Log Analytics agent, though you can optionally deploy it for additional log collection. The Defender profile uses eBPF on Linux and ETW on Windows for kernel-level monitoring.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The Log Analytics agent (MMA) is the legacy agent being deprecated after August 2024. Azure Monitor Agent (AMA) is the replacement that offers better performance, lower resource usage, and flexible configuration via Data Collection Rules (DCRs). AMA can send data to multiple destinations, while MMA only sends to a single Log Analytics workspace. For new deployments, always use AMA. For existing MMA deployments, plan to migrate to AMA.
Yes, for full protection. The Log Analytics agent (or AMA) collects security events and performance data needed for Defender for Cloud's security alerts and compliance monitoring. The MDE sensor provides endpoint detection and response (EDR) capabilities. Defender for Cloud requires both to correlate alerts and provide a unified view. Auto-provisioning in Defender for Cloud will deploy both if you enable the appropriate settings.
On-premises servers must first be onboarded to Azure Arc. Once Azure Arc is enabled, you can deploy agents using the same methods as Azure VMs: auto-provisioning in Defender for Cloud, Azure Policy, or manual extension installation. Azure Arc makes on-premises servers appear as Azure resources, allowing Defender for Cloud to manage them identically.
First, verify the agent service is running (HealthService on Windows, omsagent on Linux). Check network connectivity to the required endpoints: *.ods.opinsights.azure.com and *.oms.opinsights.azure.com (for MMA/AMA) and *.dm.microsoft.com (for MDE). Ensure the workspace ID and key are correct. Review agent logs: on Windows, look in %ProgramFiles%\Microsoft Monitoring Agent\Agent\Health Service State\Service.log; on Linux, check /var/opt/microsoft/omsagent/log/. Also check if the VM has a firewall or proxy blocking outbound HTTPS (port 443).
Yes, you can get basic CSPM (Cloud Security Posture Management) without agents by assessing your Azure resources' configurations via Azure Resource Manager. However, for advanced protections like threat detection, vulnerability assessment, and just-in-time VM access, you need agents. Agentless scanning for VMs is now available in preview, but for full runtime protection, agents are still required.
The built-in Qualys agent scans every 12 hours by default. You can also trigger a manual scan via the Defender for Cloud API or by using the 'Scan' button in the portal for a specific VM. The scan results are updated in Defender for Cloud within a few hours.
Both the Log Analytics agent and Azure Monitor Agent send a heartbeat every 5 minutes. If no heartbeat is received for 15 minutes, the agent is considered disconnected. The MDE sensor also sends a heartbeat every 5 minutes, but it is considered inactive after 30 minutes of missing heartbeats.
You've just covered Defender for Cloud Agents and Extensions — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.
Done with this chapter?