Extend security controls to hybrid and multicloud servers by using Azure Arc (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)
      --> Extend security controls to hybrid and multicloud servers by using Azure Arc


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.

Overview

Organizations frequently operate servers in several locations:

  • Azure
  • On-premises datacenters
  • Branch offices
  • Edge locations
  • Other cloud providers, such as Amazon Web Services or Google Cloud
  • Virtualized environments such as VMware or Hyper-V

Managing security consistently across these environments can be difficult. Each platform may have different management tools, identity systems, monitoring solutions, patching processes, and security configurations.

Azure Arc-enabled servers extends Azure management, governance, monitoring, and security capabilities to physical servers and virtual machines running outside Azure. After a server is connected to Azure Arc, it is represented as an Azure resource and can be managed through Azure Resource Manager, the Azure portal, Azure CLI, Azure PowerShell, and Azure APIs.

For the SC-500 exam, the important concept is that Azure Arc does not move the server into Azure. Instead, it creates a secure management relationship between the external server and Azure so that Azure services can apply security controls to that server.


What Is Azure Arc-Enabled Servers?

Azure Arc-enabled servers is an Azure service that allows organizations to connect:

  • Windows physical servers
  • Linux physical servers
  • Windows virtual machines
  • Linux virtual machines

These machines can be hosted:

  • On-premises
  • In another cloud provider
  • In a datacenter
  • At an edge location
  • In a supported virtualized environment

When connected, each machine receives an Azure representation with an Azure resource ID. The resource can be placed in an Azure resource group and managed using Azure governance and security services.

Important distinction

Azure Arc-enabled servers is designed for servers outside Azure. It is not intended to provide Azure Arc management for ordinary Azure VMs, which are already native Azure resources.


Why Azure Arc Is Important for Security

Without Azure Arc, an organization may need separate security processes for each environment:

EnvironmentPossible management approach
AzureAzure portal and Defender for Cloud
On-premisesLocal management tools
AWSAWS security and management tools
GCPGCP security and management tools
EdgeCustom monitoring and administration

This can result in:

  • Inconsistent security baselines
  • Different patching schedules
  • Unmonitored servers
  • Excessive administrative permissions
  • Incomplete asset inventories
  • Delayed vulnerability remediation
  • Different compliance reports
  • Security gaps between cloud and datacenter environments

Azure Arc provides a common Azure control plane for supported external servers. This allows organizations to extend services such as:

  • Microsoft Defender for Cloud
  • Microsoft Defender for Servers
  • Microsoft Defender for Endpoint
  • Microsoft Sentinel
  • Azure Policy
  • Azure Machine Configuration
  • Azure Monitor
  • Azure Update Manager
  • Azure Automation
  • Azure Resource Graph

The exact capabilities depend on the service, operating system, region, licensing, and supported configuration.


Azure Arc Architecture

The Azure Connected Machine agent

To connect a server to Azure Arc, the Azure Connected Machine agent must be installed on the server.

The agent:

  1. Establishes the relationship between the server and the Azure subscription.
  2. Registers the machine as an Azure resource.
  3. Provides a managed identity for the machine.
  4. Communicates with Azure over outbound connections.
  5. Enables extensions and other Azure services.
  6. Helps evaluate or enforce configuration settings on the server.

The Azure representation becomes the control point through which authorized Azure users and services manage the connected machine.

Azure is the source of truth

Management actions are generally initiated against the Azure representation of the server. For example, an administrator may use Azure to:

  • Install a monitoring extension
  • Enable Microsoft Defender for Servers
  • Assign an Azure Policy
  • Apply a machine configuration
  • Enable update management
  • Configure an approved extension

The Azure control plane evaluates the request against applicable permissions and policies before the action is sent to the agent.

This is important because Azure RBAC and Azure Policy can govern who is allowed to perform management operations on the connected server.


How the Connected Machine Agent Communicates

Azure Arc-enabled servers primarily use outbound communication from the server to Azure.

Azure does not normally initiate inbound connections into the organization’s network to manage the server. Communication between the agent and Azure is encrypted using TLS.

Security benefits of outbound communication

This design can reduce the need to:

  • Open inbound management ports
  • Expose servers directly to the internet
  • Create inbound firewall rules for Azure management
  • Publish RDP or SSH endpoints

The organization must still allow the required outbound endpoints through its firewall or proxy.

Network planning considerations

