Tag: Hybrid Cloud Security

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