Onboard servers to Defender for Servers in Defender for Cloud, including hybrid and multicloud scenarios (SC-500 Exam Prep)

This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Secure compute (20–25%)
   --> Implement security for servers and virtual machines (VMs)
      --> Onboard servers to Defender for Servers in Defender for Cloud, including hybrid and multicloud scenarios


Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Introduction

Secure compute (20–25%) → Implement security for servers and virtual machines (VMs)

This topic focuses on how to onboard servers to Microsoft Defender for Servers through Microsoft Defender for Cloud, including servers running in:

  • Microsoft Azure
  • On-premises datacenters
  • Amazon Web Services (AWS)
  • Google Cloud Platform (GCP)
  • Other supported hybrid environments

The goal is to extend security posture management, vulnerability assessment, endpoint detection and response, and other workload protection capabilities beyond Azure.


1. What Is Microsoft Defender for Servers?

Microsoft Defender for Servers is a cloud workload protection plan in Microsoft Defender for Cloud that helps protect Windows and Linux servers and virtual machines.

It provides capabilities such as:

  • Security recommendations
  • Vulnerability assessment
  • Microsoft Defender for Endpoint integration
  • Endpoint detection and response (EDR)
  • Threat detection and investigation
  • File Integrity Monitoring
  • Agentless software inventory
  • Agentless secret scanning
  • Agentless malware scanning
  • Security configuration assessment
  • Regulatory compliance reporting
  • Just-in-time VM access in supported scenarios
  • Security posture visibility across hybrid and multicloud environments

Defender for Servers can protect servers running in Azure, on-premises environments, AWS, and GCP.

However, Defender for Servers does not replace operating-system hardening, patch management, identity security, network segmentation, or application security. It extends Microsoft’s security management and protection capabilities to supported servers.


2. Understanding the Main Components

Several services work together when protecting non-Azure servers.

Microsoft Defender for Cloud

Defender for Cloud provides:

  • Cloud security posture management
  • Security recommendations
  • Regulatory compliance dashboards
  • Workload protection plans
  • Security alerts
  • Centralized security visibility

Defender for Cloud is the primary management experience where you enable Defender for Servers and review recommendations and alerts.

Azure Arc-Enabled Servers

Azure Arc-enabled servers allows a physical or virtual server outside Azure to become an Azure resource.

After onboarding:

  • The server receives an Azure resource ID.
  • It can be placed in an Azure resource group.
  • Azure RBAC can be applied.
  • Azure Policy can evaluate the resource.
  • Azure extensions can be deployed.
  • Defender for Cloud can use the server as part of its protected server inventory.

Azure Arc provides the management connection between the external server and Azure.

Azure Connected Machine Agent

The Azure Connected Machine agent is installed on the server.

The agent:

  • Establishes the server’s relationship with Azure.
  • Communicates outbound to Azure.
  • Provides the Azure resource identity.
  • Enables supported extensions.
  • Allows Azure services to evaluate and manage the connected machine.
  • Helps Defender for Cloud deploy required security components.

Azure does not generally initiate inbound management connections into the customer’s network. The agent establishes outbound communication to Azure over encrypted connections.

Microsoft Defender for Endpoint

Defender for Servers integrates with Microsoft Defender for Endpoint to provide endpoint protection and EDR capabilities.

Defender for Endpoint can provide:

  • Antivirus and antimalware protection
  • Attack surface reduction
  • Threat detection
  • Behavioral analysis
  • Threat hunting
  • Automated investigation and response
  • Endpoint security alerts

Defender for Servers Plan 1 and Plan 2 provide Defender for Endpoint capabilities through the Defender for Cloud integration.


3. Defender for Servers Plan 1 and Plan 2

Defender for Servers provides two primary paid plans.

Plan 1

Plan 1 is the entry-level plan and focuses primarily on endpoint protection through Microsoft Defender for Endpoint integration.

Important capabilities include:

  • Microsoft Defender for Endpoint integration
  • Endpoint detection and response
  • Antivirus and antimalware capabilities
  • Threat detection and investigation
  • Attack surface reduction
  • Security recommendations

Plan 2