Before onboarding a server, verify:

  • DNS resolution works.
  • The server can reach required Azure endpoints.
  • Outbound HTTPS traffic is permitted.
  • Proxy settings are configured if required.
  • TLS inspection is compatible with the agent and extensions.
  • Extensions have access to any additional endpoints they require.

Some extensions have their own network requirements beyond the base Azure Arc agent requirements.


Public and Private Connectivity

Azure Arc-enabled servers can use public Azure endpoints or supported private endpoint configurations.

Public endpoint connectivity

With public connectivity:

  • The server makes outbound connections to Azure.
  • Traffic is encrypted.
  • Required Azure endpoints must be allowed through the organization’s firewall or proxy.

This is often the simplest deployment model.

Private endpoint connectivity

Private endpoints can allow Azure Arc traffic to travel through private connectivity such as:

  • ExpressRoute
  • Site-to-site VPN

Private endpoints can provide more granular control over which machines are allowed to communicate with Azure Arc services.

However, private endpoints do not eliminate every public endpoint requirement. For example, Microsoft Entra ID does not provide a private endpoint in the same way as Azure Arc services, and some extensions may still require public connectivity.

Important limitation

Using a private endpoint for Azure Arc does not mean that every remote-management method becomes private. For example, SSH and Windows Admin Center access have separate requirements and are not automatically provided through an Azure Arc private endpoint.


Azure Arc and Microsoft Defender for Cloud

Azure Arc is commonly used to onboard non-Azure servers into Microsoft Defender for Cloud.

The general process is:

  1. Connect the external server to Azure Arc.
  2. Register the server in an Azure subscription.
  3. Enable the appropriate Microsoft Defender for Cloud plan.
  4. Deploy required security agents or extensions.
  5. Review recommendations, alerts, and security posture.
  6. Remediate identified issues.

Once connected to Azure Arc and covered by the appropriate Defender for Servers plan, an external server can appear in Defender for Cloud alongside native Azure resources.

Security capabilities that may be extended

Depending on licensing and configuration, organizations can use Defender for Cloud to provide:

  • Security posture management
  • Security recommendations
  • Vulnerability assessment
  • Threat detection
  • Microsoft Defender for Endpoint integration
  • File Integrity Monitoring
  • Just-in-time VM access where supported
  • Regulatory compliance assessments
  • Security alerts
  • Cloud workload protection

Not every Defender capability is automatically available merely because a server is connected to Azure Arc. The required Defender plan and supporting agents or extensions must be configured.


Azure Arc and Microsoft Defender for Servers

Microsoft Defender for Servers extends security protection to supported servers outside Azure when they are connected through Azure Arc.

Defender for Servers Plan 1

Plan 1 provides core server protection capabilities, including Microsoft Defender for Endpoint integration where supported.

Defender for Servers Plan 2

Plan 2 includes additional capabilities, such as:

  • File Integrity Monitoring
  • Just-in-time VM access
  • Additional vulnerability and security capabilities
  • Additional cloud workload protection features

The exact feature set should always be checked against the current service configuration and licensing model.

Exam distinction

Azure Arc provides the connection and Azure resource representation.

Microsoft Defender for Servers provides the server security capabilities.

They are related, but they are not the same service.


Azure Arc and Microsoft Defender for Endpoint

Microsoft Defender for Endpoint can provide endpoint protection and detection capabilities for supported Arc-enabled servers.

Capabilities may include:

  • Endpoint detection and response
  • Threat detection
  • Vulnerability management
  • Security monitoring
  • Investigation support
  • Automated response capabilities, depending on licensing and configuration

Azure Arc helps Defender for Cloud identify and manage the external server, while Defender for Endpoint provides endpoint-level security telemetry and protection.


Azure Arc and Microsoft Sentinel

Microsoft Sentinel is a cloud-native security information and event management and security orchestration, automation, and response solution.

Azure Arc can help onboard hybrid and multicloud servers so that their security events can be collected and analyzed in Microsoft Sentinel.

A typical architecture may include:

  1. Azure Arc connects the server to Azure.
  2. A supported monitoring or security agent is installed.
  3. Server logs and security events are collected.
  4. Data is sent to a Log Analytics workspace.
  5. Microsoft Sentinel analyzes the data.
  6. Analytics rules detect suspicious activity.
  7. Incidents, automation rules, and playbooks support response.

