Tag: Azure Arc

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

Connect hybrid cloud and multicloud environments to Defender for Cloud, including Amazon Web Services (AWS) and Google Cloud Platform (GCP) (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:
Manage and monitor security posture (20–25%)
   --> Manage security posture by using Defender for Cloud
      --> Connect hybrid cloud and multicloud environments to Defender for Cloud, including Amazon Web Services (AWS) and Google Cloud Platform (GCP)


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

Modern organizations rarely operate entirely within a single cloud provider.

An enterprise might have:

  • Azure virtual machines
  • Amazon EC2 instances
  • Google Compute Engine virtual machines
  • Amazon EKS clusters
  • Google Kubernetes Engine (GKE) clusters
  • On-premises servers
  • SQL Server databases running outside Azure
  • Applications distributed across multiple cloud platforms

Managing security independently in each environment can create visibility gaps and inconsistent security controls.

Microsoft Defender for Cloud helps address this problem by providing a centralized security platform for Azure, AWS, GCP, on-premises, and other supported environments.

For the SC-500 exam, an especially important concept is that Defender for Cloud can extend both:

  • Cloud Security Posture Management (CSPM) capabilities to multicloud environments
  • Cloud Workload Protection Platform (CWPP) capabilities to supported multicloud workloads

These two capabilities use different mechanisms.

CSPM is primarily agentless, while many CWPP scenarios use Azure Arc to connect non-Azure workloads to Azure and enable additional protection capabilities.


1. What Does “Multicloud” Mean?

A multicloud environment uses services from more than one public cloud provider.

For example:

Azure

  • Azure Virtual Machines
  • Azure SQL
  • Azure Storage
  • Azure Kubernetes Service

AWS

  • EC2
  • S3
  • RDS
  • EKS

GCP

  • Compute Engine
  • Cloud Storage
  • Cloud SQL
  • GKE

An organization may intentionally use multiple providers because of:

  • Existing investments
  • Business acquisitions
  • Application requirements
  • Geographic considerations
  • Vendor strategy
  • Specialized cloud services
  • Regulatory requirements
  • Avoidance of excessive vendor dependency

From a security perspective, however, multicloud environments introduce complexity.

Security teams need to answer questions such as:

  • What resources exist?
  • Where are they located?
  • Which resources are exposed?
  • Which resources have vulnerabilities?
  • Which security standards apply?
  • Which workloads are protected?
  • Which accounts or projects have excessive permissions?
  • Where are active threats occurring?

Defender for Cloud can provide a unified view across these environments.


2. What Does “Hybrid Cloud” Mean?

A hybrid environment combines cloud resources with infrastructure outside the public cloud.

A typical example is:

On-premises data center

↓

Azure

↓

AWS

↓

GCP

Defender for Cloud can incorporate on-premises servers by using Azure Arc-enabled servers.

An Azure Arc-enabled server becomes an Azure resource, allowing Azure services and Defender for Cloud capabilities to interact with that server.

For the SC-500 exam, remember:

Azure Arc is the key technology for extending Azure management and many Defender for Cloud workload-protection capabilities to servers outside Azure.


3. The Defender for Cloud Multicloud Model

The multicloud architecture can be viewed conceptually as:

                       Microsoft Defender for Cloud
                                  |
             +--------------------+--------------------+
             |                    |                    |
           Azure                 AWS                  GCP
             |                    |                    |
        Azure resources      AWS resources        GCP resources
             |                    |                    |
             +--------------------+--------------------+
                                  |
                           Unified security
                                  |
              +-----------------+----------------+
              |                                  |
             CSPM                               CWPP
       Posture management                  Workload protection
       Primarily agentless                Often uses Azure Arc

The key idea is that Defender for Cloud doesn’t require an organization to move its workloads into Azure.

Instead, it connects to the other environments and provides security visibility and, where supported, workload protection.


4. CSPM vs. CWPP in Multicloud Environments

This is one of the most important concepts for SC-500.

Cloud Security Posture Management

CSPM focuses on answering:

“Is my environment configured securely?”

Examples include identifying:

  • Misconfigured resources
  • Excessive exposure
  • Weak security configurations
  • Compliance issues
  • Vulnerable configurations
  • Excessive permissions
  • Security recommendations

Defender for Cloud provides CSPM capabilities for AWS and GCP after their environments are connected.

Importantly, multicloud CSPM is agentless. The CSPM assessment does not require installing agents on every AWS or GCP resource.


5. Cloud Workload Protection Platform

CWPP focuses more directly on protecting workloads from threats.

Examples include:

  • Endpoint threat detection
  • Runtime protection
  • Vulnerability assessment
  • Malware detection
  • Container runtime protection
  • Database threat detection

For multicloud environments, many of these capabilities require additional components.

For example, Defender for Servers can use:

  • Azure Arc
  • Microsoft Defender for Endpoint
  • Vulnerability assessment capabilities
  • Agentless scanning

The exact dependencies vary by Defender plan.

Exam distinction

Remember:

CapabilityPrimary purposeMulticloud approach
CSPMIdentify security posture issuesPrimarily agentless
CWPPProtect workloads against threatsOften requires Azure Arc/agents/extensions
Azure ArcConnect/manage supported non-Azure resourcesAzure management plane
Defender plansAdd workload-specific protectionDepends on workload

6. Connecting AWS to Defender for Cloud

AWS accounts can be connected directly to Defender for Cloud through a native AWS connector.

The connection creates a security relationship between Microsoft Defender for Cloud and the AWS environment.

The high-level process is:

  1. Open Microsoft Defender for Cloud.
  2. Navigate to the environment settings.
  3. Select the option to connect an AWS account.
  4. Specify the AWS account and Azure subscription information.
  5. Select the Defender plans to enable.
  6. Configure the required AWS permissions.
  7. Deploy the required AWS resources.
  8. Complete the connector configuration.
  9. Validate connector health.
  10. Review coverage.

Microsoft’s current AWS onboarding process supports configuring the connector through the Azure portal and deploying the required AWS resources using AWS CloudFormation or Terraform, depending on the configuration.


7. AWS Authentication: Federated Authentication

A critical security feature is that Defender for Cloud does not require storing long-lived AWS credentials.

Instead, Defender for Cloud uses federated authentication.

The current AWS architecture uses:

  • Microsoft-managed Microsoft Entra application
  • OpenID Connect (OIDC)
  • AWS IAM roles
  • AWS Security Token Service (STS)
  • Short-lived credentials

The CloudFormation deployment establishes the required trust relationship.

Conceptually:

Microsoft Defender for Cloud
|
| Federated authentication
v
Microsoft Entra identity
|
| OIDC / web identity federation
v
AWS IAM Role
|
| Assume role
v
AWS Security Token Service
|
| Short-lived credentials
v
AWS Resources

The important security principle is:

Defender for Cloud obtains short-lived credentials through federation instead of requiring long-lived AWS access keys to be stored.

SC-500 exam tip

If an answer says:

“Store an AWS access key and secret key in Defender for Cloud.”

that should immediately raise a red flag.

The preferred architecture uses federated trust and temporary credentials.


8. AWS IAM Permissions

The AWS connector requires appropriate permissions to discover and protect AWS resources.

The permissions depend on the Defender plans that are enabled.

For example, the CSPM connector requires permissions to discover AWS resources.

Additional permissions may be required for:

  • Defender for Servers
  • Defender for Containers
  • Other workload protection capabilities
  • Agentless scanning
  • Azure Arc autoprovisioning

Defender for Cloud creates the required roles and permissions in AWS as part of connector configuration.


9. Default Access vs. Least-Privilege Access

When configuring an AWS connector, Defender for Cloud provides options for configuring access.

Two important concepts are:

Default access

Provides the permissions required for the selected Defender capabilities and allows Defender for Cloud to incorporate future capabilities.

Least-privilege access

Grants only the permissions currently required by the selected plans.

The trade-off is important.

If new capabilities require additional permissions later, the connector may need to be updated.

Microsoft documents that changes to Defender plans or plan options can require rerunning the appropriate deployment artifact, such as the CloudFormation template or Terraform configuration.

Exam concept

If a question emphasizes:

“Grant only the minimum permissions required.”

think:

Least-privilege access.

If the question emphasizes:

“Automatically include future Defender capabilities.”

think:

Default access.


10. Connecting GCP to Defender for Cloud

GCP projects and organizations can also be connected to Defender for Cloud.

The high-level workflow is similar to AWS:

  1. Open Defender for Cloud.
  2. Navigate to Environment settings.
  3. Select the GCP connection option.
  4. Select the Azure subscription.
  5. Specify the GCP project or organization.
  6. Configure the required GCP permissions.
  7. Deploy the required GCP configuration.
  8. Complete the connector configuration.
  9. Validate connector health.
  10. Review coverage.

The current GCP connector uses federated authentication, allowing Defender for Cloud to access GCP APIs without storing long-lived credentials.


11. GCP Authentication

The GCP authentication architecture is designed to establish trust between Defender for Cloud and GCP.

The goal is similar to AWS:

Provide Defender for Cloud with the permissions required to inspect and protect resources without relying on permanently stored cloud credentials.

This is an important Zero Trust-oriented principle.

The security solution should have:

  • Appropriate identity
  • Appropriate permissions
  • Appropriate scope
  • No unnecessary long-lived secrets

12. GCP IAM Permissions

The GCP connector creates the required roles and permissions based on the selected Defender plans.

For example, Defender CSPM requires permissions that allow Defender for Cloud to:

  • Discover projects
  • Inspect organizations
  • Inspect folders
  • Review resource configurations
  • Discover resources
  • Analyze IAM-related information
  • Discover supported AI platform resources

Additional permissions may be required for workload protection plans.

Important principle

The permissions required for a GCP connector are not necessarily the same as the permissions required for an AWS connector.

Each cloud provider has its own identity and authorization model.


13. AWS vs. GCP Connector Comparison

CharacteristicAWSGCP
Connected to Defender for CloudYesYes
CSPM supportYesYes
CWPP supportYesYes
AuthenticationFederatedFederated
Long-lived cloud credentials requiredNoNo
Connector creates cloud-side security configurationYesYes
Infrastructure deploymentCloudFormation/TerraformCloud Shell/Terraform
Servers can use Azure ArcYesYes
Containers/Kubernetes supportedEKSGKE
CSPM is primarily agentlessYesYes

The exact permissions and deployment artifacts differ between AWS and GCP.


14. Azure Arc and Multicloud Servers

Azure Arc is particularly important when protecting servers outside Azure.

For example:

AWS EC2
|
| Azure Arc
v
Azure
|
v
Microsoft Defender for Cloud

and:

GCP Compute Engine
|
| Azure Arc
v
Azure
|
v
Microsoft Defender for Cloud

The Azure Arc Connected Machine agent enables the non-Azure server to participate in Azure management.

Microsoft recommends onboarding AWS and GCP machines as Azure Arc-enabled VMs to obtain the full Defender for Servers functionality.


15. Azure Arc Does Not Mean the Workload Moves to Azure

This is an important conceptual distinction.

When an AWS EC2 instance is connected through Azure Arc:

The EC2 instance remains in AWS.

When a GCP Compute Engine VM is connected through Azure Arc:

The VM remains in GCP.

Azure Arc provides a management and identity bridge.

Conceptually:

AWS EC2
|
+---- remains in AWS
|
+---- Azure Arc connection
|
v
Defender for Cloud

The same principle applies to GCP.


16. Defender for Servers on AWS and GCP

Defender for Servers can protect:

  • AWS EC2 instances
  • GCP Compute Engine VMs
  • Azure VMs
  • Azure Arc-enabled servers
  • Supported on-premises machines

When AWS or GCP machines are connected through the multicloud connector, Azure Arc can be automatically deployed as part of the connection process.

The Azure Arc agent is important because it allows Defender for Cloud to:

  • Read host-level security information
  • Deploy required extensions
  • Connect the machine to Azure
  • Extend Defender capabilities to the machine

For AWS, the AWS Systems Manager (SSM) agent is used as part of the Azure Arc autoprovisioning process.

For GCP, the OS Config agent is used for the corresponding process.


17. Defender for Containers in AWS and GCP

Defender for Containers can extend protection to:

  • Amazon EKS
  • Google GKE
  • Other supported Kubernetes environments through Azure Arc-enabled Kubernetes

The multicloud container protection architecture can include:

  • Azure Arc agent
  • Defender sensor
  • Azure Policy for Kubernetes
  • Kubernetes audit logs
  • Agentless scanning

These components have different purposes.

Defender sensor

Provides runtime threat protection.

Azure Policy for Kubernetes

Helps assess and enforce Kubernetes security configuration.

Kubernetes audit logs

Provide activity information that Defender for Cloud can use for suspicious-activity detection and investigation.

Agentless capabilities

Provide visibility into Kubernetes inventory and other security information without requiring the same sensor-based deployment model.


18. EKS and GKE

For the SC-500 exam, remember this mapping:

CloudKubernetes serviceDefender for Containers
AzureAKSYes
AWSEKSYes
GCPGKEYes

This is an easy area for scenario-based questions.

If the question describes:

“A Kubernetes cluster running in AWS”

think:

Amazon EKS → Defender for Containers

If it describes:

“A Kubernetes cluster running in GCP”

think:

GKE → Defender for Containers


19. Defender for SQL in Multicloud Environments

Defender for SQL can provide threat protection for supported SQL workloads running on AWS and GCP.

For multicloud SQL Server scenarios, Azure Arc is important.

The SQL Server can be running on:

  • AWS EC2
  • GCP Compute Engine
  • Other supported machines

The machine is connected to Azure through Azure Arc, and the appropriate Defender for SQL configuration is enabled in the Azure subscription containing the Arc-enabled machine.


20. Multicloud Dependency Model

Different Defender plans have different dependencies.

A simplified view is:

Defender capabilityAzure ArcAgent/extensionAgentless capabilities
CSPMNoNoYes
Defender for ServersYesMDE/other componentsYes
Defender for ContainersYes for sensor-based capabilitiesDefender sensor/PolicyYes
Defender for SQL on MachinesYesSQL-related componentsLimited

The exact dependencies depend on the selected features and workload.

The key exam lesson is:

Do not assume that connecting an AWS or GCP account automatically installs every Defender component required for every workload.

Different plans have different requirements.


21. On-Premises Servers

Hybrid security also includes on-premises environments.

An on-premises server can be connected to Azure using Azure Arc-enabled servers.

Once connected:

  • The server becomes an Azure resource.
  • Azure services can interact with the server.
  • Defender for Cloud can assess and protect the server when the appropriate plans are enabled.

Microsoft recommends Azure Arc onboarding for on-premises servers when full Defender for Servers functionality is desired.


22. Why Azure Arc Is Important

Azure Arc creates a common management model.

Without Arc:

Azure → Azure security model
AWS → AWS security model
GCP → GCP security model
On-premises → Local management

With Arc:

                     Azure
                       |
             Microsoft Defender for Cloud
                       |
       +---------------+---------------+
       |               |               |
    Azure            AWS             GCP
                       |               |
                    Arc               Arc
                       |               |
                    Servers           Servers

This makes it easier to apply centralized security management.


23. Connecting an AWS Account: Conceptual Process

The exact portal experience can change, but the conceptual process is important for the exam.

Step 1 — Prepare Azure

Ensure Defender for Cloud is available in the Azure subscription.

Step 2 — Prepare AWS

Ensure the AWS account can deploy the required IAM roles and resources.

Step 3 — Create the connector

Create the AWS security connector in Defender for Cloud.

Step 4 — Select Defender plans

Select the plans required for the AWS environment.

For example:

  • Defender CSPM
  • Defender for Servers
  • Defender for Containers
  • Defender for SQL

Step 5 — Configure AWS access

Choose the appropriate access model and deploy the required CloudFormation or Terraform configuration.

Step 6 — Complete federation

The AWS-side IAM roles establish the trust relationship.

Step 7 — Validate

Confirm connector health.

Step 8 — Verify coverage

Use Defender for Cloud coverage information to confirm that the expected workloads are being protected.


24. Connecting a GCP Project: Conceptual Process

The process is similar.

Step 1 — Prepare Azure

Ensure Defender for Cloud is available.

Step 2 — Prepare GCP

Ensure the required permissions are available.

Step 3 — Create the GCP connector

Create the connector in Defender for Cloud.

Step 4 — Select Defender plans

Select the appropriate protection capabilities.

Step 5 — Configure GCP access

Deploy the required GCP configuration using the supported deployment method.

Step 6 — Establish federated authentication

The connector establishes the required trust relationship.

Step 7 — Validate connector health

Confirm that Defender for Cloud can communicate with GCP.

Step 8 — Verify coverage

Confirm that the expected GCP resources are visible and protected.


25. Connector Health

Connecting an AWS account or GCP project is not the end of the implementation.

Administrators should verify:

  • Connector status
  • Authentication
  • Permissions
  • Resource discovery
  • Defender plan configuration
  • Azure Arc status where applicable
  • Agent/extension deployment where applicable
  • Security recommendations
  • Security alerts
  • Workload coverage

Both the AWS and GCP connector experiences provide mechanisms to validate connector health and review coverage.


26. Coverage Verification

A very important operational step is determining:

“What is actually protected?”

Defender for Cloud provides coverage information through workbooks, including a Coverage workbook.

This can help administrators understand:

  • Which plans are enabled
  • Which subscriptions are involved
  • Which resources are covered
  • Where protection gaps exist

The GCP connector documentation specifically identifies the Coverage workbook as a way to understand current coverage.

Exam lesson

If the question asks:

“How can an administrator verify whether multicloud resources are covered?”

look for an answer involving:

Defender for Cloud coverage information/workbooks

rather than simply checking whether the connector exists.


27. Security Connector

When AWS or GCP environments are onboarded, Defender for Cloud creates a security connector as an Azure resource.

The connector represents the relationship between the external cloud environment and Defender for Cloud.

It also serves as an important scope for access management.

For example, organizations can assign access to workload owners based on the AWS account or GCP project represented by the security connector.


28. RBAC for Multicloud Security

Azure RBAC controls access to Defender for Cloud resources and security information.

For example, users may need access to:

  • Recommendations
  • Alerts
  • Security posture
  • Connector configuration
  • Workload information

Defender for Cloud includes roles such as:

  • Owner
  • Contributor
  • Reader
  • Security Reader

The Security Reader role provides read-only access to Defender for Cloud security information such as recommendations, alerts, policies, and security states.


29. Resource Group Scope

Multicloud security connectors are Azure resources.

Therefore, Azure RBAC can be used to control access to those connectors.

Permissions assigned at the resource-group level can also be inherited for multicloud recommendations and security alerts associated with the connectors.

This is useful in large organizations where:

  • Different teams own different cloud accounts.
  • Security operations is centralized.
  • Workload owners need visibility into only their environments.

30. Cloud Account vs. Subscription vs. Project

The terminology differs by cloud.

Azure

Subscription

AWS

Account

GCP

Project

A common SC-500 scenario might say:

“Connect an AWS environment.”

Think:

AWS account → Defender for Cloud connector → Azure subscription

Or:

“Connect a GCP environment.”

Think:

GCP project/organization → Defender for Cloud connector → Azure subscription

Understanding this terminology can prevent confusion on the exam.


31. AWS Organizations and GCP Organizations

Large cloud environments may contain many AWS accounts or GCP projects.

Organizations can design their connector strategy around the scale of their environment.

The goal is to avoid creating unnecessary management complexity while maintaining appropriate isolation and access control.

For particularly large AWS environments, Microsoft recommends considering how connectors are distributed across Azure subscriptions to manage portal scale effectively.


32. CloudTrail and Cloud Logging

Multicloud security can also incorporate activity information from the source cloud.

For AWS, Defender for Cloud supports AWS CloudTrail log ingestion in supported scenarios.

For GCP, GCP Cloud Logging ingestion is available in preview for certain enhanced identity and permission insights.

This is important because:

Resource configuration tells you what exists, while activity logs can provide additional context about what happened.


33. Agentless vs. Agent-Based Security

This distinction is extremely important.

Agentless

The security service obtains information without installing an agent on the workload.

Benefits can include:

  • Lower operational overhead
  • Faster deployment
  • Broad visibility
  • No workload agent lifecycle to maintain

Multicloud CSPM is primarily agentless.

Agent-based

An agent or extension runs on or alongside the workload.

This may provide:

  • Runtime telemetry
  • Host-level information
  • Endpoint detection
  • Runtime threat detection
  • Configuration enforcement

For example, Defender for Servers can use the Azure Arc agent and Defender for Endpoint capabilities.


34. Why CSPM Doesn’t Require Azure Arc

Suppose an organization connects an AWS account to Defender for Cloud.

The security team wants only:

“Identify AWS resources with security misconfigurations.”

Azure Arc isn’t required for the core CSPM assessment.

Why?

Because CSPM can assess the AWS environment through the multicloud connector using agentless techniques.

However, if the organization wants deeper workload protection for EC2 machines, Azure Arc may become important.

Exam distinction

Posture assessment:

Connector + agentless CSPM

Full server workload protection:

Connector + Azure Arc + appropriate Defender components


35. Defender for Servers and Azure Arc

For AWS and GCP machines, Azure Arc provides the bridge needed for full Defender for Servers functionality.

The current Microsoft guidance recommends Azure Arc onboarding because it enables the broader Defender for Servers feature set.

For example:

AWS EC2
↓
AWS SSM
↓
Azure Arc
↓
Defender for Cloud
↓
Defender for Servers
↓
Security monitoring/protection

A corresponding GCP model uses the GCP OS Config agent for Azure Arc autoprovisioning.


36. Networking Requirements

Multicloud protection requires appropriate outbound network connectivity.

For example, AWS and GCP machines that are being protected through Azure Arc need access to the endpoints required by the relevant Azure Arc and Defender components.

For GCP Defender for Servers deployments, required outbound HTTPS access includes endpoints such as:

  • osconfig.googleapis.com
  • compute.googleapis.com
  • containeranalysis.googleapis.com
  • agentonboarding.defenderforservers.security.azure.com
  • gbl.his.arc.azure.com

AWS deployments require access to appropriate AWS Systems Manager endpoints and Azure Arc endpoints.

Exam lesson

If an Arc-enabled machine cannot connect to Defender for Cloud, check:

  1. Agent status
  2. IAM permissions
  3. Outbound network connectivity
  4. Required endpoints
  5. Connector health

37. Data Residency Considerations

Multicloud security introduces data residency considerations.

Organizations should understand:

  • Where security data is collected
  • Where it is processed
  • Where it is stored
  • Which agents are involved
  • Which source-cloud logging services are involved

CSPM is primarily agentless, whereas CWPP capabilities can involve agents and extensions.

For Kubernetes, for example, source-cloud logging services such as Amazon CloudWatch or GCP Cloud Logging may be involved in audit-log collection.

Therefore, organizations with strict data residency requirements should evaluate the complete architecture rather than considering only the location of the protected workload.


38. Multicloud Security and Least Privilege

A strong multicloud architecture follows least privilege.

Defender for Cloud should receive only the permissions required for the selected capabilities.

At the same time, administrators should avoid granting so little access that required security functionality cannot operate.

The balance is:

Too many permissions
↓
Unnecessary risk
Too few permissions
↓
Incomplete security visibility/protection
Appropriate permissions
↓
Required security capabilities
+
Least privilege

This is an important security-design principle and an important SC-500 exam concept.


39. Common Multicloud Security Scenario

Consider an organization with:

  • 500 Azure VMs
  • 200 AWS EC2 instances
  • 100 GCP Compute Engine VMs
  • 10 AKS clusters
  • 5 EKS clusters
  • 4 GKE clusters

The organization wants centralized security.

A reasonable architecture is:

Azure

Use Defender for Cloud directly.

AWS

Connect the AWS account and use:

  • Defender CSPM for posture management
  • Defender for Servers for EC2 protection
  • Defender for Containers for EKS

GCP

Connect the GCP project and use:

  • Defender CSPM
  • Defender for Servers
  • Defender for Containers for GKE

On-premises

Use:

  • Azure Arc-enabled servers
  • Appropriate Defender plans

This provides a unified security-management model without moving workloads between clouds.


40. Common Mistakes to Avoid

Mistake 1: Thinking Azure Arc is required for CSPM

It isn’t.

Multicloud CSPM is primarily agentless.


Mistake 2: Thinking connecting AWS automatically protects every EC2 instance

The connector provides the connection and discovery foundation.

The appropriate Defender workload protection plan and required components must also be configured.


Mistake 3: Confusing an AWS account with an Azure subscription

AWS uses accounts.

Azure uses subscriptions.

The AWS account is connected to Defender for Cloud through an Azure subscription.


Mistake 4: Confusing a GCP project with an Azure subscription

GCP uses projects.

Azure uses subscriptions.

The GCP project is connected to Defender for Cloud through an Azure subscription.


Mistake 5: Assuming long-lived AWS credentials are required

Defender for Cloud uses federated authentication and short-lived credentials for AWS.


Mistake 6: Assuming every Defender plan is multicloud

Some Defender plans are designed for Azure-specific workloads.

Always verify plan support for the cloud and workload in question.


Mistake 7: Ignoring Azure Arc

For many CWPP scenarios involving AWS/GCP servers, Azure Arc is an important dependency.


Mistake 8: Forgetting connector permissions

A connector can exist but still have insufficient permissions to perform all configured security functions.


Mistake 9: Forgetting network requirements

Agents and extensions must be able to communicate with the required services.


Mistake 10: Not verifying coverage

A healthy connector does not necessarily mean every intended workload is protected.

Always validate coverage.


41. SC-500 Decision Matrix

ScenarioPrimary consideration
Assess AWS security postureAWS connector + CSPM
Assess GCP security postureGCP connector + CSPM
Protect AWS EC2AWS connector + Defender for Servers
Protect GCP Compute EngineGCP connector + Defender for Servers
Protect AWS EKSDefender for Containers
Protect GCP GKEDefender for Containers
Protect SQL Server on AWS/GCPDefender for SQL + Azure Arc
Connect on-premises serverAzure Arc
Avoid long-lived AWS credentialsFederated authentication
Deploy AWS connectorCloudFormation or Terraform
Deploy GCP connectorCloud Shell or Terraform
Verify connector statusConnector health
Verify resource coverageCoverage workbook
Minimize cloud permissionsLeast-privilege access
Centralize multicloud securityDefender for Cloud
Runtime protection for non-Azure serverCWPP + appropriate agents/Arc

42. A Complete Multicloud Deployment Workflow

A strong enterprise implementation can follow this sequence.

Step 1 — Identify environments

Inventory:

  • Azure subscriptions
  • AWS accounts
  • GCP projects
  • On-premises servers
  • Kubernetes clusters
  • Database workloads

Step 2 — Identify security requirements

Determine whether the organization needs:

  • CSPM
  • CWPP
  • Vulnerability assessment
  • Runtime protection
  • Container security
  • SQL protection
  • Compliance assessment
  • Identity analysis

Step 3 — Establish connectors

Connect:

  • AWS accounts
  • GCP projects
  • Other supported environments

Step 4 — Configure authentication

Use federated authentication rather than long-lived cloud credentials.

Step 5 — Configure permissions

Use the minimum permissions required for the selected plans.

Step 6 — Enable Defender plans

Select appropriate workload protection plans.

Step 7 — Deploy Azure Arc where required

For supported CWPP scenarios, onboard machines or Kubernetes clusters through Azure Arc.

Step 8 — Configure agents and extensions

Deploy required:

  • Defender for Endpoint components
  • Defender sensor
  • Azure Policy for Kubernetes
  • Other required extensions

Step 9 — Verify networking

Confirm required outbound connectivity.

Step 10 — Validate connectors

Check connector health.

Step 11 — Validate coverage

Review the Coverage workbook and resource inventory.

Step 12 — Monitor

Review:

  • Recommendations
  • Alerts
  • Security posture
  • Workload protection
  • Compliance

Step 13 — Remediate

Address security findings and protection gaps.


43. SC-500 Key Concepts to Memorize

The following concepts are especially likely to be useful when answering scenario-based questions.

Concept 1

CSPM = posture management

Concept 2

CWPP = workload protection

Concept 3

CSPM for AWS/GCP = primarily agentless

Concept 4

AWS/GCP server protection = Azure Arc is important

Concept 5

AWS authentication = federated authentication + short-lived credentials

Concept 6

AWS deployment = CloudFormation or Terraform

Concept 7

GCP deployment = Cloud Shell or Terraform

Concept 8

AWS EC2 = Defender for Servers

Concept 9

GCP Compute Engine = Defender for Servers

Concept 10

AWS EKS = Defender for Containers

Concept 11

GCP GKE = Defender for Containers

Concept 12

On-premises servers = Azure Arc

Concept 13

Connector ≠ complete workload protection

Concept 14

Coverage must be verified after onboarding


44. Key Takeaways

Microsoft Defender for Cloud provides a unified security model across Azure, AWS, GCP, and hybrid environments.

The most important SC-500 concepts are:

  1. AWS accounts and GCP projects can be connected directly to Defender for Cloud.
  2. Defender for Cloud provides CSPM capabilities across AWS and GCP.
  3. Multicloud CSPM is primarily agentless.
  4. CWPP provides deeper workload protection.
  5. Azure Arc is important for many non-Azure CWPP scenarios.
  6. AWS authentication uses federated trust and short-lived credentials.
  7. GCP also uses federated authentication for its connector.
  8. AWS connector deployment can use CloudFormation or Terraform.
  9. GCP connector deployment can use Cloud Shell or Terraform.
  10. Defender for Servers can protect supported AWS EC2 and GCP Compute Engine machines.
  11. Defender for Containers can protect supported EKS and GKE environments.
  12. Different Defender plans have different dependencies.
  13. Connector permissions must be sufficient for the enabled plans.
  14. Least-privilege access reduces unnecessary permissions.
  15. Azure Arc does not move a workload into Azure.
  16. Connecting an environment does not automatically mean every workload is protected.
  17. Connector health should be validated.
  18. Coverage should be verified after onboarding.
  19. Networking requirements must be satisfied for agents and extensions.
  20. The goal is unified security management without requiring workloads to migrate to Azure.

The most useful mental model for the exam is:

Connect → Authenticate → Authorize → Assess → Protect → Verify

Or, more specifically:

AWS/GCP connector → federated identity → appropriate permissions → CSPM → Azure Arc/CWPP where required → verify coverage


Practice Exam Questions

Question 1

A company has several AWS accounts and wants Microsoft Defender for Cloud to identify security misconfigurations and assess its AWS environment. The company does not want to install agents on its AWS resources.

What should the security engineer implement?

A. Azure Arc on every AWS resource

B. Defender for Servers Plan 2 on every EC2 instance

C. An AWS connector with Defender CSPM

D. Microsoft Defender for Endpoint on every AWS resource

Answer: C. An AWS connector with Defender CSPM

Explanation: Defender for Cloud provides CSPM capabilities for AWS through the AWS connector, and multicloud CSPM is primarily agentless. Azure Arc and endpoint agents are relevant to deeper workload-protection scenarios, but they aren’t required simply to perform the core CSPM assessment.


Question 2

A security engineer needs to protect EC2 instances in an AWS account using Microsoft Defender for Servers. The organization wants to take advantage of the full Defender for Servers functionality available for its multicloud machines.

Which technology should the engineer use to onboard the machines?

A. Azure Arc-enabled servers

B. Azure Bastion

C. Azure VPN Gateway

D. Microsoft Sentinel agents

Answer: A. Azure Arc-enabled servers

Explanation: Microsoft recommends onboarding AWS and GCP machines as Azure Arc-enabled machines to take full advantage of Defender for Servers. The multicloud connector can automatically onboard the Azure Arc agent as part of the connection process.


Question 3

An organization is connecting an AWS account to Defender for Cloud. The security team has a requirement that Defender for Cloud must not store long-lived AWS access credentials.

Which authentication mechanism should be used?

A. A permanent AWS access key stored in Azure Key Vault

B. Federated authentication using OIDC and short-lived AWS credentials

C. A shared IAM user account with a permanent password

D. An Azure Storage account containing AWS credentials

Answer: B. Federated authentication using OIDC and short-lived AWS credentials

Explanation: Defender for Cloud uses federated authentication when connecting to AWS. The architecture establishes a trust relationship involving Microsoft Entra ID, OIDC, AWS IAM roles, and AWS STS so that Defender for Cloud can obtain short-lived credentials rather than relying on long-lived secrets.


Question 4

A company has deployed several workloads in Google Cloud Platform. The security team wants Defender for Cloud to discover GCP resources and assess their security posture without deploying agents to each resource.

What should the security team configure?

A. Defender for Servers on every GCP VM

B. Azure Arc on every GCP resource

C. Microsoft Defender for Endpoint on every GCP resource

D. A GCP connector with the appropriate CSPM configuration

Answer: D. A GCP connector with the appropriate CSPM configuration

Explanation: Defender for Cloud can perform CSPM for GCP through the GCP connector using primarily agentless techniques. Azure Arc and workload agents become relevant when deeper workload protection is required.


Question 5

An organization has connected an AWS account to Defender for Cloud. The security team wants to protect Amazon EKS clusters against vulnerabilities and runtime threats.

Which Defender for Cloud capability should be enabled?

A. Defender for Containers

B. Defender for Storage

C. Defender for Key Vault

D. Defender for App Service

Answer: A. Defender for Containers

Explanation: Defender for Containers provides protection for supported Kubernetes environments, including Amazon EKS. Multicloud container protection can include Azure Arc, the Defender sensor, Azure Policy for Kubernetes, audit logs, and agentless capabilities depending on the selected configuration.


Question 6

An organization is onboarding a large AWS environment to Defender for Cloud. The security team wants the connector to grant only the permissions currently required by the selected Defender plans.

Which access model should the team select?

A. Default access

B. Owner access

C. Least-privilege access

D. Contributor access

Answer: C. Least-privilege access

Explanation: Least-privilege access grants Defender for Cloud only the permissions required for the currently selected capabilities. This reduces unnecessary permissions. One trade-off is that when new Defender capabilities or permissions are required, the deployment artifact may need to be updated and redeployed.


Question 7

An organization connects a GCP project to Defender for Cloud. It wants to protect GCP Compute Engine virtual machines using Defender for Servers.

Which combination is most appropriate for obtaining the full Defender for Servers functionality?

A. GCP connector only

B. GCP connector plus Azure Arc onboarding

C. Azure Bastion plus VPN Gateway

D. Microsoft Sentinel plus Azure Firewall

Answer: B. GCP connector plus Azure Arc onboarding

Explanation: Connecting the GCP project provides the multicloud integration, while Azure Arc provides the bridge needed for full Defender for Servers functionality on supported GCP machines. Microsoft recommends Azure Arc onboarding for GCP and AWS machines protected by Defender for Servers.


Question 8

A security administrator has successfully connected an AWS account to Defender for Cloud. The connector reports as healthy, but the administrator wants to determine whether the expected AWS resources are actually covered by the enabled Defender plans.

What should the administrator do?

A. Review the Coverage workbook

B. Create a new Azure Policy initiative

C. Enable Azure Bastion

D. Review Azure Service Health

Answer: A. Review the Coverage workbook

Explanation: Connector health confirms that the connection is functioning, but coverage verification determines whether the expected resources are actually protected by the appropriate plans. Defender for Cloud provides coverage workbooks for this purpose.


Question 9

A company has SQL Server databases running on virtual machines in AWS and GCP. The security team wants to use Microsoft Defender for Cloud to provide SQL threat protection for these workloads.

Which approach is appropriate?

A. Enable Defender for Storage on the AWS and GCP accounts

B. Enable Defender for APIs on the Azure subscription

C. Use Defender for SQL with Azure Arc-enabled machines

D. Deploy Azure Firewall to both cloud environments

Answer: C. Use Defender for SQL with Azure Arc-enabled machines

Explanation: Defender for SQL supports SQL workloads running on supported AWS and GCP machines. For multicloud SQL Server scenarios, Azure Arc connects the machines to Azure, allowing Defender for Cloud to provide the required SQL protection capabilities.


Question 10

A company wants to connect its GCP environment to Defender for Cloud. The security team wants to avoid storing long-lived GCP credentials for Defender for Cloud to use when accessing GCP APIs.

Which approach is most appropriate?

A. Create a permanent GCP service-account password

B. Store a GCP private key in an Azure VM

C. Create an AWS IAM role and use it for GCP authentication

D. Use the federated authentication architecture provided by the GCP connector

Answer: D. Use the federated authentication architecture provided by the GCP connector

Explanation: The Defender for Cloud GCP connector uses federated authentication to access GCP APIs without storing long-lived credentials. This provides a more secure cross-cloud trust model while allowing Defender for Cloud to perform the required discovery and security operations.


Final SC-500 Exam Reminder

When you encounter a hybrid or multicloud Defender for Cloud question, work through these questions in order:

1. What cloud is involved?

  • Azure
  • AWS
  • GCP
  • On-premises

2. What is being requested?

  • CSPM?
  • Compliance?
  • Vulnerability assessment?
  • Server protection?
  • Container protection?
  • SQL protection?

3. Is the capability agentless?

If the question is primarily about CSPM, think:

Connector + agentless assessment

4. Does the scenario require workload protection?

If so, think:

Appropriate Defender plan + required components

5. Is Azure Arc required?

For many non-Azure server and Kubernetes CWPP scenarios:

Yes, Azure Arc is an important dependency.

6. How is authentication performed?

For AWS and GCP:

Federated authentication

Avoid answers based on permanently stored cloud credentials.

7. What scope is involved?

Remember:

Azure = Subscription

AWS = Account

GCP = Project

8. How do you know it is working?

Look for:

Connector health + resource inventory + coverage verification

The core SC-500 mental model is:

Connect → Federate → Authorize → Assess → Protect → Verify

That sequence captures much of what Microsoft is testing in this portion of the exam.

This topic is important because the current SC-500 material treats multicloud security as more than simply “connecting AWS and GCP.” The exam can test the distinction between agentless CSPM and Arc-enabled CWPP, the authentication model, cloud-specific permissions, workload-specific Defender plans, and the process of verifying that protection is actually in place.


Go to the SC-500 Exam Prep Hub main page