Plan 2 includes the capabilities of Plan 1 and adds advanced server protection and assessment capabilities.

Depending on the supported server type and scenario, Plan 2 can provide capabilities such as:

  • File Integrity Monitoring
  • Just-in-time VM access
  • Agentless scanning
  • Advanced vulnerability assessment
  • Agentless software inventory
  • Agentless secret scanning
  • Agentless malware scanning
  • Additional security posture assessments
  • System updates and patch-management capabilities

The exact feature availability depends on the operating system, cloud environment, onboarding method, and current Defender for Cloud support matrix.

Exam Tip

Do not assume that every Defender for Servers feature is available for every server type.

For example:

  • Some Azure VM features are not available for Arc-enabled servers.
  • Some features available for Azure VMs are not available for AWS or GCP machines.
  • Some Plan 2 capabilities require Azure Arc.
  • Direct Defender for Endpoint onboarding does not provide the complete set of Defender for Servers capabilities.

4. Azure VMs Versus Hybrid and Multicloud Servers

Azure Virtual Machines

Azure VMs are already Azure resources. Defender for Cloud can associate them directly with the subscription and resource group where they exist.

The onboarding process generally involves:

  1. Enable Defender for Servers for the subscription.
  2. Select Plan 1 or Plan 2.
  3. Configure the required agent or agentless capabilities.
  4. Verify that the VM is protected.

On-Premises Servers

On-premises servers should generally be onboarded as Azure Arc-enabled servers.

The server remains physically in the organization’s datacenter, but Azure represents it as a resource for management and security purposes.

AWS and GCP Servers

AWS and GCP environments can be connected to Defender for Cloud through native cloud connectors.

For complete server protection, AWS and GCP machines are generally onboarded as Azure Arc-enabled machines. Microsoft recommends onboarding AWS and GCP machines as Arc-enabled servers to take advantage of the full Defender for Servers capability set.


5. High-Level Onboarding Architecture

The typical hybrid or multicloud architecture is:

On-premises / AWS / GCP Server
|
| Azure Connected Machine agent
|
v
Azure Arc-enabled server
|
v
Microsoft Defender for Cloud
|
+--> Defender for Servers
|
+--> Microsoft Defender for Endpoint
|
+--> Vulnerability Assessment
|
+--> Azure Policy / Machine Configuration
|
+--> Azure Monitor / Log Analytics
|
+--> Microsoft Sentinel

The Azure Arc agent provides the connection, while Defender for Cloud provides the security management and protection experience.


6. Planning Before Onboarding

Before onboarding servers, plan the following.

Subscription and Resource Group Design

Decide:

  • Which Azure subscription will contain the connected servers
  • Which resource groups will be used
  • Whether servers should be grouped by environment, business unit, application, or ownership
  • Which administrators need access
  • Whether Tier 0 or highly sensitive servers require a dedicated subscription or resource group

Resource groups can be used to apply access control and organize servers according to operational responsibility.

Azure Region and Data Residency

The Azure region selected for Arc-enabled servers affects where resource metadata and certain security-related data are processed or stored.

Before onboarding, evaluate:

  • Regulatory requirements
  • Data residency requirements
  • Internal security policies
  • Cross-border data transfer restrictions
  • Log storage locations
  • Defender for Cloud and Defender for Endpoint data-handling requirements

CSPM capabilities are generally agentless, while workload protection capabilities can require agents and extensions. Therefore, data residency planning must consider both the Azure service and the agents deployed to the server.

Supported Operating Systems

Verify that the server’s:

  • Operating system
  • Version
  • Architecture
  • Installed dependencies
  • Network configuration

are supported by Azure Arc and Defender for Servers.

An unsupported operating system can prevent successful onboarding or limit available protection features.

Network Connectivity

The server must be able to communicate outbound to required Azure endpoints.

Review:

  • Firewall rules
  • Proxy configuration
  • DNS resolution
  • TLS inspection
  • Outbound port 443 access
  • Private endpoint requirements
  • AWS or GCP connector-specific endpoints

Most Arc communication is outbound and encrypted using TLS. Extensions may require additional endpoints beyond those required by the core Arc agent.