This provides a centralized view of security events across Azure, on-premises, and other cloud environments.

Example

An organization has:

  • Windows servers in Azure
  • Linux servers in an on-premises datacenter
  • AWS virtual machines
  • A central Microsoft Sentinel workspace

Azure Arc can provide the Azure connection for the non-Azure servers. Microsoft Sentinel can then correlate events from all environments to detect activity that might not be suspicious when viewed in isolation.


Azure Arc and Azure Policy

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

Policy assignments can evaluate:

  • Whether required extensions are installed
  • Whether security agents are deployed
  • Whether specific configurations are present
  • Whether servers meet organizational standards
  • Whether resources are located in approved resource groups
  • Whether required tags or metadata are present

Azure Policy can be assigned at scopes such as:

  • Management group
  • Subscription
  • Resource group
  • Individual resource

Example policy requirements

An organization might require that all Arc-enabled production servers:

  • Have Microsoft Defender for Endpoint installed
  • Send security data to an approved Log Analytics workspace
  • Use a specific security configuration
  • Have required tags
  • Belong to an approved resource group
  • Use a supported operating system version

Azure Policy helps maintain consistent governance across servers that otherwise run in different environments.


Azure Machine Configuration

Azure Machine Configuration, previously associated with Guest Configuration, can audit or enforce settings inside Arc-enabled servers.

It can be used to evaluate operating-system and machine-level settings, such as:

  • Password policies
  • Security options
  • Registry settings
  • File configurations
  • Services
  • Installed software
  • Operating-system configuration
  • Compliance with organizational baselines

Azure Policy versus Machine Configuration

CapabilityAzure PolicyAzure Machine Configuration
Primary focusAzure resource governanceSettings inside the guest operating system
ExampleRequire a security extensionRequire a specific password policy
ScopeAzure resource hierarchyMachine configuration
Typical resultResource compliance stateGuest configuration compliance state

Azure Policy can assign or evaluate machine configuration policies against Arc-enabled servers.


Azure Arc Extensions

Extensions allow Azure services and other supported capabilities to be installed or configured on an Arc-enabled server.

Examples include extensions for:

  • Monitoring
  • Security
  • Configuration
  • Automation
  • Update management
  • Custom scripts
  • Dependency analysis

Security considerations for extensions

Extensions can perform powerful operations on the server. Therefore, organizations should:

  • Limit who can install extensions.
  • Use extension allowlists where appropriate.
  • Review extension publishers and functionality.
  • Keep extensions updated.
  • Remove unnecessary extensions.
  • Monitor extension installation and configuration changes.
  • Apply Azure Policy to control extension deployment.

A compromised or overly privileged account could potentially use an extension to make changes on the server. For this reason, extension management should be treated as a privileged operation.


Azure Arc Managed Identity

The Connected Machine agent provides a managed identity for the connected server.

A managed identity can allow the server or supported applications to authenticate to Azure services without storing credentials such as:

  • Passwords
  • Client secrets
  • Certificates
  • Access keys

For example, a supported application running on an Arc-enabled server may use its managed identity to access an Azure resource according to its assigned permissions.

Benefits

Managed identities can:

  • Reduce credential storage
  • Reduce secret rotation requirements
  • Support Azure RBAC
  • Improve auditability
  • Reduce the risk of exposed credentials

Least-privilege requirement

A managed identity should receive only the permissions required for its tasks. Assigning broad roles such as Owner or Contributor unnecessarily increases risk.


Azure Arc Onboarding Methods

The onboarding process generally includes:

  1. Select the Azure subscription and resource group.
  2. Select the Azure region.
  3. Prepare the server.
  4. Install the Azure Connected Machine agent.
  5. Authenticate the onboarding operation.
  6. Register the server with Azure Arc.
  7. Verify the connection.
  8. Apply security services and policies.

Authentication options

Depending on the deployment method, onboarding may use:

  • Interactive user authentication
  • A service principal
  • Other supported authentication methods

Service principal security

When using a service principal for onboarding at scale:

  • Grant only the required permissions.
  • Avoid broad subscription-wide roles where possible.
  • Protect client secrets.
  • Rotate credentials regularly.
  • Prefer certificate-based or managed identity approaches when supported.
  • Do not place secrets directly in scripts or source-control repositories.
  • Restrict who can create and use onboarding credentials.

Microsoft identifies protection and rotation of onboarding credentials as a customer responsibility.


