10.3 Azure Arc and Defender for Servers

Blueprint Focus: Hybrid Servers Are In Scope

SC-500 explicitly measures the ability to extend security controls to hybrid and multicloud servers by using Azure Arc, onboard servers to Defender for Servers (including hybrid/multicloud), configure vulnerability scanning and EDR, and manage agentless scanning. Pure Azure-only thinking is incomplete—many enterprises still run Windows/Linux on VMware, bare metal, AWS, and GCP.

---

Azure Arc-Enabled Servers: The Control-Plane Bridge

Azure Arc-enabled servers install the Connected Machine agent on a non-Azure machine so it appears as an Azure resource (Microsoft.HybridCompute/machines) in a resource group and subscription. Once Arc-connected, you can:

• Apply Azure Policy and Machine Configuration baselines to guest OS settings.
• Inventory machines alongside Azure VMs in Defender for Cloud.
• Enable Defender for Servers protections with a consistent portal experience.
• Use tags, RBAC, Update Manager, and monitoring patterns familiar from Azure VMs.

Onboarding checklist (exam-level)

1. Verify OS support and network egress to Arc endpoints (public endpoints or Azure Arc gateway/private link patterns per design).
2. Create a service principal or use interactive onboarding scripts generated from the portal.
3. Install the Connected Machine agent; confirm the machine shows Connected.
4. Assign resource group, tags, and Azure Policy assignments.
5. Enable Defender for Servers on the subscription (and multicloud connectors if applicable).

Multicloud note: Connecting AWS accounts or GCP projects to Defender for Cloud typically onboards machines as Arc-enabled resources by default, unlocking fuller hybrid functionality.

On-premises without Arc: You can install the Defender for Endpoint agent directly, but documentation is clear that only Plan 1–class functionality is available in that thinner path; Plan 2 fullness for hybrid generally expects Arc onboarding (with some premium vulnerability features still nuanced—prefer Arc on the exam when the stem wants “full Defender for Servers”).

---

Defender for Servers: What It Is

Defender for Servers is the Defender for Cloud workload protection plan for machines. It reduces exposure with posture recommendations and protects against real-time threats. Important modern fact: Defender for Servers no longer relies on the Log Analytics agent / AMA for its core plan features; agentless scanning and Defender for Endpoint integration carry most capabilities.

Benefits you should be able to recite:

• Protect Azure, AWS, GCP, and on-premises Windows/Linux machines.
• Centralize recommendations, alerts, and inventory in Defender for Cloud / Defender XDR experiences.
• Integrate Microsoft Defender for Endpoint (MDE) for EDR.
• Integrate Microsoft Defender Vulnerability Management (MDVM) for software inventory and CVEs.
• Use agentless techniques (Plan 2) for disk snapshots analysis without an endpoint agent.

---

Plan 1 vs Plan 2 (Still Current—Know the Split)

Defender for Servers remains a two-plan product. Default enablement on a subscription is often Plan 2; you can switch plans in Environment settings → Defender plans.

Choosing a plan on the exam

• Stem emphasizes EDR only and cost minimization → Plan 1.
• Stem needs agentless scanning, JIT, FIM, or broad posture for servers → Plan 2.
• Stem needs per-server enable without whole subscription → only Plan 1 supports resource-level enable.

After enablement: a 30-day trial typically starts; MDE extension auto-provisions on supported machines unless you disable automatic provisioning; agentless scanning defaults on with Plan 2.

---

Vulnerability Scanning

Defender for Servers uses Microsoft Defender Vulnerability Management rather than requiring a separate Qualys BYOL story for the integrated experience (legacy Qualys paths may still appear in older materials—prefer MDVM language for 2026 exams).

Two modes:

1. Agent-based vulnerability scanning

   • Uses the Defender for Endpoint sensor presence.
   • Available with Plan 1 or Plan 2.
   • Good for continuous endpoint-context findings.

2. Agentless scanning

   • Plan 2 (also related to Defender CSPM agentless capabilities).
   • Works by analyzing disk snapshots without installing a scanner agent.
   • Surfaces software inventory, CVEs, secrets on disk, and malware indicators.
   • Ideal when agents are restricted, for coverage gaps, or for rapid estate-wide visibility.

Exam trap: “Agentless scanning replaces EDR.” False—agentless is posture/discovery oriented on a schedule; EDR is near real-time detection and response on the endpoint. You often want both under Plan 2.

---

EDR: Defender for Endpoint Integration

When Defender for Servers is on, Microsoft Defender for Endpoint provides:

• Behavioral EDR detections on Windows and Linux.
• Automated investigation and response capabilities in the Defender portal.
• Alert correlation into incidents analysts can triage.
• Sensor-based signals that feed vulnerability and software inventory.

Configuration tasks an SC-500 candidate should recognize:

• Confirm the MDE.Windows / MDE.Linux extension (or equivalent onboarding) is healthy.
• Avoid dual incompatible EDR agents fighting each other.
• Use the unified Defender XDR portal for incidents while still seeing recommendations in Defender for Cloud.
• For Arc machines, ensure connectivity and onboarding status before troubleshooting “missing EDR.”

---

Hybrid and Multicloud Scenarios (Worked Patterns)

Pattern 1: On-premises datacenter

1. Arc-enable Windows/Linux servers.
2. Enable Defender for Servers Plan 2 on the subscription.
3. Verify MDE onboarding + agentless coverage.
4. Apply Machine Configuration baselines (next section) and Azure Policy.
5. Route security alerts to Sentinel (later domain) if SIEM is in scope.

Pattern 2: AWS EC2 / GCP Compute

1. Connect the AWS account or GCP project to Defender for Cloud.
2. Accept Arc onboarding defaults for machines.
3. Enable Servers plan at the connector/environment scope.
4. Use JIT where supported (Azure and AWS called out in plan matrices).
5. Treat recommendations similarly to Azure VMs in the cloud security graph.

Pattern 3: Mixed estate cost control

• Run Plan 2 on production subscriptions that need agentless + JIT.
• Run Plan 1 on dev subscriptions that only need EDR.
• Disable Plan 2 at resource level for exceptions rather than inventing unsupported configurations.

---

Agentless Scanning Operations

Know what agentless scanning does not require: a resident vulnerability agent inside every guest. Know what it does require: platform permissions to snapshot/analyze disks, supported OS/disk types, and Plan 2 (or qualifying CSPM) enablement. Findings appear as recommendations/security graph insights—remediate with patching, configuration changes, or secret rotation workflows.

Secrets scanning is a high-value exam bullet: agentless discovery of credentials on disk is a Plan 2 talking point and pairs with Key Vault migration guidance from earlier chapters.

---

Exam Traps

• Trap: “Arc is only for Kubernetes.” False—Arc-enabled servers are first-class for this objective.
• Trap: “Plan 1 includes JIT and agentless malware scanning.” False—those are Plan 2.
• Trap: “Defender for Servers still requires the Log Analytics agent.” Outdated—MDE + agentless replaced that model for plan features.
• Trap: “Onboard on-prem with MDE only and claim full Plan 2 parity without Arc.” Prefer Arc when the stem wants full hybrid Defender for Servers.
• Trap: Confusing Defender for Servers (machine workload plan) with Defender CSPM (posture management) or Defender for Endpoint standalone licensing outside Cloud—know they integrate but are not identical SKUs.

With hybrid onboarding and Defender plans clear, the last section covers Trusted Launch security features and Azure Machine Configuration for enforcing OS baselines on Azure-managed and Arc-connected servers.