7. Required Permissions and Identity

Azure Permissions

The person or automation process performing onboarding needs sufficient permissions to:

  • Register or use the required resource providers
  • Create Azure Arc resources
  • Place resources in the target resource group
  • Enable Defender for Cloud plans
  • Configure extensions or related services

Use the principle of least privilege. Avoid granting subscription-wide Owner access when a narrower role is sufficient.

Onboarding Credentials

Onboarding credentials must be protected because they can be used to create or connect resources in Azure.

Best practices include:

  • Use a dedicated onboarding identity.
  • Use least-privilege permissions.
  • Avoid embedding credentials in scripts or source code.
  • Protect service principal secrets.
  • Rotate credentials regularly.
  • Prefer short-lived or federated authentication where supported.
  • Remove temporary onboarding permissions after deployment.
  • Store secrets in a secure secret-management service.

Local Server Permissions

Installing the Azure Connected Machine agent generally requires administrative privileges on the server.

After installation, the agent’s service model is designed to avoid requiring a permanently privileged domain service account. Microsoft documents different service-account behavior for Windows and Linux, and domain-joined service accounts or alternate user identities are not supported for the agent service model.


8. Onboarding On-Premises Servers

A typical on-premises onboarding process is:

Step 1: Prepare the Environment

Confirm:

  • Azure subscription availability
  • Target resource group
  • Azure region
  • Supported operating system
  • Required outbound connectivity
  • Appropriate Azure permissions
  • Defender for Cloud configuration

Step 2: Install the Azure Connected Machine Agent

Install the Azure Connected Machine agent on the server.

The agent can be installed:

  • Manually
  • Through scripted deployment
  • Through configuration-management tools
  • At scale using supported automation methods

Step 3: Authenticate the Machine

Use an approved onboarding method, such as:

  • Interactive authentication
  • Service principal authentication
  • Other supported automated authentication methods

The authentication method should be selected based on the scale of deployment and the organization’s identity-management standards.

Step 4: Connect the Server to Azure

After successful authentication, the server appears as an Azure Arc-enabled server.

It receives:

  • An Azure resource ID
  • A resource group association
  • A location
  • A managed identity
  • A connection status

Step 5: Enable Defender for Servers

Enable Defender for Servers for the subscription or appropriate scope.

Select Plan 1 or Plan 2 based on the required capabilities and licensing needs.

Step 6: Verify Protection

Verify:

  • The server appears in Defender for Cloud.
  • The Arc connection is healthy.
  • Defender for Endpoint is onboarded where required.
  • Vulnerability assessment is active.
  • Security recommendations are being generated.
  • Security alerts can be viewed.
  • Required extensions are provisioned successfully.

Microsoft provides a workflow for connecting on-premises machines to Defender for Cloud through Azure Arc and verifying the Defender for Endpoint integration.


9. Onboarding AWS Servers

AWS servers are generally connected through a native AWS connector in Defender for Cloud.

The process typically includes:

  1. Connect the AWS account to Defender for Cloud.
  2. Configure the required AWS IAM permissions.
  3. Select the subscriptions and regions to protect.
  4. Enable the appropriate Defender for Cloud plans.
  5. Configure Azure Arc onboarding for supported EC2 instances.
  6. Install or provision the Azure Connected Machine agent.
  7. Enable Defender for Servers.
  8. Verify security coverage.

AWS Systems Manager Agent can be used to help provision the Azure Arc agent automatically on supported AWS EC2 instances.

For full Defender for Servers functionality, AWS machines generally require:

  • Azure Arc agent
  • Microsoft Defender for Endpoint integration
  • Vulnerability assessment
  • Required agentless scanning capabilities
  • Appropriate AWS and Azure permissions
  • Required outbound network access

AWS and GCP server support is not identical. For example, some network-based security alerts and just-in-time access capabilities have different availability depending on the cloud platform.


10. Onboarding GCP Servers

GCP servers are connected through a native GCP connector in Defender for Cloud.