Organizing Arc-Enabled Servers

The subscription, resource group, and management-group hierarchy affects who can manage connected servers.

A recommended design is to organize servers according to:

  • Environment
  • Business unit
  • Data sensitivity
  • Administrative ownership
  • Compliance requirements
  • Production versus nonproduction status
  • Geographic or regulatory boundaries

Example structure

Management Group
└── Hybrid Security
├── Production Servers Subscription
│ ├── Critical Servers Resource Group
│ └── Application Servers Resource Group
└── Nonproduction Servers Subscription
├── Development Resource Group
└── Testing Resource Group

This structure allows administrators to apply different:

  • RBAC assignments
  • Azure Policy assignments
  • Defender plans
  • Monitoring configurations
  • Compliance requirements

Why resource placement matters

Azure RBAC permissions inherited from a subscription or resource group can grant users access to connected servers. Therefore, placing highly sensitive servers in a broadly administered resource group may unintentionally expand administrative access.


Protecting Tier 0 and Highly Sensitive Servers

Tier 0 assets may include:

  • Active Directory domain controllers
  • Certificate authorities
  • Privileged identity infrastructure
  • Highly sensitive application servers
  • Systems that control other security systems

Connecting these systems to Azure Arc can provide valuable security visibility, but it also introduces an additional management control plane.

Recommended precautions

For sensitive servers:

  • Use a dedicated subscription where practical.
  • Minimize persistent administrators.
  • Review inherited RBAC permissions.
  • Review management-group policies.
  • Restrict extension deployment.
  • Disable unnecessary agent functionality.
  • Monitor all management operations.
  • Keep the Connected Machine agent updated.
  • Ensure onboarding credentials are protected.
  • Apply only required security and management services.

Microsoft specifically recommends extra care when connecting Tier 0 assets because subscription and management-group administrators may be able to grant themselves access to the Arc-enabled server resource.


Agent and Extension Updates

The Connected Machine agent and its extensions are security-sensitive components.

Organizations should establish processes to:

  • Monitor agent versions
  • Apply agent updates
  • Update extensions
  • Remove obsolete extensions
  • Test updates before broad deployment
  • Monitor failed updates
  • Confirm that security agents remain operational

Keeping the operating system updated remains the customer’s responsibility. Azure Arc does not automatically make the underlying operating system secure.

Azure Update Manager or other supported update-management capabilities can help coordinate operating-system updates across Arc-enabled servers.


Shared Responsibility Model

Security for Arc-enabled servers is shared between Microsoft and the customer.

Microsoft responsibilities

Microsoft is responsible for:

  • Securing the Azure service
  • Protecting system metadata stored in Azure
  • Operating the Azure management platform
  • Publishing agent updates
  • Documenting security features and limitations

Customer responsibilities

The customer is responsible for:

  • Securing the physical or virtual server
  • Managing operating-system security
  • Managing RBAC access
  • Protecting onboarding credentials
  • Updating the agent and extensions
  • Configuring network access
  • Applying security policies
  • Reviewing security recommendations
  • Determining regulatory compliance
  • Securing the infrastructure hosting the server

Connecting a server to Azure Arc does not transfer responsibility for the guest operating system or underlying infrastructure to Microsoft.


Common Security Mistakes

Mistake 1: Treating Azure Arc as an endpoint-protection product

Azure Arc provides management connectivity and resource representation. Endpoint protection normally requires Defender for Endpoint or another supported security solution.

Mistake 2: Assuming onboarding automatically enables every Defender capability

The appropriate Defender plan, agents, extensions, and configuration are still required.

Mistake 3: Assigning excessive RBAC permissions

Subscription and resource-group administrators may gain broad control over Arc-enabled servers. Use least privilege and carefully designed resource groups.

Mistake 4: Storing service principal secrets in scripts

Onboarding scripts containing credentials can expose the organization to credential theft. Use secure credential handling and rotate credentials regularly.

Mistake 5: Allowing unrestricted extension installation

Extensions can perform privileged actions. Control extension deployment and use allowlists when appropriate.

Mistake 6: Assuming private endpoints remove all network requirements

Private endpoints may reduce exposure, but Microsoft Entra ID and some extensions may still require access to other endpoints.

Mistake 7: Ignoring the underlying server

Azure Arc does not replace:

  • Operating-system patching
  • Local firewall configuration
  • Endpoint protection
  • Application security
  • Backup
  • Identity hardening
  • Physical security
  • Network segmentation