The process typically includes:

  1. Connect the GCP project to Defender for Cloud.
  2. Configure the required GCP permissions.
  3. Select the projects and resources to protect.
  4. Enable the required Defender for Cloud plans.
  5. Configure Azure Arc onboarding.
  6. Install or provision the Azure Connected Machine agent.
  7. Enable Defender for Servers.
  8. Verify that the server appears in Defender for Cloud.

The GCP OS Config agent can be used to help provision the Azure Arc agent automatically on supported Google Compute Engine instances.

Required components can include:

  • Azure Arc agent
  • Microsoft Defender for Endpoint
  • Vulnerability assessment
  • Agentless scanning
  • GCP IAM permissions
  • Required outbound network connectivity

GCP and AWS machines can both receive Defender for Servers protection, but feature support must be checked against the current support matrix.


11. Direct Defender for Endpoint Onboarding Versus Azure Arc

Some non-Azure servers can be onboarded directly to Microsoft Defender for Endpoint.

However, direct onboarding is not equivalent to onboarding through Azure Arc.

Direct Defender for Endpoint onboarding can provide endpoint protection and EDR capabilities, but some Defender for Servers Plan 2 capabilities still require Azure Arc.

Microsoft documents that directly onboarded servers receive Plan 1 capabilities and selected additional capabilities, while some Plan 2 features require Arc-enabled onboarding.

Use Azure Arc When You Need:

  • Azure resource representation
  • Azure RBAC
  • Azure Policy
  • Machine Configuration
  • Azure extensions
  • Defender for Servers capabilities that require Arc
  • Centralized hybrid and multicloud inventory
  • Azure management and governance
  • Integration with other Azure services

Use Direct Defender for Endpoint Onboarding When:

  • Endpoint protection is the primary requirement
  • Azure Arc is not appropriate for the scenario
  • The required Defender for Servers features do not depend on Arc
  • The organization wants direct EDR onboarding

For exam questions, carefully distinguish between Defender for Endpoint onboarding and Defender for Servers onboarding through Azure Arc.


12. Vulnerability Assessment

Defender for Servers can provide vulnerability assessment through supported capabilities, including:

  • Microsoft Defender Vulnerability Management
  • Integrated vulnerability assessment solutions
  • Agentless vulnerability scanning in supported scenarios

Vulnerability assessment helps identify:

  • Missing security updates
  • Vulnerable software
  • Unsupported software
  • Misconfigured applications
  • Security weaknesses that attackers could exploit

The assessment method depends on the server type, operating system, Defender for Servers plan, and current feature support.

Agent-Based Assessment

An agent-based solution runs on the server and can collect detailed information about software and vulnerabilities.

Agentless Assessment

Agentless assessment can analyze supported resources without installing a traditional scanning agent on the operating system.

Agentless capabilities may be available for:

  • Software inventory
  • Vulnerability assessment
  • Secret scanning
  • Malware scanning
  • Other supported assessments

Agentless features are not universally available across all operating systems and cloud environments.


13. Microsoft Defender for Endpoint Integration

Defender for Servers uses Microsoft Defender for Endpoint to provide endpoint protection.

The integration can provide:

  • Endpoint detection and response
  • Antivirus
  • Threat intelligence
  • Behavioral detections
  • Automated investigation and response
  • Threat hunting
  • Attack surface reduction
  • Security alerts

When Defender for Endpoint detects a threat, the alert can be surfaced in Defender for Cloud. Security teams can pivot to the Defender for Endpoint experience for deeper investigation.

This integration is particularly useful when an organization wants one endpoint security platform across Azure, on-premises, AWS, and GCP servers.


14. Security Recommendations and Compliance

After servers are connected, Defender for Cloud can evaluate their security posture.

Recommendations can address:

  • Missing operating-system updates
  • Weak security configurations
  • Missing endpoint protection
  • Vulnerable software
  • Unprotected servers
  • Insecure network configurations
  • Missing disk encryption
  • File integrity concerns
  • Security baseline deviations

Defender for Cloud can also provide regulatory compliance dashboards and reports.

The compliance dashboard does not automatically mean that the organization is compliant. It provides an assessment of how resources compare with selected regulatory standards and security controls.


15. Azure Policy and Machine Configuration