Example: Securing an On-Premises Linux Server

An organization has an on-premises Linux server hosting a critical application.

The organization wants to:

  • Register the server in Azure
  • Apply a security baseline
  • Monitor security events
  • Detect vulnerabilities
  • Centralize security alerts
  • Restrict administrative access

A possible implementation is:

  1. Install the Azure Connected Machine agent.
  2. Register the server in an approved Azure subscription and resource group.
  3. Enable Microsoft Defender for Servers Plan 2 if required.
  4. Deploy the required Defender for Endpoint and monitoring components.
  5. Connect the relevant logs to Microsoft Sentinel.
  6. Assign Azure Policy for required configuration.
  7. Apply Azure Machine Configuration policies.
  8. Review Defender for Cloud recommendations.
  9. Remediate vulnerabilities and configuration issues.
  10. Monitor agent and extension health.
  11. Review RBAC assignments regularly.
  12. Protect the onboarding credentials and update processes.

This design extends Azure security management without moving the Linux server into Azure.


Example: Securing AWS Virtual Machines

An organization runs application servers in AWS but wants centralized security monitoring in Azure.

A typical approach is:

  1. Connect the AWS environment to Microsoft Defender for Cloud using the supported multicloud connector.
  2. Allow the connector to deploy or onboard the required Azure Arc components.
  3. Verify that the AWS machines appear as Arc-enabled servers.
  4. Enable the appropriate Defender for Servers plan.
  5. Deploy required security agents or extensions.
  6. Review Defender for Cloud recommendations and alerts.
  7. Send relevant security events to Microsoft Sentinel.
  8. Use Azure Policy and machine configuration to evaluate required settings.

The multicloud connector can simplify onboarding by handling the Azure Arc deployment for supported AWS and GCP scenarios.


Exam-Focused Comparison

Service or featurePrimary purpose
Azure Arc-enabled serversConnect and manage external servers through Azure
Azure Connected Machine agentEstablishes and maintains the server-to-Azure relationship
Microsoft Defender for CloudCentralized security posture management and workload protection
Microsoft Defender for ServersSecurity protection for supported servers
Microsoft Defender for EndpointEndpoint detection, response, and vulnerability capabilities
Microsoft SentinelCentralized security event analysis and response
Azure PolicyGovernance and compliance at the Azure resource level
Azure Machine ConfigurationAudit or enforce settings inside the guest operating system
Azure MonitorMonitoring, metrics, and logs
Azure Update ManagerUpdate management across supported machines
Azure RBACControls who can manage Arc-enabled resources

Key Exam Takeaways

Remember these points for the SC-500 exam:

  • Azure Arc-enabled servers extends Azure management and security capabilities to servers outside Azure.
  • The Azure Connected Machine agent must be installed on the external server.
  • An Arc-enabled server becomes an Azure resource with an Azure resource ID.
  • Azure Arc is not the same as Microsoft Defender for Cloud.
  • Defender for Cloud and Defender for Servers provide security capabilities after the appropriate plans and agents are configured.
  • Microsoft Defender for Endpoint provides endpoint protection and detection capabilities.
  • Microsoft Sentinel can collect and correlate security events from Arc-enabled servers.
  • Azure Policy can govern Arc-enabled server resources.
  • Azure Machine Configuration evaluates or enforces settings inside the guest operating system.
  • Arc communication is primarily outbound from the server to Azure and is encrypted using TLS.
  • Private endpoints are optional and do not eliminate every public endpoint requirement.
  • Onboarding credentials and service principal secrets must be protected and rotated.
  • Extensions are powerful and should be controlled.
  • RBAC permissions inherited from subscriptions and resource groups can affect access to connected servers.
  • Tier 0 servers require additional planning and restrictive management controls.
  • Azure Arc does not replace operating-system security, endpoint protection, patching, or network security.

Practice Exam Questions

Question 1

An organization runs Linux servers in an on-premises datacenter and wants to manage them through Azure Resource Manager without moving them into Azure.

Which service should the organization use?

A. Azure Arc-enabled servers
B. Azure Bastion
C. Azure Virtual Desktop
D. Azure Load Balancer

Answer: A

Explanation: Azure Arc-enabled servers represents supported physical and virtual servers outside Azure as Azure resources that can be managed through Azure Resource Manager.


Question 2

What component must be installed on an on-premises server before it can be connected to Azure Arc-enabled servers?

A. Microsoft Sentinel agent only
B. Azure Connected Machine agent
C. Azure Application Gateway agent
D. Azure Storage Explorer

Answer: B

Explanation: The Azure Connected Machine agent establishes the relationship between the external server and the Azure subscription.


Question 3

Which statement best describes the normal network communication model for Azure Arc-enabled servers?

A. Azure requires inbound RDP access to every connected server
B. Azure connects to the server through an inbound SSH tunnel by default
C. The Connected Machine agent primarily establishes outbound encrypted connections to Azure
D. The server must expose all management ports to the public internet

Answer: C

Explanation: Azure Arc primarily uses outbound communication from the server to Azure. The communication is encrypted using TLS, reducing the need for inbound management access.


Question 4

An organization wants to evaluate whether Arc-enabled servers comply with a required password policy and operating-system security configuration.

Which capability is most appropriate?

A. Azure Load Balancer health probes
B. Azure Resource Locks
C. Azure Machine Configuration
D. Azure Traffic Manager

Answer: C

Explanation: Azure Machine Configuration evaluates or enforces settings inside the guest operating system, such as password policies and security configuration.


Question 5

An organization connects its on-premises servers to Azure Arc and then enables Microsoft Defender for Servers Plan 2.

Which additional capability may be available through Plan 2?

A. File Integrity Monitoring and just-in-time VM access
B. Automatic conversion of the server into an Azure VM
C. Replacement of the server’s operating system
D. Automatic creation of a public IP address for the server

Answer: A

Explanation: Defender for Servers Plan 2 includes additional capabilities such as File Integrity Monitoring and just-in-time VM access, subject to supported configurations.


Question 6

A security team wants to centralize and correlate security events from Azure VMs, on-premises servers, and AWS virtual machines.

Which service should be used for centralized security information and event management?

A. Azure DNS
B. Microsoft Sentinel
C. Azure Resource Manager locks
D. Azure Container Registry

Answer: B

Explanation: Microsoft Sentinel can collect, analyze, correlate, and respond to security events from multiple environments, including Arc-enabled servers.


Question 7

An administrator wants to prevent users from installing unauthorized extensions on Arc-enabled servers.

Which control should be considered?

A. Azure Policy and Azure Arc extension controls
B. Azure CDN caching rules
C. Azure Front Door routing rules
D. Azure Storage lifecycle management

Answer: A

Explanation: Extensions can perform powerful operations on connected servers. Azure Policy and available Arc agent security controls can help restrict or govern extension deployment.


Question 8

An organization is onboarding hundreds of servers using a service principal.

Which action best protects the onboarding process?

A. Assign the service principal the Owner role on every subscription
B. Store the client secret in a publicly accessible script
C. Grant only required permissions and protect and rotate the credentials
D. Disable Azure RBAC after onboarding is complete

Answer: C

Explanation: Onboarding credentials should be protected, granted only the permissions required, and rotated regularly. Excessive permissions and exposed secrets create significant security risks.


Question 9

A company wants to isolate highly sensitive domain controllers that are connected through Azure Arc from ordinary application servers.

Which design is most appropriate?

A. Place all servers in one broadly administered resource group
B. Use a dedicated subscription or tightly controlled resource hierarchy with minimal persistent administrators
C. Give every administrator the Owner role
D. Disable all Azure Policy assignments

Answer: B

Explanation: Tier 0 assets require careful control of inherited permissions and management access. A dedicated subscription or tightly controlled hierarchy can reduce the number of users and policies able to manage the servers.


Question 10

Which statement correctly distinguishes Azure Arc-enabled servers from Microsoft Defender for Cloud?

A. Azure Arc provides endpoint antivirus, while Defender for Cloud only registers resources
B. Azure Arc connects and represents external servers in Azure, while Defender for Cloud provides security posture and workload protection capabilities
C. Azure Arc is used only for Azure VMs, while Defender for Cloud is used only for on-premises servers
D. Azure Arc replaces Azure Policy and Microsoft Sentinel

Answer: B

Explanation: Azure Arc provides the connection and Azure resource representation for supported external servers. Defender for Cloud provides security posture management and workload protection capabilities after the appropriate plans and configurations are enabled.


Go to the SC-500 Exam Prep Hub main page

Leave a Reply