Azure Policy can be used to govern Arc-enabled servers.

Examples include:

  • Require specific tags.
  • Restrict allowed resource locations.
  • Audit whether servers are connected.
  • Audit security configuration.
  • Enforce configuration requirements.
  • Deploy required extensions.
  • Identify noncompliant machines.

Azure Machine Configuration, formerly associated with guest configuration, can evaluate and enforce settings inside supported servers.

Examples include:

  • Password policy settings
  • Security baseline settings
  • Required services
  • Registry settings
  • File permissions
  • Operating-system configuration
  • Compliance with organizational standards

Azure Policy evaluates the Azure resource and can use machine configuration to assess settings inside the operating system.

Important Security Consideration

Extensions can perform powerful operations on a connected machine. Therefore:

  • Restrict who can deploy extensions.
  • Use RBAC carefully.
  • Limit extension permissions.
  • Review inherited policy assignments.
  • Use local agent security controls where stronger restrictions are required.

For highly sensitive or Tier 0 servers, Microsoft recommends stronger isolation, dedicated subscriptions, limited persistent administration, and careful review of inherited access and policies.


16. Network Requirements

The Azure Connected Machine agent normally communicates outbound to Azure.

Common requirements include:

  • DNS resolution
  • Outbound HTTPS connectivity
  • Port 443 access
  • Access to required Azure endpoints
  • Proxy configuration when applicable
  • Trusted TLS certificates
  • Firewall allowlists

For AWS and GCP deployments, additional cloud-specific endpoints may be required.

TLS Inspection

TLS inspection can work if:

  • The server trusts the inspection certificate.
  • The inspection device does not interfere with the connection.
  • Required extensions do not use certificate pinning.

Some extensions may use certificate pinning, which can cause failures when traffic is intercepted or modified.

Private Endpoints

Private endpoints can be used for supported scenarios to restrict traffic paths.

However:

  • Not every Arc endpoint supports private endpoints.
  • Microsoft Entra ID may still require firewall exceptions.
  • SSH and Windows Admin Center access over a private endpoint are not automatically supported by the Arc connection.
  • Extension-specific connectivity requirements may remain.

17. Monitoring and Logging

Defender for Servers should be monitored after onboarding.

Check:

  • Arc agent connection status
  • Last heartbeat
  • Defender for Endpoint health
  • Extension provisioning status
  • Vulnerability assessment status
  • Policy compliance
  • Security recommendations
  • Security alerts
  • Log ingestion
  • Data collection configuration

Azure Monitor and Log Analytics can be used for supported monitoring and logging scenarios.

Microsoft Sentinel can provide centralized security information and event management across:

  • Azure
  • On-premises servers
  • AWS
  • GCP
  • Microsoft Defender for Cloud
  • Microsoft Defender for Endpoint
  • Other security products

Defender for Cloud integrates with Microsoft Sentinel so that security alerts can be centralized for investigation, correlation, and automated response.


18. Common Onboarding Problems

Problem 1: The Server Does Not Appear in Azure

Possible causes include:

  • Invalid onboarding credentials
  • Insufficient Azure permissions
  • Failed agent installation
  • Unsupported operating system
  • Blocked outbound connectivity
  • Incorrect subscription or resource group
  • Failed authentication

Problem 2: The Arc Agent Is Connected but Defender for Servers Is Not Active

Possible causes include:

  • Defender for Servers is not enabled for the correct subscription.
  • The server is associated with a different subscription.
  • The required plan has not been selected.
  • The Defender for Endpoint extension failed.
  • The server is not supported for the selected capability.
  • Licensing or provisioning has not completed.

Problem 3: Defender for Endpoint Is Not Onboarded

Check:

  • Extension provisioning status
  • Operating-system support
  • Outbound connectivity
  • Proxy and TLS inspection
  • Defender for Endpoint licensing
  • Conflicting endpoint security software
  • Local administrative permissions

Problem 4: Vulnerability Data Is Missing

Possible causes include:

  • Vulnerability assessment is not enabled.
  • The required agent or extension failed.
  • The server is not supported.
  • The assessment has not completed its initial scan.
  • Network access is blocked.
  • The selected Defender for Servers plan does not include the required capability.

Problem 5: Policy Reports Noncompliance

Possible causes include:

  • The server does not meet the assigned configuration.
  • The policy assignment is inherited.
  • The machine configuration extension is missing.
  • The policy has not evaluated recently.
  • The server is disconnected.
  • The policy definition does not support the operating system.

19. Best Practices

Use a Standardized Onboarding Process

Create a repeatable process that includes:

  1. Inventory the server.
  2. Confirm support.
  3. Assign the target subscription and resource group.
  4. Validate network access.
  5. Use least-privilege onboarding credentials.
  6. Install the Arc agent.
  7. Enable Defender for Servers.
  8. Verify protection.
  9. Apply policies and security baselines.
  10. Monitor the server continuously.

Onboard at Scale

For large environments, use:

  • Automation
  • Infrastructure as code
  • Configuration-management tools
  • AWS Systems Manager
  • GCP OS Config
  • Standardized deployment scripts
  • Centralized policy assignments

Protect Onboarding Credentials

Do not store service principal secrets in:

  • Source code
  • Public repositories
  • Unencrypted scripts
  • Shared documents
  • Local administrator profiles

Restrict Administrative Access

Use:

  • Azure RBAC
  • Privileged Identity Management
  • Just-in-time access where supported
  • Separate administrator roles
  • Dedicated subscriptions for sensitive resources
  • Resource-group-level permissions

Monitor Agent and Extension Health

A connected server is not necessarily a fully protected server. Confirm that the required security extensions and Defender for Endpoint components are installed and healthy.

Validate Feature Availability

Always verify whether a feature is supported for:

  • Azure VMs
  • Arc-enabled servers
  • AWS machines
  • GCP machines
  • Windows
  • Linux
  • Plan 1
  • Plan 2

20. Key Exam Takeaways

Remember these points:

  1. Defender for Servers protects supported Windows and Linux servers across Azure, on-premises, AWS, and GCP.
  2. Azure Arc is the primary connection method for non-Azure servers when full Defender for Servers capabilities are required.
  3. The Azure Connected Machine agent establishes the server’s relationship with Azure.
  4. Azure Arc-enabled servers become Azure resources with resource IDs and resource-group placement.
  5. Defender for Endpoint provides core EDR capabilities.
  6. Plan 2 includes additional advanced capabilities, but feature availability varies by environment.
  7. Direct Defender for Endpoint onboarding is not equivalent to full Azure Arc onboarding.
  8. AWS and GCP connectors provide cloud-level visibility, while Arc enables deeper server-level protection.
  9. Azure Policy and Machine Configuration help govern and assess server configuration.
  10. Outbound network connectivity and endpoint allowlisting are essential.
  11. Onboarding credentials must be protected and assigned least-privilege permissions.
  12. A connected Arc server must still be monitored for agent, extension, Defender, and policy health.

Practice Exam Questions

Question 1

An organization has 200 Windows servers running in an on-premises datacenter. The organization wants to manage them through Azure and use Defender for Servers capabilities that require Azure resource representation.

What should the organization do?

A. Install only the Microsoft Defender Antivirus client on each server.
B. Onboard the servers as Azure Arc-enabled servers and enable Defender for Servers.
C. Move all servers into Azure Virtual Machines.
D. Connect the servers only to Microsoft Sentinel.

Answer: B

Explanation: Azure Arc-enabled servers allows on-premises servers to become Azure resources. Defender for Servers can then provide security posture and workload protection capabilities without requiring the servers to be moved into Azure.


Question 2

A company wants to protect AWS EC2 instances with Defender for Servers and obtain the broadest supported set of server protection capabilities.

Which component is generally required for the EC2 instances?

A. Azure Bastion
B. Azure Application Gateway
C. Azure VPN Gateway
D. Azure Arc-enabled servers

Answer: D

Explanation: AWS machines should generally be onboarded as Azure Arc-enabled servers to obtain the full set of supported Defender for Servers capabilities. Azure Arc provides the connection between the AWS machine and Azure.


Question 3

Which component establishes the relationship between a non-Azure server and Azure?

A. Azure Connected Machine agent
B. Microsoft Sentinel connector
C. Azure Firewall
D. Azure Resource Graph query

Answer: A

Explanation: The Azure Connected Machine agent is installed on the non-Azure server and establishes its connection to Azure Arc.


Question 4

An administrator directly onboards an on-premises server to Microsoft Defender for Endpoint. The administrator expects every Defender for Servers Plan 2 capability to become available.

Is this expectation correct?

A. Yes. Direct Defender for Endpoint onboarding always provides every Defender for Servers feature.
B. Yes, but only if the server is running Windows Server.
C. No. Some Defender for Servers capabilities still require Azure Arc onboarding.
D. No. Defender for Endpoint cannot protect on-premises servers.

Answer: C

Explanation: Direct Defender for Endpoint onboarding can provide endpoint protection and EDR, but some Defender for Servers Plan 2 capabilities require Azure Arc-enabled onboarding.


Question 5

An organization wants to evaluate security settings inside the operating system of Arc-enabled servers.

Which capability is most appropriate?

A. Azure Resource Graph only
B. Azure Machine Configuration
C. Azure DNS
D. Azure Front Door

Answer: B

Explanation: Azure Machine Configuration can evaluate and, in supported scenarios, enforce settings inside the operating system of Arc-enabled servers.


Question 6

Which network requirement is most commonly necessary for the Azure Connected Machine agent?

A. Inbound TCP port 3389 from Azure
B. Inbound TCP port 22 from Azure
C. Outbound HTTPS connectivity to required Azure endpoints
D. A public IP address assigned to every server

Answer: C

Explanation: Arc communication is generally outbound and encrypted over HTTPS. The server does not normally require inbound RDP or SSH access from Azure for the Arc connection.


Question 7

An organization connects its GCP project to Defender for Cloud. It wants server-level protection for supported Google Compute Engine instances.

What should it plan to deploy?

A. Azure Arc agent and the required Defender for Servers components
B. Azure Bastion on every GCP VM
C. Azure Application Gateway in the GCP project
D. Azure VPN Gateway on every GCP VM

Answer: A

Explanation: The Azure Arc agent connects supported GCP machines to Azure and allows Defender for Cloud to deploy the extensions and components required for Defender for Servers.


Question 8

Which statement best describes the difference between Defender for Cloud CSPM and Defender for Servers workload protection?

A. CSPM always requires the Microsoft Defender for Endpoint agent.
B. Defender for Servers is only available for Azure VMs.
C. CSPM evaluates security posture, while Defender for Servers provides server workload protection and may require agents or extensions.
D. CSPM and Defender for Servers are identical capabilities with different names.

Answer: C

Explanation: CSPM focuses on security posture and can be agentless in multicloud scenarios. Defender for Servers provides workload protection capabilities that can require Azure Arc, Defender for Endpoint, vulnerability assessment, or other components.


Question 9

A server appears as connected in Azure Arc, but no Defender for Endpoint alerts or vulnerability information are appearing.

What should the administrator check first?

A. Whether Azure Front Door is enabled
B. Whether Defender for Servers is enabled for the correct subscription and the required extensions are healthy
C. Whether the server has an Azure public IP address
D. Whether Azure Bastion is deployed

Answer: B

Explanation: An Arc connection alone does not guarantee that Defender for Servers protection is active. The administrator should verify the Defender for Servers plan, subscription association, Defender for Endpoint provisioning, vulnerability assessment, and extension health.


Question 10

An organization is onboarding highly sensitive Tier 0 servers through Azure Arc. Which approach best follows security best practices?

A. Use a dedicated subscription, minimize persistent administrative access, and review inherited policies and permissions.
B. Grant all administrators the Owner role at the tenant root scope.
C. Allow unrestricted extension deployment by all resource users.
D. Store onboarding credentials in a shared script repository.

Answer: A

Explanation: Highly sensitive servers should be isolated where practical, managed using least privilege, and protected from unnecessary administrative access and uncontrolled extension deployment. Onboarding credentials should also be securely managed.


Go to the SC-500 Exam Prep Hub main page

Leave a Reply