Category: Cloud computing

azure, Cloud computing, Cybersecurity, Microsoft Certification, SC-500, security October 10, 2026

Enable and configure Defender for Cloud workload protection plans (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
      --> Enable and configure Defender for Cloud workload protection plans

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

Microsoft Defender for Cloud provides security capabilities for cloud environments from security posture management through active workload protection.

For the SC-500 exam, an important distinction is between:

Cloud Security Posture Management (CSPM) — identifies security weaknesses, misconfigurations, exposure, and compliance gaps.
Cloud Workload Protection Platform (CWPP) — provides workload-specific threat protection and security capabilities for resources such as servers, containers, databases, storage, applications, APIs, and AI services.

Defender for Cloud’s workload protection plans are enabled according to the types of workloads an organization needs to protect. These plans provide capabilities such as threat detection, vulnerability assessment, runtime protection, malware scanning, and other workload-specific security controls.

For the SC-500 exam, you should understand which Defender plan protects which workload, how to enable the plan, how to configure important plan-specific settings, how to deploy plans at scale, and how to verify coverage.

1. What Is Cloud Workload Protection?

Cloud workload protection focuses on protecting workloads while they are running, rather than simply identifying whether their configuration is secure.

For example:

Workload	Potential Security Concern	Relevant Defender Capability
Virtual machines	Malware, vulnerabilities, suspicious activity	Defender for Servers
Kubernetes	Vulnerable containers, runtime attacks	Defender for Containers
Azure Storage	Malicious uploads, data threats	Defender for Storage
Azure SQL	Database attacks and vulnerabilities	Defender for Databases
App Service	Attacks against web applications	Defender for App Service
APIs	API vulnerabilities and attacks	Defender for APIs
Key Vault	Suspicious access to secrets and keys	Defender for Key Vault
AI services	Threats against generative AI applications	Defender for AI Services
Azure resource management	Suspicious resource-management operations	Defender for Resource Manager
DNS	DNS-layer threats	Defender for DNS

The important SC-500 concept is that you select protection plans based on the workloads that exist in your environment.

Defender for Cloud currently provides a broad catalog of workload-specific protection plans, including servers, containers, storage, databases, Key Vault, App Service, APIs, AI Services, DNS, and Resource Manager.

2. CSPM vs. CWPP

One of the most important distinctions for the exam is the difference between CSPM and workload protection.

Cloud Security Posture Management

CSPM answers questions such as:

“Is this environment configured securely?”

Examples include:

Is a storage account publicly accessible?
Is encryption configured?
Is a network security control missing?
Does a resource violate a security policy?
Does the environment have excessive risk?

Defender for Cloud’s foundational CSPM capabilities include recommendations, asset inventory, workbooks, Secure Score, and Microsoft cloud security benchmark capabilities.

Cloud Workload Protection

CWPP answers questions such as:

“Is this workload currently protected against threats?”

Examples include:

Is a VM protected against malware and endpoint threats?
Is a Kubernetes cluster receiving runtime threat detection?
Is malicious content being detected when uploaded to storage?
Are suspicious database activities being detected?
Are API attacks being detected?
Are AI workloads receiving threat protection?

Exam tip:

CSPM focuses primarily on improving security posture.
CWPP focuses primarily on protecting workloads from active threats.

In real environments, the two capabilities complement each other rather than replacing one another.

3. Defender for Cloud Workload Protection Plans

Defender for Cloud contains multiple workload-specific plans.

Some of the important plans for SC-500 include:

Defender for Servers

Protects physical and virtual machines across Azure and supported multicloud environments.

Defender for Servers provides capabilities such as:

Threat detection
Endpoint protection integration
Vulnerability assessment
Security recommendations
Agentless scanning
Additional Plan 2 capabilities

Defender for Servers is available as Plan 1 (P1) and Plan 2 (P2).

Defender for Containers

Protects Kubernetes environments, including supported Azure Kubernetes Service, Amazon EKS, Google GKE, and Azure Arc-enabled Kubernetes environments.

Depending on the environment and configuration, capabilities can include:

Vulnerability scanning
Runtime threat protection
Security posture assessments
Agentless scanning
Defender sensor
Kubernetes API access
Registry access

The exact components available depend on the Kubernetes environment and configuration.

Defender for Storage

Defender for Storage provides security monitoring and threat detection for Azure Storage.

The current plan includes capabilities such as:

Activity monitoring
On-upload malware scanning
Sensitive-data threat detection

Malware scanning can also be configured with options such as scanning limits, filtering, scan-result storage, and automated integration through Event Grid or Log Analytics.

Defender for Databases

Defender for Databases protects supported database workloads.

For example, Defender for Azure SQL Databases provides attack detection and threat-response capabilities for Azure SQL databases.

The broader database protection capabilities also include support for other database workloads, depending on the specific Defender plan and supported environment.

For SQL Server running on machines, the SQL Servers on Machines protection is selected within the Defender for Databases plan.

Defender for App Service

Defender for App Service provides protection for applications running on Azure App Service.

It is designed to identify attacks targeting App Service web applications and APIs.

Defender for APIs

Defender for APIs provides security visibility and protection for APIs managed through Azure API Management.

Capabilities include:

API discovery
Security posture assessment
Vulnerability prioritization
Threat detection
Runtime protection

Defender for APIs is enabled at the subscription level, and the appropriate plan should be selected based on API traffic requirements.

Important exam consideration: enabling Defender for APIs does not automatically mean that every API in existence is protected. The APIs must be onboarded appropriately, and the APIs you want to protect must be published through Azure API Management.

Defender for Key Vault

Defender for Key Vault detects unusual and potentially harmful attempts to access or exploit Key Vault accounts.

This is particularly important because Key Vault can contain highly sensitive:

Secrets
Encryption keys
Certificates

The purpose is not simply to encrypt the vault. Defender for Key Vault adds threat-detection capabilities around access and usage.

Defender for AI Services

AI workloads introduce threats that traditional infrastructure security controls may not completely address.

Defender for AI Services provides threat protection for generative AI applications and can detect suspicious activity involving supported AI services.

For SC-500, remember:

AI workloads are now explicitly part of the Defender for Cloud workload-protection model.

This is especially relevant because the SC-500 certification focuses on cloud and AI workloads, rather than traditional cloud infrastructure alone.

Defender for Resource Manager

Defender for Resource Manager monitors Azure resource-management operations and can detect suspicious activity involving management operations.

This protects an important control plane:

The Azure Resource Manager layer through which resources are created, modified, and managed.

It is different from protecting a VM’s operating system or a storage account’s data plane.

Defender for DNS

Defender for DNS provides DNS-layer threat detection for Azure resources.

This illustrates another important Defender for Cloud concept:

Defender plans are specialized according to the attack surface being protected.

4. Choosing the Appropriate Defender Plan

A common SC-500 scenario is:

“An organization has identified a particular workload and wants to enable the appropriate Defender protection.”

The first step is to identify the workload.

For example:

Requirement	Appropriate plan
Protect Azure VMs	Defender for Servers
Protect AKS/Kubernetes	Defender for Containers
Detect malicious files uploaded to Storage	Defender for Storage
Protect Azure SQL databases	Defender for Databases
Protect App Service applications	Defender for App Service
Protect APIs managed through API Management	Defender for APIs
Detect suspicious Key Vault access	Defender for Key Vault
Protect generative AI services	Defender for AI Services
Detect suspicious Azure resource-management operations	Defender for Resource Manager
Detect DNS-based threats	Defender for DNS

The exam may deliberately include several plausible answers.

The key is to identify the workload, not simply the type of security problem.

5. Enabling Defender for Cloud

Before configuring individual workload protection plans, Defender for Cloud must be enabled for the relevant environment.

For Azure, Defender for Cloud can be accessed through the Azure portal.

Once the environment is available, the administrator can use:

Microsoft Defender for Cloud → Environment settings

From there, the administrator selects the relevant:

Azure subscription
AWS account
GCP project
Other supported environment/connector

The available Defender plans can then be configured for that environment.

6. Environment Settings

The Environment settings area is particularly important for SC-500.

It provides a centralized location for configuring Defender plans for the selected environment.

A typical workflow is:

Open Microsoft Defender for Cloud.
Select Environment settings.
Select the target environment.
Locate the desired Defender plan.
Turn the plan On.
Configure plan-specific settings.
Save the configuration.
Verify coverage.

For example, to enable Defender for Servers, you select the appropriate environment, turn on the Servers plan, choose the appropriate plan tier, and save the configuration.

7. Defender for Servers Plan 1 vs. Plan 2

Defender for Servers is especially important for the SC-500 exam because it contains two plan levels:

Plan 1
Plan 2

When enabling Defender for Servers, Plan 2 is selected by default in the current Azure portal workflow, but the administrator can change the selection to Plan 1.

The plans provide different levels of capability.

For example:

Capability	Plan 1	Plan 2
Defender for Endpoint integration	Yes	Yes
Vulnerability assessment	Yes	Yes
Agentless scanning	—	Yes
File integrity monitoring	—	Available
Additional advanced capabilities	Limited	More extensive

Current configuration guidance indicates that vulnerability assessment is enabled by default when either P1 or P2 is enabled, Defender for Endpoint integration is available with both, and agentless scanning is associated with Plan 2. File integrity monitoring is a Plan 2 capability that is not enabled by default.

Exam strategy

If a question specifically requires a Plan 2-only capability, Plan 1 is not sufficient.

Do not assume:

“Servers enabled = every Defender for Servers capability is enabled.”

Instead, identify the required capability and determine which plan provides it.

8. Configuring Defender for Servers

After enabling Defender for Servers, plan-specific settings can be configured.

Examples include:

Vulnerability assessment

Helps identify vulnerable software and applications on protected machines.

Endpoint protection

Defender for Endpoint integration provides endpoint detection and response capabilities.

Agentless scanning

Agentless scanning can provide additional visibility without requiring a traditional security agent for certain scanning scenarios.

File integrity monitoring

File integrity monitoring can identify changes to important files and registries.

The availability and default state of these capabilities depend on the selected plan.

9. Defender for Storage Configuration

Defender for Storage provides several important configurable capabilities.

The current Defender for Storage plan includes:

Activity monitoring
Malware scanning
Sensitive-data threat detection

Malware scanning can be configured with options such as:

Monthly scanning caps
Scan filtering
Blob index tags for scan results
Soft deletion of malicious blobs
Event Grid integration
Log Analytics integration

Example

Suppose an organization uploads customer documents to Azure Blob Storage.

The security team wants to:

Detect malicious files immediately after upload.
Record scan results.
Automatically initiate downstream processing when malware is discovered.

Defender for Storage can provide the malware scanning capability, while Event Grid can be used to integrate scan results into automated response workflows.

10. Defender for Storage: Important Exam Distinction

Do not confuse:

Activity monitoring

with:

Malware scanning

Activity monitoring provides security analysis of activity involving storage.

Malware scanning specifically detects malicious files, including files uploaded to storage.

Similarly, sensitive-data threat detection addresses suspicious activity involving resources containing sensitive data.

Therefore, if an exam question says:

“Detect malicious files as they are uploaded to Blob Storage.”

The relevant capability is:

Defender for Storage with on-upload malware scanning.

11. Defender for Databases

Defender for Databases protects database workloads against threats and vulnerabilities.

For Azure SQL databases, Defender for Azure SQL Databases can be enabled through the Databases plan.

The administrator:

Opens Defender for Cloud.
Selects Environment settings.
Selects the relevant environment.
Locates Databases.
Selects Select types.
Enables Azure SQL Databases.
Selects Continue.
Saves the configuration.

This illustrates an important Defender for Cloud design:

A single high-level plan may contain multiple workload-specific resource types.

For example, Defender for Databases contains multiple database protection capabilities rather than representing only one specific database engine.

12. SQL Servers on Machines

SQL Server workloads may run on:

Azure virtual machines
Azure Arc-enabled servers

For SQL Servers on Machines, the protection is configured under the Defender for Databases plan.

The administrator can select the SQL Servers on Machines resource type within the Databases plan.

This is a useful exam distinction.

If a question describes:

“SQL Server installed on an Azure VM”

do not automatically treat it as the same configuration scenario as an Azure SQL Database.

The underlying workload type matters.

13. Defender for Containers

Defender for Containers protects Kubernetes environments.

Depending on the environment, administrators can configure components such as:

Agentless scanning
Defender sensor
Azure Policy
Kubernetes API access
Registry access

These capabilities support different aspects of container security.

For example:

Defender sensor

is associated with collecting runtime security telemetry used for threat detection.

Registry access

supports vulnerability assessment for container images in connected registries.

Azure Policy

supports Kubernetes security posture assessment and related recommendations.

Kubernetes API access

allows Defender for Cloud to obtain Kubernetes metadata required for inventory, configuration analysis, and related capabilities.

14. Defender for APIs

Defender for APIs provides protection for APIs managed through Azure API Management.

Its capabilities include:

Discovery
Security posture visibility
Vulnerability prioritization
Runtime threat detection
Response capabilities

One important configuration consideration is selecting the appropriate plan based on API traffic.

The current deployment guidance indicates that subscriptions are opted into Plan 1 by default and that organizations should select a plan appropriate for their API traffic volume to avoid unexpected overages.

Exam scenario

A company has a high-volume API platform.

The question asks what should be considered before selecting the Defender for APIs plan.

The best answer is likely to focus on:

API traffic volume and the plan entitlement associated with that traffic.

15. Defender for AI Services

AI workloads require specialized protection because they introduce risks beyond conventional infrastructure.

Defender for Cloud’s AI threat protection can provide:

AI workload discovery
Security posture capabilities
Runtime threat detection
Security alerts
Investigation capabilities

Microsoft’s current Defender for Cloud training specifically includes enabling and configuring the AI workloads plan and reviewing AI resource insights, posture, and runtime threats.

This is particularly important for SC-500 because AI security is integrated directly into the certification’s scope.

16. AI Threat Detection and Application Context

AI security can involve applications that sit between an end user and an AI service.

For example:

User → Web application → Azure OpenAI → Model

The AI service may see a request, but security investigators may need to understand:

Which user initiated it?
Which application generated it?
What source IP was involved?

Defender for Cloud’s AI threat protection can use additional security context to improve alert investigation. Microsoft documents the use of fields such as end-user identity, source IP, and application name for supported Azure OpenAI scenarios.

The important SC-500 concept is:

AI workload protection is not limited to infrastructure configuration; it can also provide runtime threat detection and investigation context.

17. Azure-Only vs. Multicloud Defender Plans

Not every Defender for Cloud workload plan applies to every cloud.

Some plans support Azure, AWS, and GCP workloads, while others are Azure-specific.

For example, current support information identifies these as Azure-only plans:

Defender for Storage
Defender for Key Vault
Defender for Resource Manager
Defender for DNS
Defender for App Service
Defender for APIs
Defender for AI Services

Defender for Servers and Defender for Containers, by contrast, have significant multicloud support.

Exam tip

If a question says:

“An organization wants to protect an AWS EC2 instance.”

Think about plans that support multicloud workloads, such as:

Defender for Servers

rather than Azure-only plans such as Defender for Storage.

18. Subscription-Level vs. Resource-Level Configuration

Defender for Cloud supports different deployment scopes depending on the plan.

A common approach is to enable a workload protection plan at the subscription level.

This is generally easier to manage and provides broader coverage.

Some scenarios also support resource-level configuration.

For example, Defender for Servers can be configured at different scopes, although Microsoft recommends subscription-level deployment for many scenarios.

However, resource-level configuration can be useful when:

Different workloads require different protection levels.
Specific resources need to be excluded.
An organization is transitioning workloads.
Different security requirements exist within the same subscription.

Important exam concept

Do not assume every Defender plan supports the same resource-level configuration options.

Always evaluate the specific plan.

19. Management Group Deployment

Large organizations often have many subscriptions.

Enabling every Defender plan manually on every subscription can be inefficient.

Defender for Cloud can be managed at larger scopes, including management groups, where supported.

This enables organizations to establish consistent protection across a portfolio of subscriptions.

The basic enterprise pattern is:

Management Group

↓

Subscriptions

↓

Workloads

The objective is centralized governance combined with consistent security coverage.

20. Deploying Defender Plans at Scale

Azure Policy can be used to help configure Defender for Cloud plans at scale.

Microsoft provides built-in policy initiatives for configuring Defender plans.

For example, there are built-in policies for:

Defender for Servers
Defender for Containers
Defender for Storage
Defender for Databases
Defender for APIs
Defender for AI Services
Defender CSPM
Other Defender capabilities

This is especially valuable when an organization wants to enforce security requirements consistently.

Example

An organization has 50 Azure subscriptions and wants Defender for Storage enabled consistently.

Instead of manually configuring each subscription, the organization can use an appropriate Azure Policy assignment to configure the plan at scale.

21. Azure Policy and Defender Plans

An important distinction is:

Azure Policy

can be used to enforce or deploy configurations.

Defender for Cloud

provides the security-management and workload-protection capabilities.

They work together.

For example, a policy can require that Defender for Storage be enabled.

The policy can evaluate the environment and deploy the appropriate configuration where applicable. Microsoft provides a built-in policy specifically for configuring Defender for Storage with its available capabilities.

22. Verifying Protection Coverage

Enabling a Defender plan is not the final step.

Security administrators should verify that the intended resources are actually covered.

Defender for Cloud provides a Coverage workbook that shows which plans are enabled and provides insight into coverage across subscriptions and resources.

A good operational workflow is:

Select plan

↓

Enable plan

↓

Configure plan-specific settings

↓

Deploy required components

↓

Verify coverage

↓

Review alerts/recommendations

↓

Remediate gaps

23. Why Verification Matters

Consider this scenario:

An administrator enables Defender for Servers at the subscription level.

They assume every VM is protected.

However:

Some resources may have different configuration.
Some resources may be excluded.
Required components may not be deployed.
Resource-level settings may override broader settings.
Multicloud resources may require appropriate onboarding.

Therefore:

Turning a Defender plan on is not the same thing as proving that every intended workload is protected.

The Coverage workbook is designed to help validate the actual deployment state.

24. Monitoring Workload Protection

Defender for Cloud provides workload protection insights and security alerts.

The Workload protections area can show the status of advanced protection for workloads such as:

Virtual machines
SQL databases
Containers
Web applications
Other supported workload types

Security alerts can provide:

Affected resource
Threat information
Suggested remediation
Additional investigation information
In some cases, automated response options

This allows security teams to move from:

Protection configuration

to:

Threat detection and response

25. Important Licensing and Cost Considerations

Many workload protection plans are paid capabilities.

Before enabling a plan broadly, an organization should understand:

Which workloads will be protected
Which features will be enabled
Which resources are in scope
Whether the plan has multiple tiers
Whether optional features incur additional costs
Expected usage
How long the plan will remain enabled

For example, Defender for Storage includes configurable malware-scanning capabilities, and Defender for APIs has plan selection considerations based on API traffic.

Exam strategy

If a scenario asks for the best security configuration, do not automatically choose the least expensive option.

First satisfy the security requirement.

If the question specifically introduces cost as a constraint, then cost becomes part of the decision.

26. Common SC-500 Workload Protection Scenarios

Scenario 1 — Virtual machines

Requirement: Detect vulnerabilities and protect Azure VMs.

Solution: Defender for Servers.

Scenario 2 — Kubernetes

Requirement: Detect container vulnerabilities and runtime threats in AKS.

Solution: Defender for Containers.

Scenario 3 — Malicious file uploads

Requirement: Detect malicious files uploaded to Blob Storage.

Solution: Defender for Storage with malware scanning.

Scenario 4 — Azure SQL

Requirement: Detect suspicious activity against Azure SQL databases.

Solution: Defender for Databases with Azure SQL Database protection enabled.

Scenario 5 — SQL Server on VM

Requirement: Protect SQL Server running on an Azure VM.

Solution: Configure the SQL Servers on Machines capability within Defender for Databases.

Scenario 6 — API attacks

Requirement: Discover and detect threats against APIs hosted through Azure API Management.

Solution: Defender for APIs.

Scenario 7 — AI threats

Requirement: Detect runtime threats targeting generative AI services.

Solution: Defender for AI Services.

Scenario 8 — Suspicious Azure management activity

Requirement: Detect suspicious Azure resource-management operations.

Solution: Defender for Resource Manager.

27. Common Mistakes to Avoid

Mistake 1: Confusing CSPM with workload protection

CSPM identifies posture weaknesses.

CWPP provides workload-specific protection.

Mistake 2: Enabling the wrong plan

A plan should be selected based on the workload being protected.

Mistake 3: Assuming one Defender plan protects everything

Defender for Cloud uses specialized plans for different workload categories.

Mistake 4: Assuming “On” means every feature is enabled

Some plans contain configurable components and tiers.

Mistake 5: Ignoring plan tiers

Defender for Servers has P1 and P2.

If a scenario requires a Plan 2 capability, enabling P1 is insufficient.

Mistake 6: Forgetting multicloud scope

Some Defender plans support AWS and GCP while others are Azure-only.

Mistake 7: Ignoring API traffic

Defender for APIs plan selection should take API traffic volume into account.

Mistake 8: Forgetting Storage malware scanning

Enabling Defender for Storage and enabling/configuring malware scanning are related but distinct considerations.

Mistake 9: Failing to verify coverage

Always verify that intended workloads are actually protected.

Mistake 10: Treating recommendations as runtime protection

A security recommendation identifies a security weakness.

A workload protection plan provides additional protection against threats.

They complement one another.

28. SC-500 Exam Comparison Table

Requirement	Think About
Improve overall cloud security posture	CSPM
Improve Secure Score	CSPM
Identify misconfigurations	CSPM
Protect Azure VMs	Defender for Servers
Protect Kubernetes	Defender for Containers
Detect malicious files in Storage	Defender for Storage
Protect Azure SQL	Defender for Databases
Protect SQL Server on machines	Defender for Databases → SQL Servers on Machines
Protect App Service	Defender for App Service
Protect APIs	Defender for APIs
Protect Key Vault	Defender for Key Vault
Protect generative AI services	Defender for AI Services
Detect suspicious Azure management activity	Defender for Resource Manager
Detect DNS threats	Defender for DNS
Apply configuration consistently at scale	Azure Policy
Verify plan/resource coverage	Coverage workbook

29. Recommended Deployment Method

For an enterprise environment, a strong implementation approach is:

Step 1 — Inventory workloads

Identify:

VMs
Containers
Storage
Databases
APIs
App Services
Key Vaults
AI services
Other cloud workloads

Step 2 — Map workloads to Defender plans

Determine which workload protection plan applies to each workload.

Step 3 — Determine scope

Decide whether protection should apply at:

Management group
Subscription
Resource
Connected multicloud environment

Step 4 — Select appropriate tiers

For plans with multiple tiers, select the tier that satisfies the security requirement.

Step 5 — Configure plan-specific features

Examples include:

Server vulnerability assessment
Server agentless scanning
Storage malware scanning
Storage sensitive-data detection
Container runtime protection
Container registry scanning
API plan selection
AI threat protection

Step 6 — Automate deployment

Use Azure Policy where appropriate to establish consistent deployment at scale.

Step 7 — Verify coverage

Use Defender for Cloud’s Coverage workbook.

Step 8 — Monitor

Review:

Security alerts
Recommendations
Coverage
Workload protection status

Step 9 — Remediate

Address identified vulnerabilities and configuration gaps.

30. Key Takeaways

For the SC-500 exam, remember these principles:

Defender for Cloud combines CSPM and workload protection capabilities.
CWPP plans are workload-specific.
Choose the Defender plan based on the workload that needs protection.
Defender for Servers has Plan 1 and Plan 2.
Plan 2 provides additional advanced server protection capabilities.
Defender for Storage can provide malware scanning and sensitive-data threat detection.
Defender for Databases protects supported database workloads.
Defender for Containers protects Kubernetes environments.
Defender for APIs protects APIs managed through Azure API Management.
Defender for AI Services provides specialized protection for supported AI workloads.
Not every Defender plan supports AWS and GCP.
Azure Policy can help deploy Defender plans consistently at scale.
Enabling a plan is not the same as verifying coverage.
Use the Coverage workbook to validate deployment coverage.
Always distinguish posture management from active workload protection.

The central exam concept is simple:

Identify the workload → select the appropriate Defender plan → choose the required tier/features → deploy at the appropriate scope → verify coverage → monitor and remediate.

Practice Exam Questions

Question 1

An organization has several Azure virtual machines. The security team wants to detect vulnerabilities, integrate endpoint protection, and provide additional threat protection for the machines.

Which Microsoft Defender for Cloud plan should the organization enable?

A. Defender for Servers

B. Defender for Storage

C. Defender for APIs

D. Defender for Key Vault

Answer: A. Defender for Servers

Explanation: Defender for Servers is the workload protection plan designed for server and machine workloads. It provides capabilities such as vulnerability assessment and Defender for Endpoint integration. Defender for Storage protects storage accounts, Defender for APIs protects APIs, and Defender for Key Vault protects Key Vault resources.

Question 2

A security administrator needs to protect an AKS environment against container vulnerabilities and runtime threats.

Which Defender for Cloud plan should be configured?

A. Defender for App Service

B. Defender for Resource Manager

C. Defender for Servers

D. Defender for Containers

Answer: D. Defender for Containers

Explanation: Defender for Containers is designed to protect Kubernetes environments such as AKS. Depending on the configuration, it can provide vulnerability assessment, runtime threat protection, posture assessment, agentless scanning, registry assessment, and other Kubernetes security capabilities. Defender for Servers is intended primarily for machine workloads.

Question 3

A company uploads documents to Azure Blob Storage. The security team wants Defender for Cloud to identify malicious files when they are uploaded.

Which capability should be configured?

A. Defender for Storage malware scanning

B. Defender for Databases

C. Defender for Key Vault

D. Defender for APIs

Answer: A. Defender for Storage malware scanning

Explanation: Defender for Storage provides on-upload malware scanning for supported storage workloads. The capability is specifically intended to detect malicious files uploaded to storage. Defender for Key Vault, Databases, and APIs address different workload types.

Question 4

An organization enables Defender for Servers and needs a capability that is associated with Plan 2 rather than Plan 1.

Which plan should the organization select?

A. Foundational CSPM

B. Defender for Servers Plan 1

C. Defender CSPM

D. Defender for Servers Plan 2

Answer: D. Defender for Servers Plan 2

Explanation: Defender for Servers has Plan 1 and Plan 2. Plan 2 provides additional advanced capabilities, including agentless scanning. File integrity monitoring is also available as a Plan 2 capability, although it isn’t enabled by default.

Question 5

A company uses Azure API Management and wants to discover APIs, assess their security posture, prioritize API vulnerabilities, and detect active API threats.

Which Defender for Cloud plan should be used?

A. Defender for APIs

B. Defender for App Service

C. Defender for Containers

D. Defender for Resource Manager

Answer: A. Defender for APIs

Explanation: Defender for APIs provides discovery, security posture visibility, vulnerability prioritization, and runtime threat detection for APIs managed through Azure API Management. The APIs must be appropriately onboarded, and plan selection should account for API traffic requirements.

Question 6

An organization wants to apply Microsoft Defender for Cloud workload protection configurations consistently across a large number of Azure subscriptions.

Which service is most appropriate for enforcing configuration at scale?

A. Azure Bastion

B. Azure Policy

C. Azure Monitor

D. Azure DNS

Answer: B. Azure Policy

Explanation: Azure Policy can be used to enforce and deploy security configurations consistently across Azure resources and subscriptions. Microsoft provides built-in policy definitions and initiatives for configuring various Defender for Cloud plans, including Defender for Servers, Storage, Containers, APIs, AI Services, and others.

Question 7

A security engineer wants to verify which subscriptions and resources are actually covered by the Defender for Cloud plans that have been enabled.

Which capability should the engineer use?

A. Secure Score

B. Regulatory Compliance dashboard

C. Coverage workbook

D. Azure Service Health

Answer: C. Coverage workbook

Explanation: The Defender for Cloud Coverage workbook provides visibility into which Defender plans are enabled and the resulting coverage across subscriptions and resources. This is particularly important because simply enabling a plan does not necessarily mean that every intended workload has been successfully protected.

Question 8

A company is deploying a generative AI application and wants specialized Defender for Cloud protection that can identify threats targeting supported AI services.

Which plan should the security team consider?

A. Defender for DNS

B. Defender for Key Vault

C. Defender for Storage

D. Defender for AI Services

Answer: D. Defender for AI Services

Explanation: Defender for AI Services provides specialized threat protection for supported generative AI services and applications. Defender for Cloud’s AI protection capabilities can provide discovery, posture assessment, runtime threat detection, and investigation capabilities for AI workloads.

Question 9

An organization has an Azure SQL Database and wants to enable Defender for Cloud’s attack detection and threat-response capabilities for that database.

Which configuration should the administrator use?

A. Defender for Databases with Azure SQL Databases enabled

B. Defender for Servers Plan 2

C. Defender for Storage

D. Defender for Containers

Answer: A. Defender for Databases with Azure SQL Databases enabled

Explanation: Azure SQL Database protection is configured through the Defender for Databases plan. The administrator selects the Databases plan and enables the Azure SQL Databases resource type. Defender for Servers is intended for machine workloads, while Storage and Containers address different workload categories.

Question 10

An organization has connected its AWS environment to Microsoft Defender for Cloud. The security team wants to protect Windows and Linux EC2 instances against threats.

Which Defender for Cloud plan is the best fit?

A. Defender for Storage

B. Defender for Servers

C. Defender for APIs

D. Defender for AI Services

Answer: B. Defender for Servers

Explanation: Defender for Servers supports multicloud machine workloads, including supported AWS and GCP machines. AWS and GCP machines use the appropriate Defender for Cloud onboarding mechanisms, including Azure Arc for supported server scenarios. Azure-only plans such as Defender for Storage, APIs, and AI Services are not the appropriate choice for protecting EC2 machines.

Final SC-500 Exam Reminder

When you see a Defender for Cloud workload-protection question, first ask:

“What workload am I protecting?”

Then map it to the appropriate plan:

Servers → Defender for Servers

Containers/Kubernetes → Defender for Containers

Storage → Defender for Storage

Databases → Defender for Databases

App Service → Defender for App Service

APIs → Defender for APIs

Key Vault → Defender for Key Vault

AI Services → Defender for AI Services

Resource management → Defender for Resource Manager

DNS → Defender for DNS

Then determine whether the question requires a particular plan tier, feature, deployment scope, or configuration option.

Finally, remember to verify actual coverage rather than assuming that enabling the plan means the deployment is complete.

This topic is important for SC-500 because Microsoft is increasingly treating AI workloads as a first-class security workload, so I would expect questions to test not only the traditional Servers/Storage/Databases/Containers plans but also Defender for AI Services, Defender for APIs, plan-specific configuration, and coverage verification.

Go to the SC-500 Exam Prep Hub main page

azure, Cloud computing, Cybersecurity, Microsoft Certification, SC-500, security October 10, 2026

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

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:

Capability	Primary purpose	Multicloud approach
CSPM	Identify security posture issues	Primarily agentless
CWPP	Protect workloads against threats	Often requires Azure Arc/agents/extensions
Azure Arc	Connect/manage supported non-Azure resources	Azure management plane
Defender plans	Add workload-specific protection	Depends 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:

Open Microsoft Defender for Cloud.
Navigate to the environment settings.
Select the option to connect an AWS account.
Specify the AWS account and Azure subscription information.
Select the Defender plans to enable.
Configure the required AWS permissions.
Deploy the required AWS resources.
Complete the connector configuration.
Validate connector health.
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:

Open Defender for Cloud.
Navigate to Environment settings.
Select the GCP connection option.
Select the Azure subscription.
Specify the GCP project or organization.
Configure the required GCP permissions.
Deploy the required GCP configuration.
Complete the connector configuration.
Validate connector health.
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

Characteristic	AWS	GCP
Connected to Defender for Cloud	Yes	Yes
CSPM support	Yes	Yes
CWPP support	Yes	Yes
Authentication	Federated	Federated
Long-lived cloud credentials required	No	No
Connector creates cloud-side security configuration	Yes	Yes
Infrastructure deployment	CloudFormation/Terraform	Cloud Shell/Terraform
Servers can use Azure Arc	Yes	Yes
Containers/Kubernetes supported	EKS	GKE
CSPM is primarily agentless	Yes	Yes

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:

Cloud	Kubernetes service	Defender for Containers
Azure	AKS	Yes
AWS	EKS	Yes
GCP	GKE	Yes

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 capability	Azure Arc	Agent/extension	Agentless capabilities
CSPM	No	No	Yes
Defender for Servers	Yes	MDE/other components	Yes
Defender for Containers	Yes for sensor-based capabilities	Defender sensor/Policy	Yes
Defender for SQL on Machines	Yes	SQL-related components	Limited

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:

Agent status
IAM permissions
Outbound network connectivity
Required endpoints
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

Scenario	Primary consideration
Assess AWS security posture	AWS connector + CSPM
Assess GCP security posture	GCP connector + CSPM
Protect AWS EC2	AWS connector + Defender for Servers
Protect GCP Compute Engine	GCP connector + Defender for Servers
Protect AWS EKS	Defender for Containers
Protect GCP GKE	Defender for Containers
Protect SQL Server on AWS/GCP	Defender for SQL + Azure Arc
Connect on-premises server	Azure Arc
Avoid long-lived AWS credentials	Federated authentication
Deploy AWS connector	CloudFormation or Terraform
Deploy GCP connector	Cloud Shell or Terraform
Verify connector status	Connector health
Verify resource coverage	Coverage workbook
Minimize cloud permissions	Least-privilege access
Centralize multicloud security	Defender for Cloud
Runtime protection for non-Azure server	CWPP + 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:

AWS accounts and GCP projects can be connected directly to Defender for Cloud.
Defender for Cloud provides CSPM capabilities across AWS and GCP.
Multicloud CSPM is primarily agentless.
CWPP provides deeper workload protection.
Azure Arc is important for many non-Azure CWPP scenarios.
AWS authentication uses federated trust and short-lived credentials.
GCP also uses federated authentication for its connector.
AWS connector deployment can use CloudFormation or Terraform.
GCP connector deployment can use Cloud Shell or Terraform.
Defender for Servers can protect supported AWS EC2 and GCP Compute Engine machines.
Defender for Containers can protect supported EKS and GKE environments.
Different Defender plans have different dependencies.
Connector permissions must be sufficient for the enabled plans.
Least-privilege access reduces unnecessary permissions.
Azure Arc does not move a workload into Azure.
Connecting an environment does not automatically mean every workload is protected.
Connector health should be validated.
Coverage should be verified after onboarding.
Networking requirements must be satisfied for agents and extensions.
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

azure, Cloud computing, Cybersecurity, Microsoft Certification, SC-500, security October 10, 2026

Configure Microsoft Defender Vulnerability Management settings for Azure VMs (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
      --> Configure Microsoft Defender Vulnerability Management settings for Azure VMs

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

Microsoft Defender Vulnerability Management (MDVM) is an important component of the security capabilities provided by Microsoft Defender for Cloud and Microsoft Defender for Servers. It helps security teams discover vulnerabilities in software installed on virtual machines, prioritize those vulnerabilities, and take action to reduce the organization’s exposure to known security risks.

One important current distinction is that Microsoft Defender Vulnerability Management (MDVM) is natively integrated with Defender for Servers, and Azure VM vulnerability scanning can now use both agent-based and agentless approaches depending on the Defender for Servers plan and configuration.

For the SC-500 exam, it is important to understand more than simply what a vulnerability scanner does. You should understand:

How Defender Vulnerability Management integrates with Defender for Servers
The difference between agent-based and agentless vulnerability scanning
The relationship between Defender for Servers Plan 1 (P1) and Plan 2 (P2)
How vulnerability assessment is enabled at subscription and machine scope
How to review vulnerability findings
How CVEs and severity information are used to prioritize remediation
How vulnerability findings can be managed when an organization has an accepted risk
The additional MDVM capabilities available with Defender for Servers Plan 2
How security baseline assessment and vulnerable application blocking fit into the overall solution

The current SC-500 study guide specifically includes configuring Defender for Servers settings such as vulnerability scanning and EDR, as well as implementing agentless VM scanning.

1. What Is Microsoft Defender Vulnerability Management?

Microsoft Defender Vulnerability Management is Microsoft’s vulnerability-management capability for continuously discovering and assessing vulnerabilities and helping organizations prioritize remediation.

Within Defender for Cloud, MDVM is integrated with Microsoft Defender for Endpoint and Defender for Servers.

This integration provides capabilities such as:

Software inventory
Vulnerability discovery
Vulnerability assessment
CVE identification
Risk-based prioritization
Security recommendations
Vulnerability remediation
Security baseline assessment
Premium vulnerability-management capabilities with Defender for Servers Plan 2

For servers protected by Defender for Servers, Defender Vulnerability Management is integrated natively rather than requiring a completely separate Microsoft vulnerability-management product.

Important SC-500 concept

Think of the relationship as:

Defender for Servers → integrates Defender for Endpoint + Defender Vulnerability Management

This allows Defender for Cloud to provide both:

Threat protection

and

Vulnerability management

for supported machines.

2. What Does Defender Vulnerability Management Scan?

Defender Vulnerability Management identifies vulnerabilities associated with software and configurations on machines.

For example, suppose an Azure VM is running:

Windows Server
IIS
.NET
Java
A third-party application

A vulnerability-management solution can identify vulnerable versions of installed software and associate them with known vulnerabilities such as Common Vulnerabilities and Exposures (CVEs).

Defender for Cloud then surfaces vulnerability information and recommendations that security teams can investigate and remediate.

A useful way to think about the process is:

Discover → Assess → Prioritize → Remediate → Verify

3. Defender Vulnerability Management and Defender for Servers

Defender Vulnerability Management scanning for Azure VMs is provided through the Defender for Servers plan.

Current Defender for Cloud documentation describes two primary vulnerability-scanning approaches:

Capability	Defender for Servers Plan 1	Defender for Servers Plan 2
Defender Vulnerability Management integration	Yes	Yes
Agent-based vulnerability scanning	Yes	Yes
Agentless vulnerability scanning	No	Yes
Premium MDVM capabilities	No	Yes
Security baseline assessment	No	Yes
Vulnerable application blocking	No	Yes
Other advanced Defender for Servers capabilities	Limited	Expanded

Defender for Servers Plan 2 includes the capabilities of Plan 1 plus additional functionality, including agentless scanning and premium Defender Vulnerability Management capabilities.

Exam tip

A common SC-500 question pattern is:

An organization wants vulnerability scanning without depending on an agent installed inside the VM. Which capability should be considered?

The key concept is:

Agentless vulnerability scanning → Defender for Servers Plan 2

4. Agent-Based Vulnerability Scanning

Agent-based scanning uses the Microsoft Defender for Endpoint integration.

The Defender for Endpoint sensor provides information that Defender Vulnerability Management can use to assess the machine.

Agent-based vulnerability scanning is available with:

Defender for Servers Plan 1
Defender for Servers Plan 2

The Defender for Endpoint integration is enabled by default when Defender for Servers is enabled, although individual plan settings can be modified.

Advantages

Agent-based scanning can provide:

Continuous vulnerability information
Software inventory
Vulnerability information
Endpoint security integration
Additional threat-detection capabilities through Defender for Endpoint

It is particularly useful when the organization already uses the Defender for Endpoint sensor as part of its endpoint-security architecture.

5. Agentless Vulnerability Scanning

Agentless scanning provides vulnerability visibility without requiring the traditional endpoint sensor for the vulnerability assessment itself.

This is particularly valuable when organizations want broader coverage while minimizing the need to install and maintain agents.

According to the current Defender for Cloud documentation, agentless vulnerability scanning is available with Defender for Servers Plan 2. It is also enabled by default when Defender for Servers Plan 2 or the Defender CSPM plan is enabled, subject to applicable requirements.

Why is agentless scanning important?

Consider an organization with hundreds of Azure VMs.

Installing and maintaining agents on every machine may introduce:

Deployment effort
Operational overhead
Additional dependencies
Potential compatibility concerns

Agentless scanning can provide vulnerability visibility without requiring the same agent-based deployment model.

6. Agent-Based vs. Agentless Scanning

This distinction is especially important for SC-500.

Characteristic	Agent-Based	Agentless
Requires Defender for Endpoint sensor	Yes	No
Defender for Servers P1	Supported	Not supported
Defender for Servers P2	Supported	Supported
Provides vulnerability assessment	Yes	Yes
Software inventory	Yes	Yes
Useful when minimizing agents	Less suitable	Highly suitable
Included with P2	Yes	Yes

The current Defender for Cloud implementation can also use a hybrid approach. If a machine has both agent-based and agentless scanning available, Defender for Cloud can use the agent-based results because they provide greater data freshness.

Exam scenario

If a question says:

A VM has both Defender for Endpoint-based scanning and agentless scanning available. Which results should you generally expect Defender for Cloud to use?

The important concept is:

Agent-based results take precedence because they provide better freshness.

7. Enabling Vulnerability Scanning at Subscription Scope

Vulnerability scanning can be configured for an Azure subscription through Defender for Cloud.

A typical configuration process is:

Open Microsoft Defender for Cloud.
Open Environment settings.
Select the Azure subscription.
Locate Defender for Servers.
Open the relevant monitoring/settings configuration.
Locate Vulnerability assessment for machines.
Configure the vulnerability-assessment solution.
Apply and save the configuration.

Current Microsoft documentation indicates that vulnerability scanning is enabled by default when Defender for Servers is enabled, although administrators can manually configure the vulnerability-assessment settings when required.

Important distinction

There are two related concepts:

Enabling Defender for Servers

and

Configuring the vulnerability-assessment behavior

Enabling Defender for Servers provides the overall server-protection framework, while the vulnerability-assessment settings determine how vulnerability scanning is configured.

8. Configuring Vulnerability Scanning for an Individual VM

Although configuring protection at subscription scope is generally preferable for consistent security management, Defender for Cloud also supports resource-level configuration.

This can be useful when:

Different VMs require different protection levels
An organization is gradually onboarding machines
Certain workloads require exceptions
Different server populations use different Defender for Servers plans

If a VM does not have an appropriate vulnerability assessment solution, Defender for Cloud can generate the recommendation:

Machines should have a vulnerability assessment solution

Administrators can use the recommendation to identify affected machines and configure a vulnerability solution.

9. Required Permissions

Permissions matter when configuring vulnerability scanning.

Current Microsoft guidance identifies:

Owner permissions at the resource-group level are required to deploy the scanner.
Security Reader permissions are sufficient to view vulnerability findings.

This illustrates an important security principle:

The person who needs to view vulnerability information does not necessarily need the permissions required to deploy or change vulnerability scanning.

This follows the principle of least privilege.

10. Reviewing Vulnerability Findings

Once vulnerability scanning is active, security teams need to interpret and prioritize the findings.

Defender for Cloud surfaces vulnerability information that can include:

Vulnerable machines
Affected software
CVEs
Severity
Remediation recommendations
Related security information

The Defender Vulnerability Management experience also provides broader vulnerability-management capabilities through the Microsoft Defender portal and Exposure Management.

11. Understanding CVEs

A Common Vulnerabilities and Exposures (CVE) identifier provides a standardized identifier for a publicly known vulnerability.

For example:

CVE-YYYY-NNNNN

can identify a specific vulnerability affecting a particular product or component.

When reviewing a vulnerability finding, security professionals should not simply look at the number of vulnerabilities.

Instead, they should consider:

Vulnerability severity
Affected asset
Business importance of the asset
Exploitability
Exposure
Attack-path information
Available remediation
Whether the vulnerability is actively being exploited

This helps organizations prioritize the vulnerabilities that present the greatest practical risk.

12. CVSS Scores

Vulnerability findings can also contain Common Vulnerability Scoring System (CVSS) information.

CVSS provides a standardized way to communicate the severity of a vulnerability.

For example:

CVSS	General interpretation
Low	Lower severity
Medium	Moderate severity
High	Significant severity
Critical	Extremely serious vulnerability

However, organizations should avoid treating CVSS as the only factor in remediation decisions.

A medium-severity vulnerability on an internet-facing production server could be more important to an organization than a critical vulnerability on an isolated development VM.

Modern Defender Vulnerability Management therefore emphasizes risk-based prioritization rather than simply sorting vulnerabilities by CVSS score.

13. Vulnerability Findings as Defender for Cloud Recommendations

Defender for Cloud presents vulnerability findings as recommendations.

For example:

Machines should have vulnerability findings resolved

can identify machines with vulnerabilities requiring attention.

The recommendation experience can provide:

Affected resources
Vulnerability information
CVEs
Severity
Remediation guidance

Administrators can investigate individual resources or examine findings across the environment.

14. Managing Accepted Risk

Not every vulnerability can immediately be remediated.

For example, an organization might determine that:

A vulnerable application cannot yet be upgraded.
The vulnerability affects a legacy application.
The vulnerability is not exploitable in the organization’s environment.
Compensating controls reduce the risk.
The vulnerability is below an organization’s defined risk threshold.

In these situations, organizations need a controlled way to manage exceptions.

Historically, Defender for Cloud provided disable rules for suppressing selected vulnerability findings.

However, current Microsoft guidance states that disable rules are being deprecated as part of the transition from grouped recommendations to individual recommendations, with recommendation exemptions becoming the preferred approach for managing exceptions.

Exam consideration

If a question is based on current functionality and asks how an organization should manage an accepted recommendation exception, understand the transition toward:

Recommendation exemptions

rather than assuming older disable-rule terminology is always the current answer.

15. Defender for Servers Plan 2 Premium Vulnerability Management

One of the most important reasons an organization might select Defender for Servers Plan 2 is access to additional vulnerability-management capabilities.

Current Defender documentation identifies premium capabilities associated with Plan 2, including:

Security baseline assessment
Vulnerable application blocking
Additional inventory and assessment capabilities
Additional remediation and mitigation functionality

These capabilities go beyond simply identifying CVEs.

16. Security Baseline Assessment

Security baseline assessment evaluates machines against defined security configuration profiles.

The goal is to determine whether a machine is configured according to an organization’s desired security posture.

For example, an organization might establish a baseline requiring:

Specific security settings
Appropriate authentication configuration
Required system protections
Secure operating-system configuration

Current Microsoft documentation identifies Defender Vulnerability Management security baseline assessment as a Plan 2 capability and notes that this assessment capability is currently in public preview.

Important distinction

Vulnerability assessment asks:

“Is the software or system vulnerable?”

Security baseline assessment asks:

“Is the system configured according to the desired security baseline?”

These are related but different security questions.

17. Vulnerable Application Blocking

Defender Vulnerability Management premium capabilities can also provide mechanisms for dealing with vulnerable applications.

Vulnerable application blocking is designed to reduce exploitation risk by preventing vulnerable applications from running under supported scenarios.

This is different from simply generating a vulnerability report.

The progression is approximately:

Discover vulnerability → Assess risk → Recommend remediation → Mitigate exploitation

Vulnerable application blocking therefore represents a more proactive mitigation capability.

It is associated with the premium Defender Vulnerability Management capabilities available through Defender for Servers Plan 2.

18. Defender for Servers Plan 1 vs. Plan 2

For the SC-500 exam, memorize the conceptual differences rather than attempting to memorize every individual feature.

Capability	Plan 1	Plan 2
Defender for Endpoint integration	Yes	Yes
Agent-based vulnerability assessment	Yes	Yes
Agentless machine scanning	No	Yes
Premium MDVM capabilities	No	Yes
Security baseline assessment	No	Yes
Vulnerable application blocking	No	Yes
Advanced server protection	More limited	More comprehensive

Exam shortcut

When the question emphasizes:

“agentless vulnerability scanning”

think:

Plan 2

When it emphasizes:

“premium Defender Vulnerability Management capabilities”

think:

Plan 2

When it simply asks whether Defender Vulnerability Management-based vulnerability scanning is available with Defender for Servers:

Plan 1 and Plan 2

19. What Happens When Agent-Based and Agentless Scanning Overlap?

This is an excellent potential exam scenario.

Suppose:

Defender for Servers Plan 2 is enabled.
Agentless scanning is enabled.
Defender for Endpoint is also installed and reporting vulnerability information.

Both methods may be available.

Defender for Cloud uses a hybrid behavior.

If both scanning methods provide results, agent-based results are preferred because they provide better data freshness.

This does not mean agentless scanning is unnecessary. It can extend coverage to machines that do not have an agent-based vulnerability-scanning solution.

20. Bring Your Own License Vulnerability Scanners

Organizations that already use another vulnerability-management product can use a supported Bring Your Own License (BYOL) vulnerability scanner.

Current Defender for Cloud documentation identifies supported partner solutions such as:

Qualys
Rapid7

The partner solution reports vulnerability data to its management platform, and vulnerability information can be surfaced through Defender for Cloud.

Important exam distinction

The integrated Microsoft solution is:

Microsoft Defender Vulnerability Management

A BYOL deployment is:

A supported third-party vulnerability assessment solution

These are alternative vulnerability-assessment approaches rather than two scanners that an organization necessarily needs to run simultaneously.

Only one BYOL scanner is supported for a machine.

21. Hybrid Behavior with BYOL Scanners

Defender for Cloud can combine different vulnerability-scanning capabilities depending on the machine’s configuration.

Current behavior includes:

If there is no agent-based scanner, agentless scanning can provide results where supported.
If Defender Vulnerability Management is integrated through Defender for Endpoint, Defender for Cloud can use the agent-based results.
If a supported BYOL scanner is installed, partner results generally take precedence.
Agentless results can be used for machines that do not have the partner scanner or are not reporting findings correctly.
Organizations can configure vulnerability-scanning behavior to use Defender Vulnerability Management results where appropriate.

This is an area where exam questions may test your understanding of which scanning method takes precedence rather than simply asking what each scanner does.

22. Vulnerability Scanning Is Not the Same as Network Vulnerability Scanning

Another important distinction:

The integrated Defender Vulnerability Management scanner focuses on vulnerabilities on the machine itself.

It does not function as a general network-vulnerability scanner that scans the entire network for network-device vulnerabilities.

Therefore:

“Find vulnerable software installed on this VM”

is a Defender Vulnerability Management use case.

Whereas:

“Scan the entire network for vulnerable network devices”

is a different security requirement.

23. Relationship Between Vulnerability Management and EDR

Endpoint Detection and Response (EDR) and vulnerability management address different security problems.

Defender for Endpoint / EDR

Focuses on detecting and responding to threats.

Examples include:

Suspicious behavior
Malware
Attacks
Endpoint incidents
Security alerts

Defender Vulnerability Management

Focuses on exposure and weaknesses.

Examples include:

Vulnerable software
Missing security updates
Vulnerable applications
Security recommendations
Risk prioritization

Defender for Servers integrates these capabilities to provide a more comprehensive security solution for protected machines.

24. A Practical Configuration Strategy

A good implementation strategy can be summarized as follows.

Step 1 — Enable Defender for Cloud

Ensure the Azure subscription is onboarded to Defender for Cloud.

Step 2 — Select Defender for Servers

Determine whether the organization needs:

Plan 1
Plan 2

Step 3 — Determine the scanning approach

Decide whether vulnerability assessment should use:

Agent-based scanning
Agentless scanning
A supported BYOL solution

Step 4 — Configure vulnerability assessment

Use Defender for Cloud Environment settings to configure vulnerability assessment for the appropriate subscription.

Step 5 — Validate machine coverage

Review the affected VMs and ensure vulnerability scanning is active.

Step 6 — Review findings

Analyze:

CVEs
Severity
Affected software
Affected machines
Remediation guidance

Step 7 — Prioritize

Prioritize vulnerabilities based on actual organizational risk, not simply CVSS score.

Step 8 — Remediate

Apply patches, update applications, modify configurations, or apply other compensating controls.

Step 9 — Handle accepted risks

Where remediation is not currently possible, use the appropriate recommendation-exemption mechanism according to current Defender for Cloud functionality.

Step 10 — Consider Plan 2 capabilities

For higher-security environments, evaluate:

Agentless scanning
Security baseline assessment
Vulnerable application blocking
Other premium Defender Vulnerability Management capabilities

25. Common Mistakes to Avoid

Mistake 1: Assuming Plan 1 provides agentless vulnerability scanning

It does not.

Agentless vulnerability scanning is associated with Plan 2.

Mistake 2: Assuming Plan 2 eliminates agent-based scanning

It does not.

Plan 2 supports both agent-based and agentless approaches.

Mistake 3: Confusing vulnerability management with EDR

Vulnerability management identifies weaknesses.

EDR detects and responds to active threats.

Mistake 4: Treating CVSS as the only prioritization factor

CVSS is important, but modern vulnerability management also considers contextual risk.

Mistake 5: Assuming every vulnerability should immediately be remediated

Some vulnerabilities may require documented risk acceptance or compensating controls.

Mistake 6: Confusing vulnerability assessment with network scanning

Defender Vulnerability Management focuses on vulnerabilities associated with the machine and its software.

Mistake 7: Forgetting resource scope

Defender for Servers and vulnerability assessment can be configured at subscription level, while resource-level configurations can be used for specific scenarios.

Mistake 8: Using outdated disable-rule assumptions

Microsoft is transitioning away from disable rules toward recommendation exemptions for managing exceptions.

26. SC-500 Exam-Focused Comparison

Requirement in the scenario	Most relevant concept
Scan VM vulnerabilities using Defender for Endpoint	Agent-based MDVM
Scan VMs without relying on an endpoint agent	Agentless scanning
Enable agentless vulnerability scanning	Defender for Servers Plan 2
Obtain premium MDVM capabilities	Defender for Servers Plan 2
Assess security configuration against baselines	Security baseline assessment
Prevent vulnerable applications from running	Vulnerable application blocking
View vulnerability information	Security Reader can view findings
Deploy scanner/configuration	Appropriate administrative permissions, including Owner at required scope
Identify known software vulnerabilities	MDVM
Detect active endpoint threats	Defender for Endpoint/EDR
Use an existing Qualys or Rapid7 solution	BYOL vulnerability assessment
Identify a known vulnerability	CVE
Assess vulnerability severity	CVSS and contextual risk
Manage accepted exceptions	Recommendation exemptions

27. Key Takeaways

For the SC-500 exam, remember these core concepts:

Microsoft Defender Vulnerability Management is integrated with Defender for Servers.
Defender for Servers Plan 1 supports agent-based vulnerability scanning.
Defender for Servers Plan 2 supports both agent-based and agentless vulnerability scanning.
Agentless vulnerability scanning is a major Plan 2 capability.
If both agent-based and agentless results are available, agent-based results are generally preferred because of their freshness.
Defender Vulnerability Management identifies software vulnerabilities and provides remediation information.
CVEs identify known vulnerabilities; CVSS helps communicate severity.
Risk prioritization should consider organizational context rather than relying exclusively on CVSS.
Security baseline assessment is different from vulnerability assessment.
Premium Defender Vulnerability Management capabilities, including security baseline assessment and vulnerable application blocking, are associated with Defender for Servers Plan 2.
Qualys and Rapid7 are examples of supported BYOL vulnerability-assessment solutions.
Vulnerability assessment is not the same thing as network vulnerability scanning.
Defender Vulnerability Management complements Defender for Endpoint/EDR rather than replacing it.
Current Defender for Cloud functionality is moving toward recommendation exemptions rather than older disable-rule mechanisms.

The most important mental model is:

Defender for Servers provides the server-protection framework; Defender Vulnerability Management identifies and prioritizes vulnerabilities; Defender for Endpoint provides endpoint protection and threat detection; Plan 2 adds agentless scanning and premium vulnerability-management capabilities.

Practice Exam Questions

Question 1

An organization has 500 Azure virtual machines protected by Microsoft Defender for Servers. The security team wants to identify software vulnerabilities but does not want the vulnerability assessment process to depend on installing an agent on every VM.

Which capability should the organization use?

A. Agentless vulnerability scanning with Defender for Servers Plan 2

B. Defender for Endpoint Plan 1 only

C. Microsoft Sentinel analytics rules

D. Azure Network Watcher

Answer: A

Explanation

A is correct. Defender for Servers Plan 2 supports agentless vulnerability scanning, which allows Defender Vulnerability Management to assess supported machines without relying on the traditional agent-based vulnerability-scanning approach. Agentless scanning is a key distinction between Plan 1 and Plan 2.

B is incorrect because Defender for Endpoint is associated with the agent-based approach and does not provide the requested agentless architecture.

C is incorrect because Microsoft Sentinel is primarily a SIEM/security analytics platform rather than a VM vulnerability scanner.

D is incorrect because Network Watcher provides network monitoring and diagnostics, not software vulnerability assessment.

Question 2

A company has enabled Defender for Servers Plan 1 for its Azure VMs. The security team wants to use Defender Vulnerability Management to identify vulnerabilities in installed software.

Which statement is correct?

A. Vulnerability Management requires Plan 2 and cannot be used with Plan 1.

B. Vulnerability Management is available only through Microsoft Sentinel.

C. Plan 1 supports agent-based vulnerability scanning through the Defender for Endpoint integration.

D. Plan 1 provides agentless vulnerability scanning but not agent-based scanning.

Answer: C

Explanation

C is correct. Defender for Servers Plan 1 supports agent-based vulnerability scanning through the Defender for Endpoint integration. Plan 2 expands the available capabilities by adding agentless scanning and premium Defender Vulnerability Management functionality.

A is incorrect because Plan 1 does support vulnerability assessment.

B is incorrect because Defender Vulnerability Management is integrated with Defender for Servers rather than requiring Sentinel.

D is incorrect because agentless scanning is a Plan 2 capability, whereas Plan 1 supports the agent-based approach.

Question 3

A security administrator is reviewing a vulnerability finding for an Azure VM. The finding includes a CVE identifier and a CVSS score.

What is the primary purpose of the CVE identifier?

A. To identify the Azure subscription containing the VM

B. To uniquely identify a publicly known vulnerability

C. To identify the severity category assigned by the organization’s security team

D. To identify the Defender for Servers billing plan

Answer: B

Explanation

B is correct. A Common Vulnerabilities and Exposures (CVE) identifier provides a standardized identifier for a publicly known vulnerability.

A is incorrect because Azure subscription identifiers are unrelated to CVEs.

C is incorrect because CVSS is used to communicate vulnerability severity; the CVE identifies the vulnerability itself.

D is incorrect because CVEs have nothing to do with Defender for Servers licensing.

Question 4

An organization has Defender for Servers Plan 2 enabled. Both agent-based Defender Vulnerability Management scanning and agentless scanning are available for the same VM.

Which result should an administrator generally expect Defender for Cloud to prioritize?

A. Agentless results because they always have higher accuracy

B. Results from whichever scanner has the highest CVSS score

C. Results from the scanner that was enabled most recently

D. Agent-based results because they generally provide better data freshness

Answer: D

Explanation

D is correct. When both agent-based and agentless scanning are available, Defender for Cloud generally uses the agent-based results because they provide better data freshness.

A is incorrect because agentless scanning does not automatically take precedence when both methods are available.

B is incorrect because CVSS does not determine which scanning source is selected.

C is incorrect because scanner selection is not based simply on which method was enabled most recently.

Question 5

A security team wants to evaluate whether Azure VMs conform to defined security configuration baselines. They are not merely interested in identifying known software vulnerabilities.

Which Defender Vulnerability Management capability addresses this requirement?

A. CVSS scoring

B. Security baseline assessment

C. Network vulnerability scanning

D. Microsoft Sentinel workbook analysis

Answer: B

Explanation

B is correct. Security baseline assessment evaluates machine configuration against defined security baseline profiles. It answers a different question from conventional vulnerability assessment. Current Microsoft documentation identifies this capability with Defender for Servers Plan 2.

A is incorrect because CVSS communicates vulnerability severity rather than evaluating configuration baselines.

C is incorrect because Defender Vulnerability Management’s integrated machine scanning is not a general network vulnerability scanner.

D is incorrect because Sentinel is not the service providing this MDVM capability.

Question 6

A security administrator needs to enable vulnerability assessment for machines across an Azure subscription.

Which location should the administrator use in Microsoft Defender for Cloud?

A. Environment settings for the subscription and the Defender for Servers settings

B. Azure Network Watcher

C. Microsoft Sentinel Analytics rules

D. Azure Key Vault access policies

Answer: A

Explanation

A is correct. Vulnerability assessment can be configured through Defender for Cloud → Environment settings → relevant subscription → Defender for Servers settings. Current guidance identifies vulnerability assessment for machines as a configurable Defender for Servers setting.

B is incorrect because Network Watcher handles network monitoring and diagnostics.

C is incorrect because Sentinel analytics rules detect and correlate security events rather than enabling VM vulnerability scanning.

D is incorrect because Key Vault access policies control access to Key Vault resources.

Question 7

An organization already uses a supported third-party vulnerability-management product and wants to integrate its findings into Microsoft Defender for Cloud instead of switching entirely to Microsoft’s integrated scanner.

Which approach should the organization consider?

A. Azure Bastion

B. Microsoft Sentinel data connectors

C. Azure Policy guest configuration

D. A supported Bring Your Own License vulnerability-assessment solution

Answer: D

Explanation

D is correct. Defender for Cloud supports Bring Your Own License (BYOL) vulnerability-assessment solutions, including supported partner solutions such as Qualys and Rapid7.

A is incorrect because Azure Bastion provides secure administrative access to VMs.

B is incorrect because Sentinel connectors are used for security-data ingestion rather than implementing the vulnerability scanner.

C is incorrect because Azure Policy guest configuration addresses configuration compliance rather than serving as the third-party vulnerability scanner.

Question 8

A security team wants to reduce exploitation risk by preventing vulnerable applications from running on protected servers when supported by the Defender Vulnerability Management capability.

Which Defender for Servers plan should they evaluate?

A. Defender for Servers Plan 1

B. Foundational CSPM only

C. Defender for Servers Plan 2

D. Azure Network Watcher

Answer: C

Explanation

C is correct. Vulnerable application blocking is among the premium Defender Vulnerability Management capabilities associated with Defender for Servers Plan 2.

A is incorrect because Plan 1 provides the basic Defender for Servers capabilities and agent-based vulnerability scanning but not the premium MDVM functionality described here.

B is incorrect because Foundational CSPM is focused on security posture management rather than providing the premium server vulnerability-management capability in the scenario.

D is incorrect because Network Watcher is a network diagnostic service.

Question 9

A security analyst has Security Reader permissions and needs to investigate vulnerability findings on Azure VMs. Another administrator will be responsible for deploying or changing the vulnerability scanner configuration.

Which statement best describes the permissions required?

A. Security Reader can view findings, while stronger permissions such as Owner at the required resource-group scope are needed to deploy the scanner.

B. Security Reader must be granted Global Administrator before findings can be viewed.

C. Contributor permissions are always required just to view vulnerability findings.

D. No Azure RBAC permissions are required for vulnerability information.

Answer: A

Explanation

A is correct. Current guidance specifies that Security Reader can view vulnerability findings, while Owner at the resource-group level is required to deploy the scanner.

This is an important least-privilege concept: viewing security information should not automatically require deployment-level permissions.

B is incorrect because Global Administrator is not required for viewing Defender for Cloud vulnerability findings.

C is incorrect because Contributor is not required merely to view the findings.

D is incorrect because Azure RBAC controls access to Defender for Cloud resources and findings.

Question 10

An organization determines that a particular vulnerability cannot currently be remediated because the affected application is business-critical and the organization has implemented compensating controls. The security team wants to manage the finding as an accepted exception using current Defender for Cloud functionality.

Which approach should the team favor?

A. Delete the vulnerability record

B. Use a recommendation exemption

C. Disable Microsoft Defender for Endpoint

D. Turn off Defender for Servers

Answer: B

Explanation

B is correct. Current Microsoft guidance is transitioning away from older disable rules toward recommendation exemptions for managing accepted exceptions.

The important security principle is that an accepted risk should be explicitly documented and governed rather than hiding the vulnerability by disabling the entire security capability.

A is incorrect because administrators should not attempt to delete vulnerability records to manage accepted risk.

C is incorrect because disabling Defender for Endpoint would remove important security capabilities rather than properly documenting the exception.

D is incorrect because disabling Defender for Servers would eliminate the broader server-protection capabilities and would not be an appropriate way to manage an individual accepted vulnerability.

Final Word

A key exam distinction to keep in mind is Plan 1 = agent-based vulnerability scanning; Plan 2 = agent-based + agentless scanning plus premium MDVM capabilities. Also watch for questions that distinguish vulnerability assessment, security-baseline assessment, EDR, and network scanning—they are deliberately different concepts.

Go to the SC-500 Exam Prep Hub main page

azure, Cloud computing, Cybersecurity, Microsoft Certification, SC-500, security October 10, 2026

Discover unprotected assets and vulnerabilities by using Microsoft Defender External Attack Surface Management (EASM) (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
      --> Discover unprotected assets and vulnerabilities by using Microsoft Defender External Attack Surface Management (EASM)

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 have a completely static IT environment.

Applications are deployed across Azure and other clouds. Developers create new internet-facing services. Acquisitions introduce unfamiliar domains and infrastructure. Third-party providers host applications and content. Old systems remain online after their owners have forgotten about them. Certificates, DNS records, IP addresses, and web applications continually change.

This creates a security problem:

How can an organization secure assets that it doesn’t even know it owns or exposes to the internet?

Microsoft Defender External Attack Surface Management (Defender EASM) addresses this problem by providing an outside-in view of an organization’s internet-exposed infrastructure.

Rather than starting with an Azure subscription or a known cloud resource, Defender EASM starts with known organizational assets—called discovery seeds—and recursively discovers related infrastructure. The resulting information is organized into an inventory that can expose unknown assets, third-party dependencies, vulnerabilities, and other security risks.

An important exam distinction is that Defender EASM uses an outside-in view of the internet to discover assets that may be unknown or unmanaged, complementing the resource-centric view provided by other Defender capabilities. The current Defender for Cloud integration also provides external attack-surface-management capabilities through Defender CSPM without requiring a separate Defender EASM license or special configuration.

For the SC-500 exam, this topic is particularly important because you need to understand:

What Defender EASM is
What an external attack surface is
How EASM differs from traditional vulnerability scanning
How discovery seeds work
How recursive discovery finds unknown assets
What types of assets EASM discovers
How assets are classified
The difference between approved, candidate, dependency, monitor-only, and investigation-required assets
How EASM identifies vulnerabilities and security-hygiene issues
How dashboards and inventory are used to prioritize risk
How EASM complements Defender for Cloud and Defender CSPM
How EASM can contribute to attack-path analysis
How organizations can manage discovered assets
How to distinguish EASM from Defender for Cloud’s cloud inventory and Defender Vulnerability Management

1. What Is Microsoft Defender External Attack Surface Management?

Microsoft Defender External Attack Surface Management (EASM) continuously discovers and maps an organization’s digital attack surface from an external perspective.

The key phrase to remember is:

Outside-in

EASM looks at the organization’s infrastructure from the perspective of what can be discovered from the internet.

This allows security teams to identify:

Unknown internet-facing infrastructure
Previously unmonitored assets
Web applications
Domains
Hosts
IP addresses
IP address blocks
SSL certificates
Third-party dependencies
Potential vulnerabilities
Security-hygiene problems
Suspicious or potentially malicious infrastructure relationships

Microsoft describes Defender EASM as providing visibility that helps organizations identify unknowns, prioritize risk, eliminate threats, and extend vulnerability and exposure management beyond the firewall.

The fundamental problem EASM solves

Traditional security programs often begin with assets that the organization already knows about.

For example:

“Show me all the virtual machines in this Azure subscription.”

That is useful, but it doesn’t answer:

“What internet-facing infrastructure associated with our organization exists that we don’t know about?”

EASM is designed to help answer the second question.

2. What Is an External Attack Surface?

An organization’s external attack surface consists broadly of infrastructure and services that are exposed or discoverable from the public internet.

Examples include:

Public websites
Internet-facing applications
Public IP addresses
DNS domains
Hosts
Web pages
SSL certificates
Publicly exposed services
Third-party infrastructure supporting organizational applications

The external attack surface changes constantly.

For example:

			
New application deployed
        ↓
New DNS record
        ↓
New public hostname
        ↓
New SSL certificate
        ↓
New internet-facing service
        ↓
New potential attack surface

		

A security team that relies entirely on manually maintained asset inventories may not discover every change.

Defender EASM continuously monitors and updates its understanding of the organization’s externally exposed infrastructure.

3. Why External Attack Surface Management Matters

Security controls are only effective when organizations know what they need to protect.

Consider an organization that believes it has:

50 public-facing websites
100 public IP addresses
20 internet-facing applications

EASM might discover additional infrastructure associated with those known assets.

For example:

			
Known corporate domain
        |
        +--- Web host
        |      |
        |      +--- Web application
        |      +--- SSL certificate
        |
        +--- Related IP block
        |      |
        |      +--- Additional host
        |
        +--- WHOIS contact
               |
               +--- Additional organization asset

		

The newly discovered infrastructure may represent:

Legitimate infrastructure
A third-party dependency
A forgotten asset
A development environment
Shadow IT
An incorrectly categorized asset
An asset requiring further investigation

This is one of the major security benefits of EASM.

4. How Defender EASM Discovery Works

The core concept behind EASM discovery is recursive discovery.

The process begins with assets that are known to belong to the organization.

These are called:

Discovery seeds

Defender EASM analyzes the known assets and observes relationships between them and other internet infrastructure.

It then follows those relationships to discover additional assets.

The process can be represented as:

			
Known Asset
    ↓
Discovery Seed
    ↓
Observe relationships
    ↓
Discover connected infrastructure
    ↓
Analyze newly discovered assets
    ↓
Follow additional relationships
    ↓
Build attack-surface inventory

		

Microsoft’s proprietary discovery technology recursively searches through observed connections to known legitimate assets and uses those connections to infer relationships between infrastructure.

5. What Is a Discovery Seed?

A discovery seed is a known asset that Defender EASM uses as a starting point for discovering additional infrastructure.

Examples include:

Domain names
Hosts
IP addresses or IP ranges
Autonomous System Numbers (ASNs)
Email addresses
WHOIS organization information

For example, suppose a company owns:

contoso.com

The organization can use that known domain as a discovery seed.

Defender EASM can then investigate relationships involving that domain and potentially identify:

			
contoso.com
     ↓
www.contoso.com
     ↓
public IP address
     ↓
IP block
     ↓
additional host
     ↓
related certificate

		

The objective is not simply to scan the original domain.

The objective is to understand the broader infrastructure connected to it.

6. Automated Discovery vs. Custom Discovery

Defender EASM supports automated attack-surface discovery as well as customized discovery.

Automated discovery

Microsoft has preconfigured attack surfaces for many organizations.

When starting with Defender EASM, Microsoft recommends searching for the organization’s existing attack surface before immediately creating a custom attack surface.

This allows an organization to take advantage of infrastructure that has already been identified and then allow Defender EASM to continue refreshing and expanding the inventory.

Custom discovery

Custom discovery is useful when an organization wants to investigate infrastructure that may not be sufficiently connected to its primary known assets.

For example:

A recently acquired company
A newly established business unit
A subsidiary
A newly purchased domain
A known IP range
An infrastructure relationship not discovered through the primary attack surface

Custom discoveries use selected seeds as starting points.

7. Discovery Seeds Cannot Be Private IP Addresses

An important exam detail is that Defender EASM is designed to provide an external perspective.

Therefore, private IP addresses cannot be used as discovery seeds.

The discovery process focuses on infrastructure that can be observed from the internet rather than internal-only addressing.

Exam scenario

If a question asks:

An administrator wants to create an EASM discovery group using an internal private IP address as the seed. What should the administrator do?

The correct concept is:

Use an externally discoverable asset instead.

8. Types of Assets Defender EASM Can Discover

Defender EASM’s inventory can contain several asset types.

Important asset types include:

Asset type	Example
Domains	`contoso.com`
Hosts	`www.contoso.com`
Pages	Web pages associated with hosts
IP addresses	Public IP addresses
IP blocks	Public address ranges
ASNs	Autonomous System Numbers
SSL certificates	Certificates associated with internet-facing services
WHOIS contacts	Registration/contact information

Microsoft’s current EASM documentation identifies domains, IP address blocks, hosts, email contacts, ASNs, and WHOIS organizations as core discovery asset types; the inventory also includes pages, IP addresses, and SSL certificates.

Exam tip

If a question asks which technology can help discover an organization’s:

“unknown internet-facing domains, hosts, IP addresses, and related infrastructure”

think:

Defender EASM

9. The Defender EASM Inventory

Discovered assets are indexed into the Defender EASM inventory.

The inventory acts as a dynamic record of the organization’s externally visible infrastructure.

This is important because the attack surface is not static.

An asset might:

Appear
Disappear
Change ownership
Change infrastructure
Become inactive
Become associated with a new application
Develop a new vulnerability

Defender EASM tracks these changes as part of its continuously updated attack-surface view.

10. Asset States

One of the most important SC-500 exam concepts is that not every discovered asset is automatically treated as an organizational asset.

Defender EASM uses different asset states to help organizations categorize discovered infrastructure.

Current asset states include:

Approved Inventory
Dependency
Monitor Only
Candidate
Requires Investigation

Understanding these states is important for exam questions involving asset ownership and classification.

11. Approved Inventory

Approved Inventory represents an asset that has been determined to belong to the organization’s attack surface and for which the organization is directly responsible.

For example:

			
Company-owned website
        ↓
Approved Inventory

This means the organization should normally consider the asset part of its managed security scope.

12. Dependency

A Dependency is infrastructure owned by another party but used to support the organization’s attack surface.

For example, a company may have a website hosted by a third-party provider.

The company owns the website and domain, but the underlying hosting infrastructure may belong to the provider.

The external infrastructure may therefore be classified as a dependency.

This distinction is important because:

The asset can be relevant to your attack surface even though you don’t directly own or control it.

Microsoft gives third-party hosting as an example of infrastructure that can be classified as a dependency.

13. Monitor Only

Monitor Only is useful when an asset is relevant to the organization’s attack surface but isn’t directly controlled by the organization and isn’t a technical dependency.

For example:

An independently operated franchise
A related organization
An asset belonging to a related company

The organization may want visibility into the asset without treating it as directly owned infrastructure.

14. Candidate

A Candidate asset has a relationship to known organizational assets but does not have a strong enough relationship for Defender EASM to automatically classify it as approved inventory.

A security administrator should review the asset and determine its appropriate classification.

For example:

			
Known company domain
       ↓
Related host discovered
       ↓
Relationship uncertain
       ↓
Candidate
       ↓
Manual review

		

This is an important distinction.

A discovered asset does not necessarily mean:

“This definitely belongs to our organization.”

Instead, Defender EASM provides evidence and relationship information so security teams can make the determination.

15. Requires Investigation

Requires Investigation is another state that identifies assets requiring additional human analysis.

Defender EASM uses internally generated confidence information to determine whether relationships between assets are sufficiently strong.

A Requires Investigation designation means:

The relationship needs further validation.

It does not necessarily mean the asset is malicious.

It means the organization should investigate its relationship to the known attack surface.

16. Understanding the Discovery Chain

The discovery chain helps security professionals understand why Defender EASM believes an asset is related to the organization.

For example:

			
Known domain
     ↓
WHOIS contact
     ↓
IP block
     ↓
IP address
     ↓
Host

		

The discovery chain provides evidence about the relationships connecting a discovered asset to a known seed.

This is extremely useful when investigating potentially unknown infrastructure.

Rather than simply saying:

“We found this IP address.”

Defender EASM can help answer:

“Why does Defender EASM believe this IP address is related to our organization?”

17. Asset Approval

Some discovered assets can be automatically approved when Defender EASM determines that the relationship to the known seed is sufficiently strong.

Other assets require manual review.

The current discovery information distinguishes between:

Approved inventory

and

Candidate

based on the strength of the relationship and approval process.

Exam scenario

If an asset is discovered but there isn’t enough evidence to automatically establish ownership, don’t assume it is automatically approved.

Think:

Candidate → investigate/approve appropriately.

18. Vulnerability Discovery

Defender EASM isn’t only an asset-discovery tool.

It also provides information that can help security teams identify vulnerabilities and other risks associated with externally exposed infrastructure.

For example, EASM can surface:

Vulnerabilities
CVEs
Weak security configurations
SSL/TLS issues
Exposed services
Security-hygiene problems
Potentially risky infrastructure

These insights help organizations prioritize which parts of their external attack surface require attention.

19. EASM and CVEs

Defender EASM can associate known vulnerabilities with externally discovered assets.

For example:

			
Internet-facing host
        ↓
Detected software
        ↓
Known vulnerability
        ↓
CVE
        ↓
Risk prioritization
        ↓
Remediation

		

This provides a useful external perspective on vulnerability exposure.

However, remember that EASM is fundamentally concerned with the external attack surface.

It is not simply another name for Defender Vulnerability Management.

20. Defender EASM vs. Defender Vulnerability Management

This distinction is highly relevant to SC-500.

Capability	Defender EASM	Defender Vulnerability Management
Primary focus	External attack surface	Vulnerability/exposure management
Perspective	Outside-in	Primarily workload/endpoint-oriented
Unknown internet-facing assets	Strong capability	Not its primary purpose
Discover domains and hosts	Yes	Not its primary purpose
Discover public IP infrastructure	Yes	Not its primary purpose
Identify software vulnerabilities	Yes, as part of external attack-surface insights	Core capability
Endpoint software inventory	Not primary	Strong capability
Defender for Endpoint integration	Not its primary purpose	Yes
Azure VM vulnerability assessment	Not its primary purpose	Yes

A useful mental model is:

EASM asks, “What can the internet see that belongs to us?”

while:

Defender Vulnerability Management asks, “What vulnerabilities exist on the systems we’re managing?”

These capabilities complement one another.

21. Defender EASM vs. Defender for Cloud Inventory

Another important distinction is between EASM and the Defender for Cloud cloud inventory.

Defender for Cloud’s inventory provides a resource-centric view of connected cloud resources, including Azure, AWS, and GCP resources.

For example:

			
Azure subscription
   ↓
VM
Storage account
SQL database
Container
AI service

		

EASM takes a different approach:

			
Internet
   ↓
Known public asset
   ↓
Related infrastructure
   ↓
Unknown external assets
   ↓
External attack surface

		

Defender for Cloud inventory is therefore useful for understanding the security state of known connected cloud resources, while EASM helps uncover internet-facing infrastructure that may not be represented in the organization’s cloud-resource inventory.

22. EASM and Defender CSPM

Defender EASM is particularly important in conjunction with Defender Cloud Security Posture Management (Defender CSPM).

Current Defender for Cloud functionality integrates external attack-surface-management capabilities through Defender EASM.

This integration allows organizations to improve their security posture by incorporating an external view of attack-surface exposure.

Importantly, Microsoft currently states that the external attack-surface-management capability integrated into Defender CSPM is included with the Defender CSPM plan and doesn’t require a separate Defender EASM license or special configuration.

Exam tip

Don’t automatically assume:

“Defender EASM always requires a separate EASM license.”

The current Defender CSPM integration changes this distinction.

23. EASM and Attack Path Analysis

EASM findings can also complement attack path analysis.

The SC-500 training specifically calls out the integration of EASM findings with Defender CSPM for attack-path analysis.

The significance is that an organization can move beyond simply asking:

“What assets are exposed?”

and begin asking:

“Which exposed assets create meaningful attack paths into important resources?”

For example:

			
Internet-facing asset
       ↓
Vulnerability
       ↓
Compromised workload
       ↓
Lateral movement
       ↓
Sensitive resource

		

Attack-path analysis helps security teams focus on exposures that could contribute to meaningful attack scenarios.

24. EASM Dashboards

Defender EASM provides dashboards designed to help organizations understand their attack surface.

Dashboard insights can focus on areas such as:

Vulnerabilities
Security hygiene
Compliance
Infrastructure
Asset exposure

These dashboards help security teams prioritize the areas presenting the greatest risk rather than reviewing every discovered asset individually.

25. Security Hygiene

Not every security problem is necessarily a traditional software vulnerability.

For example, an organization might have:

An expired or weak SSL certificate
Unexpected exposed ports
Unnecessary internet-facing infrastructure
An outdated service
An unexpected host
An unmanaged domain

These conditions can contribute to an organization’s overall security hygiene.

EASM dashboards and inventory capabilities help surface these conditions so organizations can investigate and remediate them.

26. IP Reputation

Defender EASM also provides IP reputation information.

The IP reputation information can identify potential threats associated with an IP address, including evidence that the address has appeared on threat lists.

For example, an IP address could have been associated with suspicious activity or a known malicious host.

This information provides additional context when evaluating an externally exposed asset.

Important distinction

An IP appearing in threat intelligence does not automatically prove that the organization’s current system is compromised.

It is an indicator that warrants investigation.

27. Connected Assets

The Defender EASM asset details experience provides a Connected assets view.

This allows security professionals to understand other assets connected to a particular asset.

For example:

			
Domain
  |
  +-- Host
  |
  +-- IP address
  |
  +-- SSL certificate
  |
  +-- Web page

		

Understanding connected assets is valuable because a security issue involving one component may reveal additional infrastructure that needs investigation.

28. JavaScript and Web Resources

Defender EASM can also provide visibility into resources associated with web assets.

For example, it can identify JavaScript resources associated with pages or hosts.

Information can include:

Resource URL
Resource host
MD5 hash
First-seen date
Last-seen date

This provides another layer of visibility into the technologies and resources used by externally exposed web applications.

29. SSL Certificate Visibility

SSL certificates are another important component of the external attack surface.

Certificates can provide relationships between:

Domains
Hosts
Infrastructure
Organizations

An unexpected certificate can sometimes reveal infrastructure that wasn’t present in a manually maintained inventory.

For this reason, certificate information can be valuable during external attack-surface discovery.

30. Managing EASM Inventory Assets

Defender EASM doesn’t just discover assets.

Security teams can also manage the inventory.

Current capabilities include:

Changing asset states
Adding labels
Assigning external IDs
Removing labels
Marking observations as not applicable
Removing assets from inventory
Managing assets discovered through specific seeds
Tracking changes through Task Manager

For example, an organization can label an asset according to an internal classification such as:

			
Production
Development
Acquisition
Third-party
Critical
Requires Review

		

Labels provide additional organizational context.

31. Marking an Observation as Not Applicable

An important management capability is the ability to mark certain observations as not applicable.

For example, a security team may investigate a vulnerability or other observation and determine that it does not apply to the organization’s specific situation.

Rather than ignoring the issue informally, the organization can manage the observation within the EASM inventory.

This helps maintain more accurate reporting.

32. Removing Assets

Defender EASM also provides mechanisms for removing assets from inventory.

For example, when removing a discovery seed, an administrator can choose to remove assets that were discovered through a connection to that seed.

This is useful when an organization determines that:

A seed no longer belongs to it
An acquisition has been divested
An infrastructure relationship is no longer relevant
The inventory needs to be corrected

33. EASM and Shadow IT

One of the strongest practical use cases for EASM is discovering shadow IT and previously unknown external infrastructure.

Consider this scenario:

A development team launches:

test-new-app.company-example.com

The security team isn’t informed.

The application becomes publicly accessible.

Traditional security inventory:

Unknown

EASM:

			
Internet discovery
       ↓
Related domain discovered
       ↓
Host discovered
       ↓
Application identified
       ↓
Potential vulnerability detected

		

This provides security teams with visibility into infrastructure that may have bypassed normal inventory and security-review processes.

34. EASM for Mergers and Acquisitions

EASM can also be valuable during mergers and acquisitions.

Suppose Company A acquires Company B.

Company A may receive:

New domains
Public IP ranges
Websites
Web applications
Certificates
Hosts
Third-party dependencies

The acquiring organization’s existing asset inventory may not immediately contain all of this infrastructure.

EASM can help establish an external view of the acquired organization’s attack surface.

35. EASM and Third-Party Dependencies

An organization may depend on infrastructure it doesn’t directly own.

For example:

			
Company website
      ↓
Third-party hosting provider
      ↓
External infrastructure

		

That external infrastructure may be classified as a Dependency.

This is important because:

Security responsibility may differ from ownership.

An organization can have a security exposure resulting from a third party even when the organization doesn’t directly manage the underlying infrastructure.

36. A Typical EASM Investigation

Consider an organization that believes all of its public infrastructure is known.

Step 1 — Start with known assets

Provide known:

Domains
Hosts
IP blocks
Other supported identifiers

Step 2 — Run discovery

Defender EASM recursively examines relationships among internet-facing infrastructure.

Step 3 — Review the inventory

The security team examines discovered assets.

Step 4 — Classify assets

Assets may be:

Approved Inventory
Dependency
Monitor Only
Candidate
Requires Investigation

Step 5 — Investigate unknown assets

The security team examines:

Discovery chains
Connected assets
IP reputation
Vulnerabilities
Web resources
Certificates

Step 6 — Prioritize risk

Security teams use dashboards and vulnerability information to identify the most important exposures.

Step 7 — Remediate

Examples include:

Remove unnecessary public exposure
Patch vulnerable software
Replace certificates
Secure misconfigured services
Remove abandoned infrastructure
Transfer remediation to the appropriate third-party owner

Step 8 — Continue monitoring

The organization continues monitoring its changing external attack surface.

37. EASM Outside-In vs. Traditional Inside-Out Security

This is perhaps the most important conceptual distinction for the exam.

Traditional cloud security

Starts with:

			
Known Azure resource
       ↓
Configuration
       ↓
Security posture
       ↓
Recommendations

		

Defender EASM

Starts with:

			
Internet
   ↓
Known organizational asset
   ↓
Related infrastructure
   ↓
Unknown assets
   ↓
External vulnerabilities
   ↓
Attack-surface risk

		

Neither approach replaces the other.

They answer different questions.

38. EASM Does Not Replace Defender for Cloud

It is important not to interpret EASM as a replacement for Defender for Cloud.

Instead, think of the technologies as complementary.

Security question	Appropriate capability
What Azure resources do we have?	Defender for Cloud inventory
What security recommendations affect our Azure resources?	Defender for Cloud
What vulnerabilities exist on protected VMs?	Defender Vulnerability Management
What internet-facing infrastructure belongs to us?	Defender EASM
What unknown domains/hosts/IP infrastructure exists?	Defender EASM
What externally exposed vulnerabilities exist?	Defender EASM
What attack paths involve external exposure?	Defender CSPM + EASM integration

39. Permissions

Defender EASM uses Azure RBAC.

Current documentation identifies the following general roles:

Owner

An Owner can:

Create EASM resources
Delete resources
Edit resources
Manage inventory assets
Use EASM capabilities

Contributor

A Contributor can also create, delete, and edit EASM resources and inventory assets.

Reader

A Reader can:

View Defender EASM data

but cannot create, delete, or edit resources or inventory assets.

Exam tip

If the question says:

“The user only needs to view EASM data.”

Think:

Reader

If the user needs to modify inventory or resources:

Contributor or Owner, depending on the required scope and operation.

40. Current Defender CSPM Integration

A particularly important current-platform consideration is the integration between Defender EASM and Defender CSPM.

Microsoft currently describes external attack-surface-management functionality in Defender for Cloud as being provided through integration with Defender EASM.

The capability is included with the Defender CSPM plan by default and does not require a separate Defender EASM license or special configuration for that integrated capability.

This makes external attack-surface visibility part of a broader cloud-security-posture strategy.

41. Security Copilot Integration

Current Defender EASM also supports integration with Microsoft Security Copilot.

Security Copilot can be used to interact with Defender EASM data using natural-language prompts.

For example, security teams can ask questions about:

External attack surface
Critical risks
CVEs
SSL certificates
Exposed ports
Specific assets

It can also help with attack-surface curation, including working with labels, external IDs, and asset states.

For SC-500, however, the foundational concept remains:

EASM provides external attack-surface discovery and visibility.

42. Common EASM Misconceptions

Misconception 1: EASM is just another vulnerability scanner

Not exactly.

Vulnerability discovery is an important capability, but the primary purpose is to understand the external attack surface.

Misconception 2: EASM only scans Azure

Incorrect.

EASM is concerned with internet-facing infrastructure and can discover assets across an organization’s external digital environment rather than limiting itself to Azure resource types.

Misconception 3: Every discovered asset belongs to the organization

Incorrect.

Assets can be classified as:

Approved Inventory
Dependency
Monitor Only
Candidate
Requires Investigation

Misconception 4: Candidate means malicious

Incorrect.

Candidate means the relationship to the organization requires review.

Misconception 5: Dependency means the organization owns the infrastructure

Incorrect.

A dependency can be infrastructure owned by another organization but supporting the organization’s attack surface.

Misconception 6: EASM replaces Defender Vulnerability Management

Incorrect.

EASM and Defender Vulnerability Management provide complementary capabilities.

Misconception 7: EASM only looks at internal Azure inventory

Incorrect.

Its defining characteristic is the external, outside-in perspective.

Misconception 8: Private IP addresses can be used as discovery seeds

Incorrect.

Private IP addresses cannot be used as Defender EASM discovery seeds.

43. SC-500 Exam-Focused Comparison

Scenario	Think
Discover unknown public domains	Defender EASM
Discover unknown internet-facing hosts	Defender EASM
Discover external IP infrastructure	Defender EASM
Map relationships between known and unknown public assets	EASM discovery
Start discovery from a known domain	Discovery seed
Determine why an asset was associated with the organization	Discovery chain
Asset ownership uncertain	Candidate / Requires Investigation
Third-party infrastructure supporting an application	Dependency
Related but independently controlled organization infrastructure	Monitor Only
Asset directly owned and managed by organization	Approved Inventory
Find vulnerabilities associated with externally exposed assets	Defender EASM
Scan Azure VM software for vulnerabilities	Defender Vulnerability Management
Get cloud-resource inventory	Defender for Cloud Inventory
Use external attack-surface information for attack-path analysis	Defender CSPM + EASM
View EASM information without modifying it	Reader
Modify EASM inventory	Contributor/Owner
Use a private IP as a discovery seed	Not supported

44. Key Takeaways

For the SC-500 exam, remember the following:

Defender EASM provides an outside-in view of an organization’s internet-exposed attack surface.
EASM uses discovery seeds as starting points.
Discovery is recursive—Defender EASM follows observed relationships to discover additional infrastructure.
Discovery seeds can include known domains, hosts, IP ranges, ASNs, email information, and WHOIS-related identifiers.
Private IP addresses cannot be used as discovery seeds.
EASM can discover assets such as domains, hosts, pages, IP addresses, IP blocks, ASNs, SSL certificates, and WHOIS-related information.
Discovered assets are maintained in the Defender EASM inventory.
Important asset states include:
- Approved Inventory
- Dependency
- Monitor Only
- Candidate
- Requires Investigation
A Candidate asset requires additional review before being treated as approved organizational infrastructure.
A Dependency can be owned by a third party but still be relevant to the organization’s attack surface.
The discovery chain helps explain why Defender EASM believes an asset is connected to the organization.
EASM can surface vulnerabilities, CVEs, IP reputation information, SSL-related issues, and other security-hygiene concerns.
EASM is not simply another name for Defender Vulnerability Management.
Defender Vulnerability Management focuses primarily on vulnerability management for managed workloads/endpoints, whereas EASM emphasizes the organization’s externally observable attack surface.
Defender EASM complements Defender for Cloud rather than replacing it.
Current Defender CSPM functionality integrates external attack-surface management through Defender EASM without requiring a separate EASM license for that integrated capability.
EASM findings can complement Defender CSPM attack-path analysis.
The fundamental EASM question is:

“What can the internet see that belongs to our organization?”

The fundamental vulnerability-management question is:

“What vulnerabilities exist on the systems we’re managing?”

For the exam, remember:

Known asset → Discovery seed → Recursive discovery → External attack-surface inventory → Classify assets → Identify vulnerabilities/exposures → Prioritize risk → Remediate.

Practice Exam Questions

Question 1

A security team is concerned that developers may have deployed internet-facing applications that are not included in the organization’s official asset inventory. The team wants to discover unknown public-facing domains, hosts, and related infrastructure associated with the organization.

Which Microsoft solution is most appropriate?

A. Azure Policy

B. Microsoft Defender for Endpoint

C. Microsoft Defender External Attack Surface Management

D. Microsoft Sentinel

Answer: C

Explanation

A is correct. Defender EASM is specifically designed to provide an external, outside-in view of an organization’s internet-facing attack surface. Its recursive discovery capabilities can uncover previously unknown and unmonitored infrastructure connected to known organizational assets.

B is incorrect because Defender for Endpoint primarily provides endpoint protection, detection, and response capabilities.

C is incorrect because Azure Policy governs Azure resources and configurations rather than discovering an organization’s unknown public internet infrastructure.

D is incorrect because Sentinel is a SIEM/SOAR platform rather than an external attack-surface discovery service.

Question 2

An administrator wants to create a custom Defender EASM discovery group. The administrator has identified a known company-owned domain that should be used as the starting point for discovery.

What should the administrator configure?

A. A private IP address

B. A security recommendation

C. The company-owned domain as a discovery seed

D. An Azure Resource Graph query

Answer: C

Explanation

C is correct. A discovery seed is a known organizational asset that Defender EASM uses as a starting point for recursive discovery. Domains, hosts, IP ranges, and other supported identifiers can be used as seeds.

A is incorrect because private IP addresses cannot be used as Defender EASM discovery seeds.

B is incorrect because a security recommendation isn’t a discovery seed.

D is incorrect because Azure Resource Graph is used to query Azure resource information and isn’t the mechanism for defining EASM discovery seeds.

Question 3

Defender EASM discovers an IP address associated with a known corporate domain. The security team wants to understand why EASM determined that the IP address is related to the organization.

Which capability should the team examine?

A. Security baseline assessment

B. Discovery chain

C. Azure Policy compliance

D. CVSS score

Answer: B

Explanation

B is correct. The discovery chain provides information about the observed relationships between a discovery seed and a discovered asset. It helps security professionals understand why Defender EASM associated an asset with their organization.

A is incorrect because security baseline assessment evaluates machine configuration rather than EASM asset relationships.

C is incorrect because Azure Policy compliance doesn’t explain EASM discovery relationships.

D is incorrect because CVSS relates to vulnerability severity rather than asset discovery relationships.

Question 4

A Defender EASM discovery operation identifies an external host that appears to be related to the organization. However, the relationship isn’t strong enough for the asset to be automatically classified as part of the organization’s approved inventory.

What asset state should the security team expect?

A. Approved Inventory

B. Dependency

C. Monitor Only

D. Candidate

Answer: D

Explanation

D is correct. A Candidate asset has a relationship to known organizational assets but doesn’t have sufficient evidence to be automatically treated as approved inventory. It requires manual review to determine the appropriate classification.

A is incorrect because Approved Inventory indicates that the asset has been established as part of the organization’s owned attack surface.

B is incorrect because Dependency is used when infrastructure owned by another party supports the organization’s attack surface.

C is incorrect because Monitor Only is intended for relevant assets that aren’t directly controlled and aren’t necessarily technical dependencies.

Question 5

A company hosts its public web application with a third-party provider. Defender EASM identifies the third-party infrastructure as being directly associated with the company’s externally exposed application, but the company does not own the underlying hosting infrastructure.

How should this infrastructure generally be classified?

A. Candidate

B. Dependency

C. Approved Inventory

D. Requires Investigation

Answer: B

Explanation

B is correct. A Dependency represents infrastructure owned by a third party that directly supports the organization’s attack surface. Third-party hosting is a typical example.

A is incorrect because Candidate is primarily used when the relationship to the organization requires additional ownership validation.

C is incorrect because the scenario explicitly states that the organization does not own the infrastructure.

D is incorrect because the scenario provides sufficient information to establish that the infrastructure supports the organization’s attack surface as a third-party dependency.

Question 6

A security architect needs a tool that can provide an external view of the organization’s public-facing infrastructure and discover previously unknown hosts, domains, and IP addresses.

Which characteristic most directly distinguishes Defender EASM from a traditional cloud-resource inventory?

A. EASM begins with an outside-in perspective of internet-exposed infrastructure

B. EASM only inventories Azure virtual machines

C. EASM requires every discovered asset to be an Azure resource

D. EASM can only discover resources that are manually entered by administrators

Answer: A

Explanation

A is correct. The defining characteristic of EASM is its outside-in perspective. It starts with known external assets and recursively discovers related internet-facing infrastructure.

B is incorrect because EASM isn’t limited to Azure VMs.

C is incorrect because EASM discovers externally exposed infrastructure that does not necessarily correspond to Azure resource objects.

D is incorrect because the purpose of recursive discovery is precisely to identify infrastructure that administrators may not have manually entered.

Question 7

A security analyst wants to investigate whether a public IP address associated with an organization’s attack surface has previously been associated with suspicious or malicious activity.

Which Defender EASM capability should the analyst examine?

A. Discovery seed configuration

B. Asset state

C. Azure RBAC

D. IP reputation

Answer: D

Explanation

D is correct. Defender EASM provides an IP reputation view that can identify potential threats and suspicious activity associated with an IP address, including appearances on threat lists.

A is incorrect because discovery seeds determine where discovery starts.

B is incorrect because asset state describes how the organization categorizes an asset.

C is incorrect because Azure RBAC controls access to resources and data; it doesn’t provide IP reputation information.

Question 8

A security team wants to understand the difference between Defender EASM and Microsoft Defender Vulnerability Management.

Which statement is most accurate?

A. EASM is primarily an endpoint detection and response system, while Defender Vulnerability Management is primarily a SIEM.

B. EASM and Defender Vulnerability Management are identical capabilities with different names.

C. EASM focuses on discovering and understanding internet-facing attack-surface exposure, while Defender Vulnerability Management focuses on vulnerability management for managed workloads and endpoints.

D. Defender Vulnerability Management discovers unknown public domains, while EASM scans operating-system vulnerabilities on Azure VMs.

Answer: C

Explanation

C is correct. EASM’s primary purpose is to discover and understand an organization’s external attack surface, including unknown internet-facing infrastructure. Defender Vulnerability Management focuses on identifying, assessing, and prioritizing vulnerabilities on managed systems and endpoints.

A is incorrect because neither description is accurate.

B is incorrect because the two technologies serve complementary but distinct purposes.

D is incorrect because it reverses the primary responsibilities of the two technologies.

Question 9

An organization uses Defender CSPM and wants external attack-surface information to contribute to its overall cloud security posture and attack-path analysis.

Which integration should the organization use?

A. Defender EASM integration with Defender CSPM

B. Azure Bastion integration with Microsoft Sentinel

C. Azure Key Vault integration with Defender for Endpoint

D. Azure Policy integration with Defender Vulnerability Management

Answer: A

Explanation

A is correct. Defender EASM integrates with Defender CSPM to provide external attack-surface information that can contribute to security-posture analysis and attack-path analysis. The current Defender for Cloud implementation provides this external attack-surface capability through the Defender EASM integration.

B, C, and D are incorrect because those combinations do not provide the EASM external attack-surface integration described in the scenario.

Question 10

A security analyst has been given access to a Defender EASM resource. The analyst only needs to view the organization’s attack-surface information and must not be able to modify resources or inventory assets.

Which Azure RBAC role is most appropriate?

A. Owner

B. Contributor

C. Reader

D. Global Administrator

Answer: C

Explanation

C is correct. The Defender EASM documentation identifies the Reader role as providing the ability to view Defender EASM data without allowing the user to create, delete, or edit resources or inventory assets.

A is incorrect because Owner provides extensive management permissions beyond the analyst’s requirement.

B is incorrect because Contributor can create, delete, and edit EASM resources and inventory assets.

D is incorrect because Global Administrator is a Microsoft Entra directory role and is not the appropriate least-privilege choice for simply viewing Defender EASM data.

Final Word

For this exam objective, place some emphasis on discovery seeds → recursive discovery → inventory → asset states → vulnerabilities/exposure → risk prioritization. Those concepts are more important for the SC-500 exam than memorizing portal navigation. The distinction between Candidate, Dependency, Monitor Only, and Approved Inventory is especially worth studying because it lends itself naturally to scenario-based exam questions.

Go to the SC-500 Exam Prep Hub main page

AI Security, azure, Cloud computing, Cybersecurity, Microsoft Certification, SC-500, security October 10, 2026

Create and connect workspaces in Microsoft Sentinel (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%)
   --> Implement activity and event collection in Microsoft Sentinel
      --> Create and connect workspaces in Microsoft Sentinel

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

Microsoft Sentinel is a cloud-native Security Information and Event Management (SIEM) platform that collects security data from cloud, on-premises, and other environments and uses that data for detection, investigation, threat hunting, and response.

A fundamental part of implementing Microsoft Sentinel is understanding its workspace architecture. Microsoft Sentinel is deployed to a Log Analytics workspace, which provides the underlying data store for the logs and events that Sentinel analyzes.

For the SC-500 exam, you should understand not only how to create a workspace, but also how to decide on an appropriate workspace architecture, how Microsoft Sentinel is connected to a workspace, how permissions affect access, and when multiple workspaces or tenants may be appropriate.

Microsoft’s current training module specifically identifies three core objectives for this area:

Describe Microsoft Sentinel workspace architecture.
Onboard a Microsoft Sentinel workspace to Microsoft Defender.
Manage a Microsoft Sentinel workspace in Microsoft Defender.

1. Understanding the Microsoft Sentinel Workspace

The most important concept to remember is:

Microsoft Sentinel is added to a Log Analytics workspace.

A Log Analytics workspace is an Azure resource that stores and organizes log data. Microsoft Sentinel adds SIEM capabilities to that workspace, allowing security teams to analyze the collected data and build security operations processes around it.

A simplified architecture looks like this:

                    Data Sources
                         |
          +--------------+--------------+
          |              |              |
       Azure          Microsoft      On-premises
      Resources       Services        Systems
          |              |              |
          +--------------+--------------+
                         |
                         v
                Data Connectors
                         |
                         v
              +----------------------+
              |  Log Analytics      |
              |     Workspace       |
              |                      |
              |  Logs / Events       |
              |  Tables              |
              |  Security Data       |
              +----------+-----------+
                         |
                  Microsoft Sentinel
                         |
          +--------------+--------------+
          |              |              |
       Analytics       Incidents      Hunting
         Rules                        & KQL
          |              |              |
          +--------------+--------------+
                         |
                  Investigation &
                     Response

The workspace therefore provides the underlying location for Sentinel data, while Sentinel supplies the security operations capabilities.

Microsoft’s current onboarding guidance confirms that Microsoft Sentinel must be added to a Log Analytics workspace. An existing Log Analytics workspace can be used, or a new one can be created before Sentinel is enabled.

2. Why Workspace Architecture Matters

The choice of workspace architecture can have a major impact on:

Security operations
Data isolation
Access control
Data residency
Regulatory requirements
Retention requirements
Cost
Administration
Cross-workspace monitoring
Cross-tenant operations

For many organizations, a single workspace is sufficient and simpler to manage.

However, there are circumstances in which multiple workspaces make sense.

Microsoft’s current deployment guidance recommends evaluating factors such as the number of tenants, compliance and data-storage requirements, access-control requirements, and the organization’s data sources before determining the appropriate architecture.

Example

Consider a company with three business divisions:

			
Contoso Corporation
        |
  +-----+-----+
  |           |
Finance     Healthcare
  |           |
Workspace A  Workspace B
        +
        |
     Retail
        |
   Workspace C

		

The organization might decide to use separate workspaces because different divisions have:

Different regulatory requirements
Different data-retention requirements
Different security teams
Different access requirements

However, multiple workspaces introduce additional management complexity.

Exam Tip: If a question does not provide a compelling reason for multiple workspaces, do not automatically assume that multiple workspaces are the better design.

3. Single-Workspace Architecture

A single-workspace architecture places the organization’s Microsoft Sentinel data into one Log Analytics workspace.

For example:

			
Azure Resources
Microsoft 365
On-premises Servers
Network Devices
Third-party Applications
       |
       v
+-------------------------+
| Log Analytics Workspace |
|                         |
| Microsoft Sentinel      |
+-------------------------+

		

Advantages

A single workspace can simplify:

Data management
KQL queries
Analytics rules
Incident investigation
Workbooks
Automation
Permissions
Administration

Microsoft currently recommends a single-workspace environment when practical, while recognizing that specific organizational requirements can justify multiple workspaces.

When it is especially attractive

A single workspace is often appropriate when:

The organization has a single Microsoft Entra tenant.
Security teams need centralized visibility.
Data does not need to be separated for regulatory reasons.
Different business units do not require strong data isolation.
A common retention strategy is acceptable.

4. Multiple-Workspace Architecture

Some organizations need multiple Log Analytics workspaces with Microsoft Sentinel enabled.

Examples include:

Large enterprises
Managed Security Service Providers (MSSPs)
Organizations with multiple Microsoft Entra tenants
Organizations with different regulatory boundaries
Organizations requiring different retention policies
Organizations requiring strong separation between business units

Microsoft supports cross-workspace and cross-tenant Sentinel architectures for these scenarios.

For example:

                 Central SOC
                     |
        +------------+------------+
        |            |            |
        v            v            v
   Workspace A  Workspace B  Workspace C
     Finance      Retail       Europe

The security operations team can maintain centralized visibility while allowing each environment to retain its own workspace.

5. Primary and Secondary Workspaces

Current Microsoft Sentinel architecture in the Microsoft Defender portal supports a primary workspace and multiple secondary workspaces for a tenant.

Microsoft defines a workspace in this context as a Log Analytics workspace with Microsoft Sentinel enabled.

This distinction is important because some tenant-level Microsoft security integrations operate through the primary workspace.

For example, in a multiple-workspace environment, the Microsoft Defender XDR connector is connected to the primary workspace. Certain standalone Microsoft security-product connectors are consequently handled differently in secondary workspaces to prevent duplicate tenant-based alerts.

Exam Tip

If a question asks about the primary workspace, think about the workspace that provides the central Sentinel context for the tenant, particularly for supported Microsoft security integrations.

6. Creating a Log Analytics Workspace

Before Microsoft Sentinel can be deployed, you need a Log Analytics workspace.

At a high level, the process is:

Select the Azure subscription.
Select or create a resource group.
Specify the Log Analytics workspace name.
Select an appropriate region.
Configure the required workspace settings.
Validate the configuration.
Create the workspace.

Microsoft’s current onboarding process explicitly follows this model: create or select a Log Analytics workspace, choose its subscription/resource group and region, and deploy it before adding Microsoft Sentinel.

Workspace location matters

The workspace’s Azure region can matter for:

Data residency
Regulatory requirements
Performance
Organizational policies
Integration requirements

Therefore, selecting the region should be treated as an architectural decision rather than simply choosing the closest Azure region.

7. Adding Microsoft Sentinel to the Workspace

Once the Log Analytics workspace exists, Microsoft Sentinel can be added to it.

Conceptually:

			
Step 1
Create Log Analytics Workspace
             |
             v
Step 2
Add Microsoft Sentinel
             |
             v
Step 3
Configure Data Connectors
             |
             v
Step 4
Configure Security Content
             |
             v
Step 5
Begin Monitoring

		

The resulting relationship is:

			
Log Analytics Workspace
          |
          +-- Microsoft Sentinel
          |
          +-- Logs
          +-- Tables
          +-- Security Events
          +-- Data

		

Microsoft’s current quickstart describes this as adding Microsoft Sentinel to an existing Log Analytics workspace.

8. Connecting a Workspace to Microsoft Defender

Microsoft Sentinel can be accessed and managed through the Microsoft Defender portal, providing a unified security operations experience.

For a single-workspace deployment, the prerequisite is a Log Analytics workspace with Microsoft Sentinel enabled, together with the appropriate permissions.

In the Defender portal, administrators can connect an existing Sentinel workspace.

The current workflow includes:

Open the Microsoft Defender portal.
Navigate to the Microsoft Sentinel settings.
View the available Sentinel workspaces.
Select the workspace.
Connect the workspace.
Where applicable, designate it as the primary workspace.

For current Defender-portal deployments, Microsoft describes a workspace as a Log Analytics workspace with Microsoft Sentinel enabled.

9. Azure Portal Versus Microsoft Defender Portal

This is an important current-state exam consideration.

Microsoft is transitioning Microsoft Sentinel toward the Microsoft Defender portal.

Microsoft currently states that after March 31, 2027, Microsoft Sentinel will no longer be supported in the Azure portal and will be available only through the Microsoft Defender portal. Microsoft also recommends that organizations using Sentinel in the Azure portal begin planning the transition.

Therefore, you may encounter documentation and questions involving both experiences during the transition.

The underlying architectural concept remains the same:

Microsoft Sentinel operates on top of a Log Analytics workspace.

10. Workspace Resource Groups

A resource group can be used to organize the Azure resources associated with Microsoft Sentinel.

For example:

			
Security Resource Group
        |
        +-- Log Analytics Workspace
        |
        +-- Microsoft Sentinel
        |
        +-- Supporting Security Resources
        |
        +-- Workbooks
        |
        +-- Other Sentinel Resources

		

Keeping Sentinel-related resources organized can simplify:

RBAC assignments
Resource management
Governance
Administration
Lifecycle management

Microsoft’s current unified security operations deployment guidance recommends placing Microsoft Sentinel-related resources in a common security resource group when appropriate and assigning Sentinel permissions at the resource-group level to simplify administration.

11. Microsoft Sentinel Roles and Permissions

Security teams should use Azure role-based access control (RBAC) to provide users with only the access they need.

Common Sentinel-specific roles include:

Role	General purpose
Microsoft Sentinel Reader	View Sentinel resources and data
Microsoft Sentinel Responder	Respond to incidents and perform appropriate response actions
Microsoft Sentinel Contributor	Manage Sentinel resources and security content
Microsoft Sentinel Playbook Operator	Manage or execute applicable playbook operations
Log Analytics Reader	Read Log Analytics data
Log Analytics Contributor	Manage Log Analytics resources and configurations

The exact permissions required depend on the operation being performed.

For example, an analyst who only needs to view Sentinel information should not automatically be given Contributor permissions.

Microsoft’s current guidance identifies the Microsoft Sentinel Reader role as the minimum Sentinel-specific permission for an analyst who only needs to view Microsoft Sentinel data.

12. Least Privilege Is Important

The principle of least privilege is particularly important in a SIEM because Sentinel can expose highly sensitive security information.

Consider these users:

User	Appropriate access
SOC analyst	Reader or appropriate incident-response permissions
Incident responder	Responder
Sentinel administrator	Contributor
Security architect	Permissions based on required administrative duties
Auditor	Read-only access

Avoid giving every security employee Contributor or Owner permissions.

Exam Tip: When a question asks how to give an analyst access while minimizing privileges, look for a read-oriented RBAC role, not Owner or Contributor.

13. Connecting Data Sources

Creating a workspace does not automatically populate it with security data.

You must configure data connectors to ingest data from the systems you want Microsoft Sentinel to monitor.

Examples include:

Azure resources
Microsoft Entra ID
Microsoft Defender products
Windows systems
Linux systems
Network devices
Third-party security products
Cloud platforms
Applications

Conceptually:

			
Microsoft Entra ID ----+
Azure Activity --------+
Microsoft Defender ----+
Windows ---------------+----> Microsoft Sentinel
Linux -----------------+
Firewall --------------+
Third-party Apps ------+

		

Data connectors establish the path by which security data enters the Sentinel environment.

14. Data Retention

Retention is another important workspace design consideration.

Organizations should determine how long security data needs to remain available for:

Threat investigation
Threat hunting
Incident response
Compliance
Forensics
Historical analysis

Retention requirements can differ between organizations and even between different categories of data.

Microsoft’s current Sentinel onboarding guidance notes that organizations should configure appropriate data-retention and archive policies in Azure Monitor Logs.

Important distinction

Do not confuse:

Workspace retention
Archive/long-term retention
Data ingestion
Data connector configuration

These are related but separate concepts.

15. Managing Multiple Tenants

Large organizations and MSSPs may need to monitor Sentinel workspaces across multiple Microsoft Entra tenants.

Azure Lighthouse can provide delegated management capabilities across tenants.

For example:

                    Central SOC
                        |
                  Azure Lighthouse
                        |
        +---------------+---------------+
        |               |               |
        v               v               v
    Tenant A         Tenant B        Tenant C
        |               |               |
    Sentinel         Sentinel        Sentinel
    Workspace        Workspace       Workspace

This can be useful for:

MSSPs
Global organizations
Organizations with multiple Entra tenants
Central security operations teams

Azure Lighthouse supports management of multiple Sentinel workspaces across tenants, including scenarios involving cross-workspace queries, workbooks, and security operations.

16. When Should You Use Multiple Workspaces?

A common exam scenario is determining whether an organization should use one workspace or several.

Consider multiple workspaces when there is a meaningful requirement such as:

Regulatory separation

Different jurisdictions may have different data requirements.

Different security boundaries

Separate business units may need strict separation.

Different retention requirements

One organization might require different retention periods for different data sets.

Multiple tenants

A global organization may operate multiple Microsoft Entra tenants.

MSSP scenarios

An MSSP may manage Sentinel environments belonging to multiple customers.

Data ownership

Different organizations or subsidiaries may need to maintain control over their own security data.

Microsoft’s current guidance highlights scenarios such as MSSPs, global SOCs, multiple tenants, granular access control, data privacy, and regulatory compliance as reasons a multiple-workspace architecture may be appropriate.

17. When Should You Avoid Multiple Workspaces?

Multiple workspaces introduce complexity.

They can complicate:

Queries
Analytics rules
Workbooks
Data management
Permissions
Administration
Investigations
Content deployment

Therefore, don’t create separate workspaces simply because different departments exist.

Instead, ask:

Is there a security, compliance, operational, or architectural reason to separate the data?

If the answer is no, a single workspace may be simpler.

18. Workspace Architecture Decision Matrix

Requirement	Likely approach
Small organization with centralized SOC	Single workspace
One tenant and centralized security	Single workspace
Different regulatory boundaries	Multiple workspaces may be appropriate
Multiple Entra tenants	Multiple workspaces may be appropriate
MSSP managing customer environments	Multiple workspaces/tenants
Different data-retention requirements	Multiple workspaces may be appropriate
Need strict business-unit isolation	Multiple workspaces may be appropriate
No compelling separation requirement	Prefer simpler single-workspace design

The important exam principle is:

Choose the simplest architecture that satisfies the organization’s requirements.

19. Workspace Manager

For organizations operating multiple Sentinel workspaces, Microsoft provides capabilities to manage workspaces at scale.

Workspace Manager can be used to centrally manage member workspaces and organize them into groups based on factors such as:

Business unit
Geography
Organizational structure
Other operational requirements

Microsoft’s current documentation describes onboarding member workspaces and organizing them into workspace-manager groups for centralized management.

This is different from simply creating multiple workspaces. The purpose is to make the resulting environment easier to manage consistently.

20. Multiple-Workspace Incident Management

Security teams may need to investigate incidents across multiple Sentinel workspaces.

Microsoft provides multiple-workspace capabilities for this purpose.

For example:

			
Workspace A ----+
Workspace B ----+----> Central SOC
Workspace C ----+
Workspace D ----+

Current multiple-workspace functionality allows security teams to view incidents from multiple workspaces and, where supported, across tenants. Microsoft currently documents a maximum of 100 concurrently displayed workspaces in the multiple-workspace incident view.

However, permissions still matter. A user needs the appropriate permissions on the workspaces involved in an operation.

21. Connecting Versus Ingesting Data

One of the most important conceptual distinctions is:

Connecting a workspace to Microsoft Sentinel is not the same thing as connecting a data source to Sentinel.

For example:

			
Log Analytics Workspace
        |
        +-- Microsoft Sentinel
                |
                +-- Data Connector: Azure Activity
                +-- Data Connector: Entra ID
                +-- Data Connector: Defender XDR
                +-- Data Connector: Firewall

		

The workspace provides the foundation.

Data connectors bring security information into that foundation.

This distinction frequently appears in certification questions.

22. A Typical Deployment Sequence

A practical deployment can follow this sequence:

Step 1 — Plan the architecture

Determine:

Number of tenants
Number of workspaces
Data residency
Regulatory requirements
Retention
Access control
Security operations structure

Step 2 — Create or identify a Log Analytics workspace

Select:

Subscription
Resource group
Region
Workspace configuration

Step 3 — Enable Microsoft Sentinel

Add Microsoft Sentinel to the Log Analytics workspace.

Step 4 — Connect the workspace to Microsoft Defender

For organizations using the unified Defender experience, connect the workspace and configure its role in the Defender portal.

Step 5 — Configure permissions

Apply appropriate Azure RBAC roles.

Step 6 — Configure data connectors

Connect the required data sources.

Step 7 — Configure retention

Set appropriate retention and archive policies.

Step 8 — Deploy security content

Configure:

Analytics rules
Workbooks
Automation rules
Playbooks
Watchlists
Other Sentinel content

Step 9 — Validate data ingestion

Confirm that expected events are arriving in the workspace.

23. Common Mistakes

Mistake 1: Assuming Sentinel is a standalone Log Analytics replacement

It isn’t.

Microsoft Sentinel is added to a Log Analytics workspace.

Mistake 2: Creating a new workspace without evaluating existing ones

An organization may already have an appropriate Log Analytics workspace.

Creating unnecessary workspaces can increase operational complexity.

Mistake 3: Assuming one workspace is always correct

Single-workspace architecture is often simpler, but regulatory, organizational, tenant, or operational requirements can justify multiple workspaces.

Mistake 4: Giving analysts excessive permissions

An analyst who only needs to view data does not necessarily need Contributor or Owner permissions.

Mistake 5: Assuming that enabling Sentinel automatically collects all security data

Data connectors must be configured for the relevant data sources.

Mistake 6: Confusing workspace architecture with data connectors

Workspace architecture determines where Sentinel data is organized and managed.

Data connectors determine how particular data sources send data to Sentinel.

Mistake 7: Ignoring data residency

The workspace’s region can be an important architectural and compliance consideration.

24. Key Exam Comparisons

Concept	Remember
Log Analytics workspace	Underlying workspace used by Sentinel
Microsoft Sentinel	SIEM/security operations capabilities
Data connector	Brings data from a source into Sentinel
Analytics rule	Detects patterns or conditions in data
Incident	Security case generated from alerts/detections
Single workspace	Simpler centralized architecture
Multiple workspaces	Used when separation or organizational requirements justify it
Primary workspace	Central Sentinel workspace in supported Defender portal multi-workspace scenarios
Azure Lighthouse	Helps manage resources across tenants
RBAC	Controls user access to Sentinel resources/data
Retention	Determines how long data remains available
Defender portal	Current unified experience for Microsoft security operations

25. Exam-Focused Scenario

Scenario

A multinational company has:

Three Microsoft Entra tenants
Separate security teams for each tenant
Different regulatory requirements
A central SOC that needs visibility across all environments

Which architecture is most appropriate?

The strongest answer would generally involve multiple Sentinel workspaces aligned with the tenant/security requirements, combined with centralized management capabilities.

Why?

Because the organization has legitimate architectural reasons for separation:

Multiple tenants
Different security boundaries
Regulatory requirements
Centralized SOC requirements

This is substantially different from a company with one tenant and one centralized security team that has no data-isolation requirements.

26. SC-500 Exam Tips

Exam Tip 1: Remember the relationship:

Log Analytics workspace → Microsoft Sentinel

Exam Tip 2: If the question asks where Sentinel stores/analyzes its collected log data, think Log Analytics workspace.

Exam Tip 3: If the question asks how data enters Sentinel, think data connectors.

Exam Tip 4: If the question asks whether to use one or multiple workspaces, look for requirements involving regulatory boundaries, data residency, access isolation, multiple tenants, MSSP operations, or different retention requirements.

Exam Tip 5: If the requirement is simply centralized security operations without a compelling separation requirement, a single workspace is often the simpler design.

Exam Tip 6: Remember that Microsoft Sentinel can be managed through the Microsoft Defender portal, and Microsoft’s current roadmap is moving Sentinel away from the Azure portal experience.

Exam Tip 7: Don’t confuse Azure Lighthouse with Microsoft Sentinel itself. Lighthouse provides delegated management capabilities across tenants; it is not the Sentinel data store.

Exam Tip 8: Apply least privilege. A user who only needs to view Sentinel data generally shouldn’t receive Contributor or Owner access.

27. Key Takeaways

The most important concepts to remember for the SC-500 exam are:

Microsoft Sentinel is added to a Log Analytics workspace.
A Log Analytics workspace provides the underlying location for Sentinel data.
Sentinel provides SIEM and security operations capabilities on that data.
Data connectors bring data from individual sources into Sentinel.
A single workspace is often the simplest architecture.
Multiple workspaces can be appropriate for regulatory, security, organizational, tenant, or operational reasons.
Microsoft Defender supports managing Sentinel workspaces through its unified security operations experience.
Azure Lighthouse can help manage Sentinel environments across multiple tenants.
Azure RBAC should be used to implement least-privilege access.
Workspace region, data retention, and data residency should be considered during architecture planning.
Creating a workspace and configuring data connectors are separate activities.
Current Microsoft Sentinel architecture supports primary and secondary workspace concepts in the Defender portal for applicable multi-workspace scenarios.
Avoid unnecessary workspace proliferation because multiple workspaces increase operational complexity.

Practice Exam Questions

Question 1

A company is implementing Microsoft Sentinel for the first time. The security team wants to use an existing Azure Monitor Logs environment as the foundation for Sentinel.

What should the team use?

A. An existing Log Analytics workspace

B. An Azure Storage account

C. An Azure Key Vault

D. An Azure Data Explorer cluster

Answer: A

Explanation

Microsoft Sentinel is added to a Log Analytics workspace. The organization does not need to create a separate Sentinel-specific data store. An existing suitable Log Analytics workspace can be used.

Azure Storage, Key Vault, and Azure Data Explorer serve different purposes and are not the underlying workspace required for a standard Microsoft Sentinel deployment.

Question 2

An organization has one Microsoft Entra tenant, one centralized SOC, no special regulatory separation requirements, and no requirement for separate data-retention policies.

Which workspace architecture should the security architect consider first?

A. One workspace for every Azure subscription

B. One workspace for every department

C. A single Microsoft Sentinel workspace

D. A separate workspace for every data connector

Answer: C

Explanation

There is no stated requirement that justifies separating the environment. A single workspace generally provides a simpler architecture for centralized security operations.

Creating unnecessary workspaces increases administrative and operational complexity. Microsoft currently recommends a single-workspace environment when practical.

Question 3

A multinational organization has separate Microsoft Entra tenants for its European and North American operations. The organization also has different regulatory requirements governing security data in each environment.

What is the strongest reason to consider multiple Microsoft Sentinel workspaces?

A. To allow users to run different versions of KQL

B. To provide appropriate separation for tenant and regulatory requirements

C. To eliminate the need for data connectors

D. To prevent Microsoft Sentinel from using Log Analytics

Answer: B

Explanation

Multiple tenants and different regulatory requirements are legitimate reasons to consider multiple workspaces. Workspace architecture can provide separation of data, access, and operational boundaries while still allowing centralized security operations where appropriate.

The other answers incorrectly describe the purpose of multiple workspaces.

Question 4

A security administrator creates a new Log Analytics workspace but cannot find any security events in Microsoft Sentinel.

What should the administrator do next?

A. Create an Azure Storage account

B. Assign every analyst the Owner role

C. Configure the appropriate Microsoft Sentinel data connectors

D. Delete and recreate the Log Analytics workspace

Answer: C

Explanation

Creating the workspace and enabling Sentinel does not automatically cause every desired security data source to send data to Sentinel. The appropriate data connectors must be configured.

For example, Azure Activity data requires the corresponding connector and configuration to begin sending events to Sentinel.

Question 5

A security analyst only needs to view Microsoft Sentinel data and investigate information without administering Sentinel configuration.

Which approach best follows least-privilege principles?

A. Assign Azure Owner

B. Assign Microsoft Sentinel Reader

C. Assign Microsoft Sentinel Contributor

D. Assign Subscription Administrator

Answer: B

Explanation

The Microsoft Sentinel Reader role is designed for read access and is appropriate when the user needs to view Sentinel information without requiring broad administrative permissions.

Giving the analyst Owner, Contributor, or subscription-level administrative permissions would provide substantially more access than required. Microsoft’s current unified security operations guidance identifies Sentinel Reader as the minimum Sentinel-specific permission for an analyst who only needs to view Sentinel data.

Question 6

A company is deciding whether to create separate Sentinel workspaces for each business unit. All business units:

Use the same Microsoft Entra tenant.
Have the same regulatory requirements.
Use the same retention requirements.
Are monitored by the same SOC.

What should the architect generally do?

A. Prefer a single workspace unless another requirement justifies separation

B. Create a workspace for every business unit

C. Create a workspace for every data source

D. Create a workspace for every security analyst

Answer: A

Explanation

There is no stated requirement for data or security separation. A single workspace can simplify queries, administration, security operations, and data management.

Multiple workspaces should be introduced when there is a meaningful architectural reason, rather than simply because an organization has multiple departments.

Question 7

An MSSP needs to manage Microsoft Sentinel workspaces belonging to multiple customer Microsoft Entra tenants. The MSSP wants delegated cross-tenant management capabilities.

Which Azure service is most appropriate?

A. Azure Key Vault

B. Azure Policy

C. Microsoft Entra ID Protection

D. Azure Lighthouse

Answer: D

Explanation

Azure Lighthouse provides delegated management capabilities across Azure tenants and can be used to manage multiple Microsoft Sentinel environments at scale.

This is particularly relevant to MSSP scenarios in which a central SOC needs to manage Sentinel environments belonging to multiple customers.

Question 8

Which statement best describes the relationship between Microsoft Sentinel and a Log Analytics workspace?

A. Microsoft Sentinel replaces the Log Analytics workspace

B. A Log Analytics workspace is optional when Sentinel is deployed

C. Microsoft Sentinel is enabled on a Log Analytics workspace

D. Log Analytics is only used for storing archived Sentinel data

Answer: C

Explanation

Microsoft Sentinel is added to a Log Analytics workspace. The workspace provides the underlying environment for the data Sentinel analyzes.

This relationship is fundamental to Sentinel architecture and is one of the most important concepts to remember for the exam.

Question 9

An organization has several Sentinel workspaces because of regulatory and organizational requirements. The central SOC needs to monitor incidents across those workspaces.

Which capability is designed for this scenario?

A. Multiple-workspace capabilities

B. Azure Key Vault

C. Azure Bastion

D. Microsoft Defender Vulnerability Management

Answer: A

Explanation

Microsoft Sentinel provides multiple-workspace capabilities that allow security teams to work across multiple Sentinel workspaces. Current functionality supports viewing incidents across selected workspaces and, in supported scenarios, across tenants.

The other services address different security requirements.

Question 10

An organization has connected its Sentinel workspace to the Microsoft Defender portal. The security team now wants to start receiving logs from Microsoft Entra ID.

Which statement is correct?

A. Connecting the workspace automatically enables every available security data source

B. The appropriate data connector must be configured

C. A second Sentinel workspace must be created

D. Azure Lighthouse must be configured

Answer: B

Explanation

Connecting or onboarding the Sentinel workspace establishes the Sentinel environment, but individual data sources still need to be configured appropriately.

Data connectors provide the mechanisms for bringing data from services and applications into Microsoft Sentinel.

Therefore, the team should configure the appropriate Microsoft Entra ID data connector rather than create another workspace or configure Azure Lighthouse.

Go to the SC-500 Exam Prep Hub main page

azure, Cloud computing, Cybersecurity, Microsoft Certification, SC-500, security October 10, 2026

Plan and implement Azure Bastion (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)
      --> Plan and implement Azure Bastion

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

Azure Bastion is a fully managed Azure platform service that provides secure Remote Desktop Protocol (RDP) and Secure Shell (SSH) connectivity to Azure virtual machines.

Instead of exposing RDP or SSH directly to the public internet, administrators connect to Azure Bastion through the Azure portal or, when supported, through a native RDP or SSH client. Bastion then connects to the target virtual machine over its private IP address.

Azure Bastion is particularly useful for reducing the attack surface of administrative access to virtual machines. It helps eliminate the need to assign public IP addresses to VMs solely for remote management.

For the SC-500 exam, you should understand:

Why Azure Bastion is used.
How Bastion is deployed in a virtual network.
The purpose of the AzureBastionSubnet.
Bastion SKU differences.
Browser-based and native-client connections.
Private-only Bastion deployments.
Bastion integration with network security controls.
How to select the appropriate SKU.
Common deployment and connectivity problems.

Why Azure Bastion Is Important

Traditional remote administration often requires exposing:

RDP on TCP port 3389.
SSH on TCP port 22.

Exposing these ports directly to the internet increases the attack surface and can make virtual machines targets for:

Password attacks.
Credential stuffing.
Brute-force attacks.
Exploitation of protocol vulnerabilities.
Port scanning.
Automated reconnaissance.

Azure Bastion provides an alternative administrative access pattern:

The administrator signs in to Azure.
The administrator selects a virtual machine.
The administrator chooses Connect > Bastion.
Azure Bastion establishes the RDP or SSH connection.
The session is presented through the browser or a supported native client.
The VM is accessed through its private IP address.

The target VM does not need:

A public IP address.
An RDP or SSH agent.
Special client software for browser-based access.
Direct internet exposure of management ports.

Bastion is therefore a network-security control for administrative access, not a replacement for identity security or VM hardening.

Azure Bastion Architecture

Dedicated Bastion Deployment

For the Basic, Standard, and Premium SKUs, Azure Bastion is deployed into a dedicated subnet named:

AzureBastionSubnet

The subnet must be reserved for Azure Bastion. Other Azure resources should not be deployed into it.

For dedicated Bastion deployments, Microsoft recommends a subnet of at least /26 to support scaling and future feature requirements. The subnet can be larger, such as /25 or /24.

A typical architecture is:

			
Administrator
     |
     | HTTPS/TLS
     v
Azure Bastion
     |
     | Private RDP or SSH
     v
Azure Virtual Machine

		

The VM can remain without a public IP address.

Bastion in a Hub-and-Spoke Network

Azure Bastion can support connections to VMs in:

The same virtual network.
Peered virtual networks, when supported by the selected SKU and architecture.

A common enterprise design is to deploy Bastion in a central hub virtual network and use virtual network peering to access VMs in spoke virtual networks.

This allows an organization to centralize administrative access instead of deploying a separate Bastion resource in every spoke.

The selected SKU must support virtual network peering. The Developer SKU does not support peered virtual network connections.

Azure Bastion SKUs

Azure Bastion provides four SKUs:

Developer.
Basic.
Standard.
Premium.

The SKU affects:

Cost.
Deployment architecture.
Number of supported connections.
Scaling.
Native-client support.
File transfer.
Custom ports.
Shareable links.
Session recording.
Private-only deployment.

Developer SKU

The Developer SKU is intended for development and testing.

Characteristics include:

No additional Bastion hourly charge.
Shared infrastructure.
One VM connection at a time.
Browser-based access.
Support for RDP to Windows VMs.
Support for SSH to Linux VMs.
No virtual network peering.
Limited feature set.
Availability only in selected regions.

The Developer SKU is not intended for production workloads because it uses shared infrastructure and supports only one VM connection at a time.

Use Developer when:

The environment is for development or testing.
Cost is a major consideration.
Only occasional browser-based access is required.
Advanced features are unnecessary.
The region supports the Developer SKU.

Basic SKU

The Basic SKU provides a dedicated Bastion deployment with fixed capacity.

It supports:

Browser-based RDP.
Browser-based SSH.
Connections to VMs in the same or peered virtual networks.
Dedicated Bastion infrastructure.

The Basic SKU does not provide several advanced capabilities, including:

Native-client connections.
Shareable links.
IP-based connections.
Custom inbound ports.
File transfer through the native client.
Configurable host scaling.

Basic is appropriate when an organization needs a dedicated production deployment but does not require advanced connection features.

Standard SKU

The Standard SKU includes the Basic features and adds advanced capabilities such as:

Native RDP and SSH client connections.
Configurable host scaling.
Shareable links.
IP-based connections.
Custom inbound ports.
File upload and download.
Higher connection capacity.
Ability to configure additional Bastion features.

The Standard SKU is appropriate when administrators need to connect using local RDP or SSH clients or when the organization needs greater scalability.

Premium SKU

The Premium SKU includes Standard features and adds:

Session recording.
Private-only deployment.
No public IP address on the Bastion resource in a private-only architecture.

Premium is appropriate when an organization requires:

High-security administrative access.
Session audit trails.
Compliance-oriented session recording.
A fully private Bastion deployment.
Stronger restrictions on internet exposure.

The Premium SKU is the most appropriate choice when the requirement explicitly states that Bastion itself must not have a public IP address.

SKU Comparison

Capability	Developer	Basic	Standard	Premium
Intended use	Development and testing	Dedicated production access	Advanced production access	High-security production access
Dedicated infrastructure	No	Yes	Yes	Yes
Browser-based RDP and SSH	Yes	Yes	Yes	Yes
Same-VNet connectivity	Yes	Yes	Yes	Yes
Peered-VNet connectivity	No	Yes	Yes	Yes
Concurrent connections	One VM at a time	Fixed capacity	Configurable scaling	Configurable scaling
Native RDP/SSH client	No	No	Yes	Yes
Custom ports	No	No	Yes	Yes
IP-based connections	No	No	Yes	Yes
Shareable links	No	No	Yes	Yes
File transfer	No	No	Yes	Yes
Session recording	No	No	No	Yes
Private-only deployment	No	No	No	Yes
Hourly Bastion charge	No	Yes	Yes	Yes

The exact capacity depends on the SKU, number of Bastion instances, connection type, and current service limits. Standard and Premium support host scaling, while Basic provides fixed capacity.

Selecting the Correct SKU

Use the following decision process.

Choose Developer when:

The workload is development or testing.
One VM connection at a time is sufficient.
No peered-network access is required.
No advanced features are required.
The region supports Developer.

Choose Basic when:

A dedicated deployment is required.
Browser-based RDP and SSH are sufficient.
Fixed capacity is acceptable.
Native-client access is not required.
Session recording is not required.
Private-only deployment is not required.

Choose Standard when:

Native RDP or SSH clients are required.
File transfer is required.
Custom ports are required.
Shareable links are required.
IP-based connections are required.
Host scaling is required.
Higher connection concurrency is needed.

Choose Premium when:

Session recording is required.
Bastion must use a private-only deployment.
The Bastion resource must not have a public IP address.
Compliance requires administrative session audit trails.
The workload has stringent security requirements.

A common exam clue is:

“The VM must not have a public IP address.”

This requirement alone does not necessarily require Premium. Basic, Standard, and Premium can provide access to VMs without public IP addresses.

A different requirement is:

“Bastion itself must not have a public IP address.”

That points to a Premium private-only deployment.

Deploying Azure Bastion

Deployment Prerequisites

Before deploying Bastion, verify:

The target virtual network exists.
The virtual network is in a supported region.
The target VM is deployed in the same or a peered virtual network.
The required subnet exists.
The subnet is named AzureBastionSubnet.
The subnet is at least /26 for dedicated deployments.
The selected SKU supports the required features.
The required public IP configuration is available.
Network security rules do not block required Bastion traffic.
The administrator has sufficient Azure permissions.

For Basic, Standard, and Premium deployments, the subnet is dedicated to Bastion.

Do not deploy virtual machines, Azure Firewall, NAT Gateway, or other unrelated resources into AzureBastionSubnet.

Deploying from the Azure Portal

A typical portal deployment process is:

Sign in to the Azure portal.
Open the target virtual network or virtual machine.
Select Connect > Bastion, or create a Bastion resource.
Select the appropriate subscription.
Select or create a resource group.
Select the target virtual network.
Select the Bastion SKU.
Configure the AzureBastionSubnet.
Configure the public IP address if required.
Configure optional advanced features.
Select Review + create.
Validate the configuration.
Select Create.

Dedicated Bastion deployments generally take longer to provision than the Developer SKU.

Public IP Requirements

For standard dedicated deployments:

Basic requires a public IP address.
Standard requires a public IP address.
Premium can use a public IP address or a private-only deployment.

The public IP address is associated with Bastion, not with the target VM.

The target VM can remain accessible only through its private IP address.

For a private-only Premium deployment:

Bastion has no public IP address.
Administrative connectivity must use private network connectivity.
The administrator must have an appropriate path into the virtual network, such as a corporate network connection, private connectivity, or another approved access mechanism.

Private-only Bastion is therefore useful for environments that require no internet-routable Bastion endpoint.

Connecting to Virtual Machines

Browser-Based Connections

Browser-based connections use the Azure portal and an HTML5 web client.

The administrator:

Opens the virtual machine in the Azure portal.
Selects Connect.
Selects Bastion.
Selects the connection protocol.
Provides the required credentials.
Selects Connect.

For Windows VMs, the default RDP port is usually:

For Linux VMs, the default SSH port is usually:

Browser-based connections do not require a public IP address on the VM or special client software on the administrator’s computer.

RDP Connections

RDP is normally used to connect to Windows virtual machines.

The user must have the appropriate rights on the target VM. Depending on the authentication method, the user may need to be:

A local administrator.
A member of the Remote Desktop Users group.
Assigned an appropriate Microsoft Entra VM login role.

SSH Connections

SSH is normally used to connect to Linux virtual machines.

The administrator may authenticate using:

A username and password, where supported.
An SSH private key.
Microsoft Entra ID authentication, where supported and configured.

The VM must be configured to accept the selected authentication method.

Native-Client Connections

The native-client feature allows administrators to use the RDP or SSH client installed on their local computer instead of using only the browser-based client.

Native-client support requires:

Standard or Premium SKU.
Native-client support enabled.
Appropriate VM and authentication configuration.
Azure CLI for supported connection workflows.

Native-client connections can support additional capabilities, such as:

Local RDP or SSH client use.
Microsoft Entra authentication.
File transfer for supported connection types.
Custom ports.
Multiple concurrent VM sessions.

Session recording is not available for native-client connections. Session recording is a Premium feature for supported browser-based sessions.

Native-Client Limitations

Important limitations include:

Native-client support is not available with Developer or Basic.
Native-client connections are not supported from Azure Cloud Shell.
SSH private keys stored in Azure Key Vault cannot be used directly for native-client sign-in.
The private key must be available as a file on the local computer when using that authentication method.
Capabilities vary depending on the local client, target VM, protocol, and Bastion configuration.

Network Security Considerations

Azure Bastion reduces the need to expose RDP and SSH ports publicly, but network security rules still matter.

Network Security Groups

Network Security Groups can be used to control traffic to and from subnets and network interfaces.

When using Bastion, ensure that NSG rules do not unintentionally block:

Required Bastion control-plane traffic.
Bastion-to-VM RDP traffic.
Bastion-to-VM SSH traffic.
Required Azure platform communication.

For native-client configurations, administrators may use NSG rules to restrict access to required ports such as:

TCP 22 for SSH.
TCP 3389 for RDP.

Custom ports require Standard or Premium.

User-Defined Routes

User-defined routes are not supported on the Azure Bastion subnet.

This is important when designing a network that also contains:

Azure Firewall.
Network virtual appliances.
Custom routing.
Hub-and-spoke network topologies.

Bastion-to-VM communication is private, and traffic does not generally need to be forced through Azure Firewall by applying a user-defined route to AzureBastionSubnet.

Azure Firewall

Azure Firewall and Azure Bastion serve different purposes:

Azure Bastion provides administrative RDP and SSH connectivity.
Azure Firewall provides centralized traffic inspection and filtering.

They can be deployed in the same overall network architecture, but they should not be treated as interchangeable services.

Azure Bastion and Just-in-Time VM Access

Azure Bastion and Just-in-Time VM access solve related but different problems.

Azure Bastion

Azure Bastion:

Provides a secure access path to VMs.
Reduces the need for public IP addresses.
Avoids exposing RDP and SSH directly to the internet.
Provides browser-based or native-client connectivity.

Just-in-Time VM Access

Just-in-Time VM access:

Opens management ports only when access is requested.
Limits the duration of access.
Creates temporary network security rules.
Is useful for VMs that still require public management access.

Bastion is generally the better choice when the goal is to eliminate public management exposure altogether.

Just-in-Time access may be useful when a VM must retain a public IP address or when direct access is required for a specific operational scenario.

The two controls can be evaluated independently and may be used together where appropriate.

Azure Bastion and Point-to-Site VPN

Azure Bastion provides access to virtual machines through RDP and SSH.

A point-to-site VPN provides network-level access from an individual client into an Azure virtual network.

Use Azure Bastion when administrators need:

RDP or SSH access to VMs.
A browser-based administrative experience.
No public IP address on the VM.
A controlled access path to specific virtual machines.

Use point-to-site VPN when administrators need access to:

Databases.
Internal web applications.
Storage services.
Multiple private network resources.
Other services that are not accessed through RDP or SSH.

A VPN provides broader network access, while Bastion focuses primarily on secure VM administration.

Managing Bastion Sessions

Depending on the SKU and connection method, Bastion may support:

Copy and paste.
Full-screen sessions.
File upload.
File download.
Custom ports.
Shareable links.
Session recording.

Shareable Links

Shareable links allow users to connect to a specific VM without navigating through the Azure portal in the usual way.

They are available with Standard and Premium and should be governed carefully because they can simplify access distribution.

Use them only when:

The recipient is authorized.
The link is distributed securely.
The organization understands the access implications.
The link is revoked or allowed to expire when no longer needed.

Session Recording

Session recording is available with Premium for supported browser-based sessions.

It can help organizations:

Review administrative activity.
Support compliance requirements.
Investigate suspicious behavior.
Establish an audit trail for privileged access.

Session recording should not be assumed to apply to native-client sessions. Native-client sessions do not support session recording.

Monitoring and Troubleshooting

When Bastion connectivity fails, investigate the following areas.

Bastion Resource State

Check:

Provisioning state.
SKU.
Region.
Configuration settings.
Health status.
Availability.
Recent deployment changes.

Virtual Network

Verify:

The VM is in the expected virtual network.
Peering is configured correctly.
Peering is in a connected state.
Address spaces do not overlap.
Required routes are available.
The VM has a private IP address.

Subnet

For dedicated deployments, verify:

The subnet is named AzureBastionSubnet.
The subnet is at least /26.
No unrelated resources are deployed in the subnet.
NSG configuration is compatible with Bastion.
No unsupported user-defined routes are applied.

VM Configuration

Verify:

The VM is running.
The operating system supports the selected protocol.
RDP or SSH is enabled.
The required service is running.
The VM’s guest firewall permits the connection.
The user has the required permissions.
The selected port is correct.

Authentication

Check:

Username and password.
SSH key.
Microsoft Entra authentication configuration.
VM login role assignments.
Local group membership.
Credential expiration.
Conditional Access requirements.

SKU Features

A connection may fail or an option may be unavailable because the SKU does not support it.

Examples:

Native-client option missing: use Standard or Premium.
Custom port unavailable: use Standard or Premium.
Session recording unavailable: use Premium for supported browser sessions.
Private-only deployment unavailable: use Premium.
Peered-VNet access unavailable: do not use Developer.

Common Mistakes to Avoid

Mistake 1: Deploying resources into `AzureBastionSubnet`

The Bastion subnet is reserved for Azure Bastion.

Mistake 2: Using a subnet that is too small

Dedicated Bastion deployments should use at least a /26 subnet to support current and future requirements.

Mistake 3: Assuming Basic supports native-client connections

Native-client connections require Standard or Premium.

Mistake 4: Assuming Premium is required just because the VM has no public IP

All dedicated Bastion SKUs can provide access to VMs without public IP addresses. Premium is required when Bastion itself must be private-only.

Mistake 5: Assuming Bastion replaces RBAC

Azure Bastion provides network access, but users still need appropriate permissions on the Bastion resource, virtual network, VM, and operating system.

Mistake 6: Applying unsupported user-defined routes to the Bastion subnet

User-defined routes are not supported on AzureBastionSubnet.

Mistake 7: Assuming session recording works with native clients

Session recording is not available for native-client connections.

Mistake 8: Using Developer in production

Developer is designed for development and testing and supports only one VM connection at a time.

Mistake 9: Ignoring VM-level firewalls

Bastion does not bypass the VM’s operating system firewall or authentication requirements.

Mistake 10: Confusing Bastion with a VPN

Bastion provides RDP and SSH access. A VPN provides broader network-level connectivity.

Key Takeaways

For the SC-500 exam, remember:

Azure Bastion provides secure RDP and SSH access to Azure VMs.
Bastion reduces the need to expose VM management ports to the internet.
Target VMs do not need public IP addresses.
Dedicated Bastion deployments use AzureBastionSubnet.
The dedicated subnet should be at least /26.
The Bastion subnet is reserved for Bastion.
Developer is intended for development and testing.
Basic provides dedicated browser-based access with fixed capacity.
Standard adds native clients, scaling, custom ports, file transfer, and other advanced features.
Premium adds session recording and private-only deployment.
Native-client support requires Standard or Premium.
Private-only Bastion requires Premium.
Session recording is not available for native-client sessions.
User-defined routes are not supported on the Bastion subnet.
Bastion and Just-in-Time VM access are different controls.
Bastion provides VM administration, while VPN provides broader network access.
VM-level permissions and firewalls still apply.
SKU selection should be based on required features, capacity, and security requirements.

Practice Exam Questions

Question 1

An organization wants administrators to connect to Azure VMs through the Azure portal without assigning public IP addresses to the VMs.

Which service should the organization use?

A. Azure Bastion
B. Azure DNS Private Resolver
C. Azure Application Gateway
D. Azure Load Balancer

Correct answer: A

Explanation: Azure Bastion provides browser-based RDP and SSH access to VMs through their private IP addresses. The VMs do not need public IP addresses for this access pattern.

Question 2

You are deploying a dedicated Azure Bastion resource. Which subnet configuration is required?

A. A subnet named GatewaySubnet with a /29 prefix
B. A subnet named AzureFirewallSubnet with a /27 prefix
C. A subnet named AzureBastionSubnet with at least a /26 prefix
D. A subnet named AppGatewaySubnet with a /28 prefix

Correct answer: C

Explanation: Dedicated Bastion deployments use a subnet named AzureBastionSubnet. A /26 or larger subnet is recommended and required for the supported dedicated deployment configuration.

Question 3

A development team needs free, browser-based access to one Azure VM at a time. The team does not need virtual network peering or advanced features.

Which Bastion SKU should you select?

A. Basic
B. Developer
C. Standard
D. Premium

Correct answer: B

Explanation: The Developer SKU is intended for development and testing, is available at no additional Bastion hourly charge, and supports one VM connection at a time.

Question 4

A production environment requires administrators to connect to VMs using the native RDP client installed on their local Windows computers.

Which minimum Bastion SKU is required?

A. Developer
B. Basic
C. Standard
D. None; native-client support is available with every SKU

Correct answer: C

Explanation: Native-client support requires the Standard or Premium SKU. Developer and Basic support browser-based connections but not native-client connections.

Question 5

A company requires Bastion itself to have no public IP address. Which configuration should be used?

A. Basic Bastion with a private VM IP address
B. Standard Bastion with a private VM IP address
C. Developer Bastion in a peered virtual network
D. Premium Bastion with private-only deployment

Correct answer: D

Explanation: Premium supports private-only deployment, in which Bastion does not use a public IP address. Other dedicated SKUs can access VMs privately but normally require a public IP address for Bastion.

Question 6

Which Bastion feature is available with Premium but not with Standard?

A. Browser-based SSH
B. Browser-based RDP
C. Session recording
D. Access to VMs in the same virtual network

Correct answer: C

Explanation: Premium adds session recording and private-only deployment. Browser-based RDP and SSH and same-VNet connectivity are available with lower dedicated SKUs.

Question 7

An administrator wants to apply a user-defined route to AzureBastionSubnet so that all Bastion traffic passes through an Azure Firewall.

What should the administrator know?

A. User-defined routes are not supported on the Bastion subnet
B. User-defined routes are required for every Bastion deployment
C. User-defined routes are supported only with Developer
D. User-defined routes are required to connect to VMs in the same virtual network

Correct answer: A

Explanation: User-defined routes are not supported on AzureBastionSubnet. Bastion-to-VM communication is private and does not generally require forcing traffic from the Bastion subnet through Azure Firewall.

Question 8

An organization needs to connect to VMs in multiple spoke virtual networks from a Bastion resource deployed in a hub virtual network.

Which requirement is important?

A. The Bastion resource must use Developer
B. Virtual network peering must be configured, and the selected SKU must support peered-VNet connectivity
C. Every VM must have a public IP address
D. All VMs must be in the same subnet as Bastion

Correct answer: B

Explanation: Bastion can support VMs in peered virtual networks when peering is correctly configured and the selected SKU supports that capability. Developer does not support peered-VNet connections.

Question 9

A security team wants to use Azure Bastion to provide RDP and SSH access, but it also needs network-level access to private databases and internal web applications.

Which additional service may be appropriate?

A. Azure VPN Gateway with point-to-site connectivity
B. Azure Storage firewall
C. Azure Key Vault
D. Azure DDoS Protection

Correct answer: A

Explanation: Bastion focuses on RDP and SSH access to VMs. A point-to-site VPN provides broader network-level access to resources such as databases, storage, and internal applications.

Question 10

A company requires file transfer, custom inbound ports, host scaling, and native-client connections through Azure Bastion. Session recording is not required.

Which is the most appropriate minimum SKU?

A. Developer
B. Basic
C. Standard
D. Premium

Correct answer: C

Explanation: Standard supports native-client connections, file transfer, custom inbound ports, and configurable host scaling. Premium is unnecessary unless features such as session recording or private-only deployment are required.

Go to the SC-500 Exam Prep Hub main page

AI Security, Cloud computing, Cybersecurity, Microsoft Certification, SC-500, security October 10, 2026

Enable and enforce use of just-in-time (JIT) VM access (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)
      --> Enable and enforce use of just-in-time (JIT) VM access

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

Azure virtual machines often require inbound management access through protocols such as:

SSH — typically TCP port 22 for Linux VMs
RDP — typically TCP port 3389 for Windows VMs
WinRM — typically TCP ports 5985 and 5986

Leaving these ports permanently open increases the attack surface of a virtual machine. Attackers can continuously scan exposed management ports and attempt brute-force, credential-stuffing, or exploit-based attacks.

Just-in-time (JIT) VM access in Microsoft Defender for Cloud reduces this exposure by allowing inbound access to selected VM ports only when it is required, from an approved source IP address, and for a limited period.

JIT does not replace authentication, authorization, patching, or network segmentation. Instead, it adds a temporary network-access control layer around administrative access.

What Is Just-in-Time VM Access?

JIT VM access is a Microsoft Defender for Cloud capability that:

Identifies VM management ports that should not remain permanently exposed.
Creates or manages restrictive network rules for those ports.
Requires an authorized user to request temporary access.
Opens the requested ports only for the approved duration.
Restricts access to the requesting IP address or specified address range.
Restores the restrictive network configuration after the access window expires.

For example, an administrator may need to connect to a Linux VM using SSH. Instead of leaving port 22 open continuously, the administrator requests access for 30 minutes from their current public IP address. Defender for Cloud temporarily permits the connection and then closes the access window.

The basic security principle

Open administrative access only when needed, only to the required port, only from the required source, and only for the required duration.

Why JIT VM Access Is Important

1. Reduces the attack surface

Permanent inbound access to RDP or SSH gives attackers more opportunities to discover and target a VM. JIT minimizes the time during which these ports are reachable.

2. Reduces exposure to brute-force attacks

Because management ports remain restricted until access is requested, attackers cannot continuously attempt authentication against those ports during normal operation.

3. Supports least-privilege network access

JIT applies the principle of least privilege to network connectivity:

Only selected ports are opened.
Only selected source addresses are permitted.
Access is available only for a limited time.

4. Improves auditing

JIT access activity can be reviewed to determine:

Who requested access
Which VM was accessed
Which ports were opened
Which source IP address was used
When access was requested
When access expired

5. Helps enforce security standards

Organizations can use Azure Policy to identify or enforce the requirement that supported VMs use JIT access.

JIT VM Access Prerequisites

The principal prerequisite for Azure VM JIT access is:

Microsoft Defender for Servers Plan 2 must be enabled on the subscription.

The administrator also needs appropriate permissions to view, configure, or request JIT access.

Supported environments

JIT access supports Azure Resource Manager-based virtual machines. It can also work with supported VMs protected by Azure Firewall on the same virtual network.

Unsupported or restricted scenarios

Important limitations include:

Classic deployment-model VMs are not supported.
JIT does not support VMs protected by Azure Firewall configurations controlled by Azure Firewall Manager.
The Azure Firewall configuration must use the supported rules model.
A VM generally needs an appropriate NSG, Azure Firewall configuration, or both.
JIT is not a replacement for Azure Bastion, a VPN, or an identity provider.

How JIT Works with Network Security Groups

When JIT is enabled, Defender for Cloud creates or manages restrictive inbound rules for the selected ports.

For example, a VM might normally have the following inbound rule:

Priority	Source	Destination port	Action
100	Any	3389	Allow

This permanently exposes RDP to the internet.

With JIT, the selected management port is restricted until an authorized request is made. Defender for Cloud ensures that deny rules exist for the selected ports in the applicable NSG and/or Azure Firewall configuration.

When access is requested and approved, Defender for Cloud temporarily creates an allow rule for:

The selected port
The requesting source IP address or range
The requested duration

After the time window expires, the restrictive configuration is restored.

Important rule-processing consideration

Existing network rules can affect JIT behavior. If another rule already permits traffic to the selected port with a higher priority, that rule may take precedence over the JIT-generated rule.

Therefore, enabling JIT does not automatically correct every conflicting NSG or firewall rule. Administrators should review existing rules and ensure that permanent broad allow rules do not undermine the intended protection.

JIT Access Policy Settings

A JIT policy is configured for a VM and defines which ports can be opened temporarily.

For each protected port, the policy can specify:

Port number
Protocol
Allowed source IP addresses
Maximum request access duration

Common ports

Port	Protocol or service	Typical use
22	SSH	Linux administration
3389	RDP	Windows administration
5985	WinRM over HTTP	Windows remote management
5986	WinRM over HTTPS	Secure Windows remote management

The default recommendations commonly include ports 22, 3389, 5985, and 5986, although the actual ports should be based on the organization’s requirements. Custom ports can also be added.

Example policy

An organization might configure:

Setting	Value
Port	22
Protocol	TCP
Allowed source	Administrator’s public IP range
Maximum duration	1 hour

This means the administrator cannot request unlimited access to port 22. The request must remain within the maximum duration defined by the policy.

Enabling JIT Access in the Azure Portal

JIT can be enabled from Microsoft Defender for Cloud or from the Azure virtual machine experience.

From Microsoft Defender for Cloud

Open the Azure portal.
Open Microsoft Defender for Cloud.
Go to Workload protections.
Open Just-in-time VM access.
Select the Not configured virtual machines tab.
Select one or more eligible VMs.
Select Enable JIT on VMs.
Review the recommended ports.
Customize the ports, protocols, source addresses, and maximum duration.
Save the policy.

From the Virtual Machines page

Open Virtual machines in the Azure portal.
Select the target VM.
Open Configuration.
Locate Just-in-time access.
Select Enable just-in-time.
Review or modify the default configuration.
Save the settings.

For Windows VMs, the default RDP port is normally 3389. For Linux VMs, the default SSH port is normally 22. The default maximum access duration is commonly three hours, but this should be reduced when operationally practical.

Configuring JIT Access Securely

The default configuration may be functional but not sufficiently restrictive for a production environment.

Recommended configuration practices

Restrict source IP addresses

Avoid allowing access from Any unless there is a specific business requirement.

Prefer:

A corporate public IP range
A secured jump-host address
A VPN egress address
A privileged administrator workstation range

Use the shortest practical duration

If an administrator needs 20 minutes, do not configure a maximum duration of several hours without a reason.

Shorter access windows reduce exposure.

Protect only required ports

Do not enable JIT for unnecessary ports. If a VM is administered only through SSH, there may be no reason to expose RDP or WinRM.

Use custom ports carefully

Changing the port number does not provide meaningful security by itself. Nonstandard ports can reduce casual scanning noise, but they do not replace authentication, authorization, patching, or JIT.

Review existing NSG and firewall rules

Permanent allow rules can undermine the intended JIT protection. Review:

NSG inbound rules
Azure Firewall rules
Load balancer rules
Public IP exposure
Routing and network virtual appliance rules

Requesting JIT Access

After JIT is enabled, a user must request access before connecting to the VM.

Request process

Open the Just-in-time VM access page.
Select the Configured tab.
Select the target VM.
Select Request access.
Choose the required port or ports.
Specify the source IP address or range.
Specify the requested access duration.
Select Open ports.

The request is evaluated against the user’s permissions and the VM’s JIT policy.

After the request is approved, the user connects using the normal RDP, SSH, or other supported management method.

Requesting access from the VM Connect page

A user can also:

Open the VM in the Azure portal.
Select Connect.
If JIT is enabled, select Request access.
Specify the required access parameters.
Open the ports.
Connect to the VM.

For VMs protected by Azure Firewall, Defender for Cloud may provide the appropriate connection details, including the relevant port mapping.

Does JIT Automatically Approve Every Request?

JIT is not necessarily an approval workflow in the same sense as a formal access-request system.

The user must have the required Azure permissions, and the request must comply with the JIT policy. Depending on the configuration and permissions, an authorized user may be able to open the permitted ports without a separate human approval step.

Organizations requiring managerial or security approval should combine JIT with additional controls, such as:

Privileged Identity Management
Access reviews
Service management approval workflows
Conditional Access
Privileged access workstations
Ticketing and change-management processes

JIT controls temporary network exposure. It does not independently provide a complete privileged-access approval process.

Permissions for JIT Access

Different activities require different permissions.

Viewing JIT information

A user needs appropriate read permissions to view JIT policies and status.

Configuring or editing a JIT policy

A user needs permissions to modify the JIT network access policy and, in some cases, the VM configuration.

Requesting access

A user needs permissions to initiate a JIT access request and read the relevant VM and network configuration.

The principle of least privilege should be applied. A user who only needs to request access should not automatically receive permissions to modify JIT policies or change VM settings.

Enforcing JIT with Azure Policy

Enabling JIT manually on individual VMs does not scale well in a large environment.

Azure Policy can be used to identify VMs that do not comply with the organization’s JIT requirements.

Typical governance approach

Define the organization’s JIT requirement.
Assign an Azure Policy at the subscription or management-group scope.
Evaluate VMs for compliance.
Identify noncompliant VMs.
Remediate or configure JIT where appropriate.
Monitor compliance continuously.

The policy may be used to audit whether JIT is enabled or to support an organizational requirement that eligible VMs use JIT.

Why policy enforcement matters

Without centralized governance, administrators may:

Deploy a VM with RDP permanently exposed.
Forget to enable JIT.
Add a new management port without protecting it.
Modify network rules after JIT is configured.
Create inconsistent security configurations across subscriptions.

Azure Policy provides a repeatable method for identifying and managing these deviations.

JIT and Azure Bastion

JIT and Azure Bastion address related but different security concerns.

Capability	JIT VM access	Azure Bastion
Primary purpose	Temporarily opens selected management ports	Provides managed RDP/SSH connectivity
VM public IP required	May be required depending on network design	Normally not required
Browser-based connection	Not the primary feature	Yes
Temporary port access	Yes	Not the primary feature
Works with existing RDP/SSH clients	Yes	Supported with appropriate Bastion SKU
Reduces permanently exposed management ports	Yes	Yes, by avoiding public VM management exposure
Main control	Time-bound network access	Managed secure connectivity

A strong design may use both:

Azure Bastion to provide private administrative connectivity.
JIT to restrict management ports when direct network access is required.

JIT and Just-in-Time Privileged Identity Management

JIT VM access should not be confused with Microsoft Entra Privileged Identity Management.

JIT VM access

Controls temporary network access to VM ports.

Privileged Identity Management

Controls temporary privileged role activation.

For example:

PIM may temporarily activate the Virtual Machine Administrator Login role.
JIT may temporarily open port 3389 from the administrator’s IP address.

Using both controls provides stronger defense in depth because the user must have both:

The appropriate identity and role permissions.
Temporary network connectivity.

JIT and Network Security Groups

JIT does not eliminate the need for NSGs.

NSGs still provide:

Subnet-level filtering
NIC-level filtering
Inbound and outbound traffic control
Application-specific network segmentation
Persistent baseline security rules

JIT adds temporary management-port control on top of the existing network security design.

Example

An NSG might permanently allow application traffic:

TCP 443 from the internet to a web server

But administrative traffic could be controlled through JIT:

TCP 3389 closed by default
TCP 3389 opened only for an administrator’s IP
TCP 3389 automatically restricted after the approved period

JIT and Azure Firewall

JIT can work with supported Azure Firewall configurations.

When Azure Firewall protects a VM, JIT can temporarily modify the relevant firewall access configuration. After the access window expires, the previous restrictive configuration is restored.

Important considerations include:

Azure Firewall must use a supported configuration.
Azure Firewall Manager-controlled firewall configurations are not supported for JIT.
Firewall rules must be reviewed for conflicts.
The user may receive a translated or mapped port when connecting through the firewall.

Auditing JIT Activity

JIT activity should be reviewed regularly.

Useful information includes:

VM name
User who requested access
Request time
Requested port
Source IP address
Access duration
Whether access was granted
Last access time
Number of approved requests

This information can help identify:

Unexpected administrative activity
Excessively long access requests
Repeated requests from unusual IP addresses
VMs that are accessed more frequently than expected
Potential misuse of administrative access

JIT activity should be correlated with other security data, including:

Microsoft Entra sign-in logs
Azure Activity Log
NSG flow logs where available
Microsoft Defender for Cloud alerts
Microsoft Sentinel incidents
Privileged Identity Management activation records

Common JIT Troubleshooting Scenarios

The VM does not appear as eligible

Possible causes include:

Defender for Servers Plan 2 is not enabled.
The VM uses an unsupported deployment model.
The VM lacks a supported NSG or firewall configuration.
JIT is disabled by a security policy.
The VM is protected by an unsupported Azure Firewall configuration.

The user cannot request access

Check:

Azure RBAC permissions
VM read permissions
JIT request permissions
Subscription and resource-group scope
Whether the VM is configured for JIT
Whether the requested port is included in the policy

The user requested access but cannot connect

Check:

The request was successfully opened.
The correct source IP was specified.
The user is connecting from the same IP address used in the request.
The correct port and protocol are being used.
The VM is running.
The guest operating system firewall allows the traffic.
The NSG or Azure Firewall does not contain conflicting rules.
The VM service is listening on the expected port.
Routing and DNS are functioning correctly.

Access remains available after the expected expiration

Remember that JIT controls network rules. An already established connection may not be interrupted when the access window expires. The expiration prevents new access rather than necessarily terminating an existing session.

A permanent allow rule defeats JIT

Review NSG and firewall priorities. A broad allow rule with a higher priority may continue to permit traffic even when JIT has created a restrictive rule.

Best Practices Summary

Enable Defender for Servers Plan 2 for subscriptions containing eligible VMs.
Enable JIT on all supported administrative VMs.
Protect only required management ports.
Restrict source IP addresses whenever possible.
Use the shortest practical access duration.
Review NSG and Azure Firewall rules for conflicts.
Combine JIT with Azure Bastion where appropriate.
Combine JIT with PIM for privileged role activation.
Use Azure Policy to identify noncompliant VMs.
Audit JIT requests and correlate them with identity and security logs.
Do not treat changing an SSH or RDP port as a substitute for JIT.
Remember that JIT does not replace patching, endpoint protection, strong authentication, or least-privilege RBAC.

Key Exam Takeaways

For the SC-500 exam, remember the following:

JIT VM access is provided through Microsoft Defender for Cloud.
Microsoft Defender for Servers Plan 2 is a prerequisite for Azure VM JIT access.
JIT reduces exposure by restricting inbound management ports.
Access is requested for a specific port, source IP address, and time window.
Common ports include 22, 3389, 5985, and 5986.
JIT policies can include custom ports.
JIT works with supported NSG and Azure Firewall configurations.
Existing higher-priority allow rules can undermine JIT protection.
JIT can be enabled and managed through the Azure portal, PowerShell, or REST API.
Azure Policy can be used to enforce or audit JIT adoption.
JIT controls temporary network access; it does not replace RBAC, PIM, Bastion, or authentication.
Expiration of a JIT window does not necessarily terminate an already established connection.

Practice Exam Questions

Question 1

An organization has several Azure Windows VMs with RDP port 3389 permanently open to the internet. Security administrators want to allow RDP only when an administrator needs access and only for a limited period.

Which solution should they implement?

A. Just-in-time VM access in Microsoft Defender for Cloud
B. Azure Resource Lock
C. Azure Storage firewall rules
D. Microsoft Defender for Storage

Answer: A

Explanation: JIT VM access restricts inbound management ports and temporarily opens them only when access is requested. Resource locks protect resources from deletion or modification, while Storage firewall rules and Defender for Storage do not control RDP access to VMs.

Question 2

What is required before enabling just-in-time access for Azure virtual machines through Microsoft Defender for Cloud?

A. Microsoft Defender for Containers
B. Microsoft Defender for Servers Plan 2
C. Azure Kubernetes Service
D. Microsoft Sentinel automation rules

Answer: B

Explanation: Microsoft Defender for Servers Plan 2 must be enabled on the subscription for Azure VM JIT access.

Question 3

A Linux administrator needs SSH access to a VM for 45 minutes from a corporate public IP address. The JIT policy protects SSH port 22 and allows a maximum request duration of two hours.

Which information should the administrator provide when requesting access?

A. The VM’s operating-system password only
B. The VM’s resource lock and subscription ID
C. Port 22, the corporate source IP address, and a duration of 45 minutes
D. The Azure Storage account and container name

Answer: C

Explanation: A JIT request specifies the port, source IP address or range, and requested access duration. Authentication to the VM is still required separately.

Question 4

An organization wants to ensure that all eligible Azure VMs use JIT access. Administrators should be able to identify VMs that do not comply with the requirement.

Which service should be used?

A. Azure Policy
B. Azure DNS
C. Azure Load Balancer
D. Azure Front Door

Answer: A

Explanation: Azure Policy can audit or enforce organizational requirements and identify VMs that do not comply with JIT-related governance requirements.

Question 5

A VM has JIT enabled for RDP. However, users can still connect to port 3389 even when no JIT request is active.

What should the administrator investigate first?

A. Whether the VM has a managed identity
B. Whether the VM uses a Premium SSD
C. Whether the VM has a resource lock
D. Whether another higher-priority NSG or firewall rule permanently allows RDP

Answer: D

Explanation: Existing higher-priority allow rules can take precedence over JIT-generated restrictions. NSG and Azure Firewall rules should be reviewed for conflicting permanent access.

Question 6

Which statement best describes the relationship between JIT VM access and Azure Bastion?

A. JIT replaces the need for Azure RBAC
B. Azure Bastion is required for every JIT request
C. JIT controls temporary network access, while Bastion provides managed RDP/SSH connectivity
D. Azure Bastion permanently opens RDP and SSH ports on the VM

Answer: C

Explanation: JIT and Bastion provide different controls. JIT manages temporary access to management ports, while Bastion provides secure managed connectivity without requiring a public IP on the target VM in the normal design.

Question 7

A security engineer wants administrators to request JIT access only from approved corporate IP addresses rather than from any internet address.

Which JIT setting should be configured?

A. Allowed source IP addresses
B. VM disk encryption type
C. Azure resource lock level
D. Guest operating system image version

Answer: A

Explanation: The JIT policy allows administrators to define permitted source IP addresses or ranges for each protected port.

Question 8

A user requests JIT access to a VM protected by a supported Azure Firewall configuration. After the request is approved, Defender for Cloud provides a port mapping that differs from the VM’s internal RDP port.

Why might this occur?

A. JIT has changed the VM’s operating system
B. Azure Firewall may use a DNAT port mapping for the connection
C. The VM has been converted into an App Service
D. The VM’s managed identity has expired

Answer: B

Explanation: When Azure Firewall protects the VM, the user may need to connect using the connection details and port mapping associated with the firewall’s DNAT configuration.

Question 9

An administrator requests JIT access for 30 minutes and establishes an SSH session. The 30-minute window expires, but the existing SSH session remains connected.

Is this behavior consistent with JIT?

A. Yes. JIT expiration restricts new access but does not necessarily terminate established connections
B. No. JIT must always forcibly terminate every active session
C. No. JIT only controls outbound traffic
D. Yes, but only when the VM uses Azure Bastion

Answer: A

Explanation: JIT expiration restores the restrictive network configuration. Existing connections may remain active, so organizations should use session controls and operational procedures when immediate termination is required.

Question 10

Which approach provides the strongest defense-in-depth design for administrative access to sensitive Azure VMs?

A. Change the RDP port and leave it permanently open
B. Use JIT alone and disable all identity controls
C. Use JIT, least-privilege RBAC, strong authentication, and Azure Bastion or another secure connectivity method where appropriate
D. Use a resource lock to protect the VM from network attacks

Answer: C

Explanation: JIT should be combined with identity, authorization, authentication, network, and endpoint security controls. Changing ports does not eliminate exposure, and resource locks do not protect network access.

Go to the SC-500 Exam Prep Hub main page

Cloud computing, Cybersecurity, Microsoft Certification, SC-500, security October 10, 2026

Exam Prep Hub for SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads

Welcome to the SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads Exam Prep Hub!

Welcome to the one-stop hub with information for preparing for the SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads certification exam. The content for this exam helps prepare you to be “a security engineer who protects organizational systems and data across cloud and hybrid environments by implementing comprehensive security controls that proactively help prevent unauthorized access and mitigate risks. Your role spans multiple security domains, including identity, network, application, data, and compute. You also help ensure that platforms, data, identities, and infrastructure used by AI workloads are securely implemented and monitored.”.
Upon successful completion of the exam, you earn the Microsoft Certified: Cloud and AI Security Engineer Associate certification.

This hub provides information directly here (topic-by-topic as outlined in the official study guide), links to a number of external resources, tips for preparing for the exam, practice tests, and section questions to help you prepare. Bookmark this page and use it as a guide to ensure that you are fully covering all relevant topics for the SC-500 exam and making use of as many of the resources available as possible.

**Audience profile (from Microsoft’s site)**

As a candidate for this Microsoft Certification, you’re a security engineer who protects organizational systems and data across cloud and hybrid environments by implementing comprehensive security controls that proactively help prevent unauthorized access and mitigate risks. Your role spans multiple security domains, including identity, network, application, data, and compute. You also help ensure that platforms, data, identities, and infrastructure used by AI workloads are securely implemented and monitored.

In this role, your responsibilities include:
- Securing access to resources by using Microsoft Entra ID and Azure Key Vault.
- Enforcing security and regulatory compliance.
- Securing storage, databases, and networking.
- Securing compute.
- Securing AI solutions.
- Managing and monitoring security posture.

You work closely with architects, administrators, engineers, analysts, and developers responsible for Azure, Microsoft 365, identity and access, information protection, security operations, DevOps, application development, database platforms, and networks.

For this exam, you should have practical experience in administration of Azure and hybrid environments, including compute, network, and storage. You need strong familiarity with Microsoft Entra ID and familiarity with Microsoft 365 administration.

Skills at a glance

Manage identity, access, and governance (20–25%)
Secure storage, databases, and networking (25–30%)
Secure compute (20–25%)
Manage and monitor security posture (20–25%)

Topic-by-Topic Exam Content

[click a topic link to access the content and practice questions for that topic]

Manage identity, access, and governance (20–25%)

Secure access to resources by using Microsoft Entra ID

Secure secrets and keys by using Azure Key Vault

Implement governance to enforce security and regulatory compliance

Secure storage, databases, and networking (25–30%)

Implement security for storage accounts

Implement security for databases

Implement security for Azure network services

Secure compute (20–25%)

Implement security for AI

Implement security for servers and virtual machines (VMs)

Implement security for application platform services

Manage and monitor security posture (20–25%)

Manage security posture by using Defender for Cloud

Implement activity and event collection in Microsoft Sentinel

Implement Microsoft Security Copilot

SC-500 Practice Exams

SC-500 Practice Exam #1 (30 questions)

SC-500 Practice Exam #2 (30 questions)

SC-500 Practice Exam #3 (30 questions)

SC-500 Practice Exam #4 (30 questions)

Important SC-500 Resources

Link to the free, comprehensive, self-paced course on Microsoft Learn:

Implement end‑to‑end security controls for cloud and AI workloads

This course has 12 learning paths.

Link to the certification page:

Link to the “Microsoft Certified: Cloud and AI Security Engineer Associate” certification page.

Link to the study guide:

Link to the Study Guide for SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads.

A few highly rated SC-500 related courses on Udemy:

YouTube Video Series

Good luck to you passing the SC-500 Exam!
However, the more preparation you have, the less luck you will need. 🙂

Visit this post to see the list of all the certification preparation hubs available on The Data Community.

AI-200, azure, Azure AI, Cloud computing, Microsoft Certification August 15, 2026

Exam Prep Hub for AI-200: Developing AI Cloud Solutions on Azure

Welcome to the AI-200: Developing AI Cloud Solutions on Azure Exam Prep Hub!

Welcome to the one-stop hub with information for preparing for the AI-200: Developing AI Cloud Solutions on Azure certification exam. The content for this exam helps prepare you to be “responsible for contributing to all phases of implementing AI solutions on Azure, with an emphasis on back-end services and components. You’re also responsible for supporting all phases of the development lifecycle, including requirements gathering, design, development, deployment, security, and monitoring”.
Upon successful completion of the exam, you earn the Microsoft Certified: Azure AI Cloud Developer Associate certification.

This hub provides information directly here (topic-by-topic as outlined in the official study guide), links to a number of external resources, tips for preparing for the exam, practice tests, and section questions to help you prepare. Bookmark this page and use it as a guide to ensure that you are fully covering all relevant topics for the AI-200 exam and making use of as many of the resources available as possible.

Audience Profile (from Microsoft’s site)

As a candidate for this Microsoft Certification, you’re responsible for contributing to all phases of implementing AI solutions on Azure, with an emphasis on back-end services and components. You’re also responsible for supporting all phases of the development lifecycle, including requirements gathering, design, development, deployment, security, and monitoring.

You should be proficient in:
- Azure SDKs and third-party SDKs used in Azure.
- Azure data management services.
- Azure monitoring and troubleshooting.
- Azure messaging and eventing.
- Vector databases.
- Python programming.
- Implementing containerized applications on Azure.

Skills at a glance (as specified in the official study guide)

Develop containerized solutions on Azure (20–25%)
Develop AI solutions by using Azure data management services (25–30%)
Connect to and consume Azure services (20–25%)
Secure, monitor, troubleshoot Azure solutions (20–25%)

Topic-by-Topic Exam Content

[click a topic link to access the content and practice questions for that topic]

Develop containerized solutions on Azure (20–25%)

Implement container application hosting

Implement container-orchestrated solutions

Develop AI solutions by using Azure data management services (25–30%)

Develop AI solutions by using Azure Cosmos DB for NoSQL

Develop AI solutions by using Azure Database for PostgreSQL

Integrate Azure Managed Redis in AI solutions

Connect to and consume Azure services (20–25%)

Develop event- and message-based AI solutions

Develop and implement Azure Functions

Secure, monitor, and troubleshoot Azure solutions (20–25%)

Implement secure Azure solutions

Monitor and troubleshoot Azure solutions

AI-200 Practice Exams

AI-200 Practice Exam #1 (30 questions)

AI-200 Practice Exam #2 (30 questions)

AI-200 Practice Exam #3 (30 questions)

AI-200 Practice Exam #4 (30 questions)

Important AI-200 Resources

Link to the free, comprehensive, self-paced course on Microsoft Learn:

Develop AI cloud solutions on Azure

This course has 9 learning paths:

Good luck to you passing the AI-200 Exam!
However, the more preparation you have, the less luck you will need. 🙂

Visit this post to see the list of all the certification preparation hubs available on The Data Community.

AI-200, azure, Azure AI, Cloud computing, Microsoft Certification August 15, 2026

Queue and process back-end operations by using Azure Service Bus, including dead-letter queue handling, messages, topics, and subscriptions (AI-200 Exam Prep)

This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Connect to and consume Azure services (20–25%)
   --> Develop event- and message-based AI solutions
      --> Queue and process back-end operations by using Azure Service Bus, including dead-letter queue handling, messages, topics, and subscriptions

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

AI applications frequently perform operations that should not block a user’s request. Examples include processing documents, generating embeddings, running batch inference, sending notifications, executing long-running model operations, or enriching data.

Azure Service Bus provides reliable asynchronous messaging that allows application components to communicate without requiring them to be available or execute at the same time.

For the AI-200 exam, you should understand how to:

Use Service Bus queues for asynchronous point-to-point processing.
Use topics and subscriptions for publish/subscribe scenarios.
Design messages for AI workloads.
Process messages reliably.
Understand message settlement.
Use peek-lock processing.
Handle retries and poison messages.
Work with dead-letter queues (DLQs).
Understand message locks and delivery counts.
Choose between queues and topics based on application requirements.

The key architectural idea is decoupling.

Instead of:

AI application → immediately execute expensive operation

you can use:

AI application → Service Bus → worker → AI operation

This allows the producer and consumer to scale independently and protects downstream AI services from sudden workload spikes.

1. What Is Azure Service Bus?

Azure Service Bus is a fully managed enterprise message broker designed for reliable asynchronous communication between distributed applications.

A typical architecture might look like:

			
Client
   |
   v
AI API
   |
   v
Service Bus Queue
   |
   +------------------+
   |                  |
   v                  v
Worker 1            Worker 2
   |                  |
   +--------+---------+
            |
            v
       AI Service

		

The API does not have to wait for the worker to finish.

Instead, it places a message onto the queue and can return a response indicating that the operation has been accepted.

The worker processes the message later.

This provides several important architectural benefits.

Temporal decoupling

The producer and consumer do not have to be running simultaneously.

A producer can place a message into the queue even when the consumer is temporarily unavailable.

Load leveling

Suppose an application normally receives 100 AI requests per minute but occasionally receives 5,000 requests per minute.

Rather than requiring the AI processing infrastructure to immediately handle all 5,000 requests, the application can place requests into a queue.

Workers can process the backlog at a sustainable rate.

			
Incoming requests
       |
       v
+----------------+
| Service Bus    |
| Queue          |
+----------------+
       |
       v
+----------------+
| AI Workers     |
| 1  2  3  4 ... |
+----------------+

		

The queue acts as a buffer between the workload producer and the processing infrastructure.

Competing consumers

Multiple worker instances can consume messages from the same queue.

For example:

             +--> Worker 1
             |
Service Bus -+--> Worker 2
   Queue     |
             +--> Worker 3
             |
             +--> Worker 4

Each message is normally processed by only one competing consumer.

This allows the processing tier to scale horizontally.

2. Azure Service Bus Messaging Entities

The three primary messaging entities you need to understand are:

Queues
Topics
Subscriptions

The most important distinction is:

Entity	Communication pattern	Typical use
Queue	Point-to-point	Work distribution
Topic	Publish/subscribe	Broadcasting events
Subscription	Receiver attached to a topic	Independent consumers

3. Service Bus Queues

A queue is appropriate when a message represents a unit of work that should generally be processed by one consumer.

For example:

			
AI API
  |
  | Submit document-processing request
  v
Service Bus Queue
  |
  +---- Worker A
  |
  +---- Worker B
  |
  +---- Worker C

		

Although multiple workers can listen to the same queue, a particular message is delivered to one competing consumer for processing.

Example

Suppose an application accepts uploaded documents and needs to:

Extract text.
Generate embeddings.
Store vectors.
Update a search index.

The web application could put this message onto a queue:

			
{
  "operation": "process-document",
  "documentId": "12345",
  "blobUrl": "https://storage/.../document.pdf",
  "model": "embedding-model",
  "correlationId": "abc-123"
}

		

A worker receives the message and performs the processing.

This is preferable to making the user’s HTTP request wait for the entire AI pipeline.

4. Topics and Subscriptions

Queues are primarily for point-to-point processing.

Topics and subscriptions are designed for publish/subscribe scenarios.

A topic can have multiple subscriptions:

                 +--> Subscription A --> Consumer A
                 |
Publisher --> Topic
                 |
                 +--> Subscription B --> Consumer B
                 |
                 +--> Subscription C --> Consumer C

Each subscription can receive its own copy of a published message.

Example AI architecture

Imagine that a document is uploaded.

Several independent operations need to happen:

Generate embeddings.
Perform compliance analysis.
Extract metadata.
Notify an audit system.

A topic could be used:

                  +--> Embedding subscription
                  |
Document Event --> Topic
                  |
                  +--> Compliance subscription
                  |
                  +--> Metadata subscription
                  |
                  +--> Audit subscription

This is a classic fan-out architecture.

5. Queues vs. Topics

A common AI-200 exam scenario asks you to choose between a queue and a topic.

Use a queue when:

One processing path should handle each work item.

Use a topic with subscriptions when:

Multiple independent processing paths need to receive the event.

Example

Scenario A:

A document-processing request must be handled by one available worker.

Use: Queue.

Scenario B:

A document-created event must be independently consumed by the search, auditing, analytics, and notification systems.

Use: Topic with subscriptions.

6. Subscription Filters

Subscriptions can use rules and filters to determine which messages are delivered to a particular subscription.

For example, a topic might receive:

			
{
  "eventType": "DocumentUploaded",
  "department": "Finance"
}

A subscription could filter messages so that only Finance documents are delivered.

This allows a single topic to support multiple specialized consumers without requiring every consumer to receive every message.

This is particularly useful in event-driven AI architectures.

7. Designing Service Bus Messages for AI Workloads

A Service Bus message should generally contain the information necessary for a consumer to locate and process the work.

A useful AI message might contain:

			
{
  "operation": "generate-summary",
  "documentId": "98431",
  "storageUri": "https://storage.example/document.pdf",
  "model": "summary-model",
  "priority": "normal",
  "correlationId": "req-982734"
}

		

Important concepts include:

Message body

Contains the primary payload.

For AI applications, this might be JSON containing:

Operation name
Entity ID
Storage location
Model information
Processing parameters

Application properties

Application properties can contain metadata used for routing, correlation, filtering, or processing decisions.

Examples include:

eventType
tenantId
priority
correlationId
contentType

Message ID

A producer can assign a unique message ID.

This can be useful for duplicate detection and application-level idempotency.

Correlation ID

A correlation ID allows related operations to be tracked across distributed components.

For example:

			
HTTP request
    |
    | correlationId = ABC123
    v
Service Bus
    |
    v
AI worker
    |
    v
Azure AI service

		

Logging the same correlation ID throughout the workflow makes troubleshooting considerably easier.

8. Avoid Putting Large AI Payloads Directly in Messages

AI workloads can involve large documents, images, audio files, or other payloads.

Instead of putting a large file directly into the Service Bus message, a common architecture is the claim-check pattern.

The large payload is stored separately, such as in Azure Blob Storage.

The Service Bus message contains a reference:

			
{
  "documentId": "12345",
  "blobUri": "https://storage.example/document.pdf",
  "operation": "extract-text"
}

		

The consumer retrieves the payload from storage.

This keeps messages smaller and allows the messaging layer to focus on coordinating work rather than transporting large files.

9. Message Processing Modes

Service Bus provides different approaches for receiving messages.

The two important concepts for the AI-200 exam are:

Peek-lock
Receive-and-delete

10. Peek-Lock Mode

Peek-lock is generally the preferred mode when losing a message is unacceptable.

The processing model is approximately:

			
Receive message
      |
      v
Message is locked
      |
      v
Process message
      |
      v
Complete message

		

When the consumer receives a message in peek-lock mode, the message is temporarily locked so another consumer cannot simultaneously process it.

After successful processing, the consumer explicitly completes the message.

11. Message Settlement

When using peek-lock, the consumer must settle the message.

Important settlement operations include:

Complete

The operation succeeded.

The message is removed from the queue or subscription.

			
Process successfully
       |
       v
    Complete
       |
       v
Message removed

		

Abandon

The consumer cannot successfully process the message and wants it made available again.

			
Processing failure
       |
       v
    Abandon
       |
       v
Message becomes available again

		

Dead-letter

The message is considered unsuitable for normal processing and is moved to the dead-letter queue.

This is useful for poison messages or messages that cannot be successfully processed after repeated attempts.

Defer

The consumer can defer a message when processing cannot currently continue but the application wants to retrieve it later using its sequence number.

12. Why Peek-Lock Is Important

Consider this sequence:

			
Worker receives message.
Worker starts AI processing.
Worker crashes.
Message was never completed.

Because the message wasn’t completed, Service Bus can make it available again after the lock expires.

This provides an at-least-once processing behavior.

The important consequence is:

A message can potentially be processed more than once.

Therefore, AI workers should ideally be designed to be idempotent.

For example, before inserting an embedding, the application could check whether that document/version has already been processed.

13. Receive-and-Delete

In receive-and-delete mode, the message is removed as soon as it is received.

			
Receive
   |
   v
Message deleted
   |
   v
Process

		

This can provide simpler and potentially higher-throughput processing, but it introduces a major risk.

If the worker crashes after receiving the message but before completing the work, the message is already gone.

Therefore:

Use peek-lock when message loss is unacceptable.

Use receive-and-delete only when occasional message loss is acceptable.

14. Message Locks

When a message is received using peek-lock, it is temporarily locked.

The lock prevents another receiver from processing the same message simultaneously.

However, the lock has a limited duration.

If processing takes too long, the application can renew the lock where supported.

For long-running AI operations, this is important.

For example:

			
Receive
  |
  v
Lock acquired
  |
  +---- Process AI request
  |
  +---- Renew lock
  |
  +---- Renew lock
  |
  v
Complete

		

If the lock expires before the message is completed, the message can become available again.

This can result in duplicate processing.

15. Dead-Letter Queues

A dead-letter queue (DLQ) is a secondary subqueue associated with a Service Bus queue or topic subscription.

It stores messages that cannot be successfully processed or delivered.

Common causes include:

Exceeding the maximum delivery count.
Message expiration when dead-lettering on expiration is enabled.
Explicit application dead-lettering.
Certain forwarding or routing failures.
Invalid processing conditions.

The DLQ is therefore an important mechanism for handling poison messages.

16. What Is a Poison Message?

A poison message is a message that repeatedly fails processing.

For example:

			
Message received
      |
      v
AI worker fails
      |
      v
Message retried
      |
      v
AI worker fails
      |
      v
Message retried
      |
      v
...
      |
      v
Dead-letter queue

		

Without a DLQ, the same bad message could continuously consume processing capacity.

17. Maximum Delivery Count

Service Bus queues and topic subscriptions have a maximum delivery count.

The default value is commonly 10.

When a message is repeatedly delivered under peek-lock and the processing attempt fails—for example, because the message is abandoned or its lock expires—the delivery count increases.

Once the configured maximum is exceeded, Service Bus moves the message to the DLQ.

The important exam concept is:

Increasing the maximum delivery count does not fix a poison message. It only allows more failed delivery attempts before dead-lettering.

The appropriate value depends on the workload.

18. Handling the Dead-Letter Queue

A DLQ should not simply become a place where failed messages are forgotten.

A production application should monitor it.

A typical operational workflow is:

             Normal Queue
                  |
                  v
             AI Worker
                  |
             Processing
             /         \
          Success      Failure
             |           |
             v           v
          Complete      Retry
                         |
                         v
                    Max attempts
                         |
                         v
                       DLQ
                         |
                         v
                 Investigate
                         |
              +----------+----------+
              |                     |
           Correct                Reject
              |                     |
              v                     v
          Reprocess              Discard

The application or operations team can inspect DLQ messages, determine why processing failed, correct the underlying problem, and potentially resubmit appropriate messages.

Dead-lettered messages include dead-letter reason information that can help diagnose the failure.

19. Explicit Dead-Lettering

An application can explicitly dead-letter a message.

This is appropriate when the application determines that retrying will not solve the problem.

For example:

			
Message:
customerId = 123
operation = generate-report
format = "INVALID_FORMAT"

If the application knows that the message is permanently invalid, repeatedly retrying it is wasteful.

The worker can dead-letter the message instead.

This is different from a transient error such as:

AI service temporarily unavailable

A transient failure may justify retrying.

A permanently invalid message generally should not.

20. Retry vs. Dead-Letter

A useful exam distinction is:

Situation	Appropriate response
Temporary network failure	Retry
Temporary AI service throttling	Retry
Worker temporarily unavailable	Retry
Invalid message structure	Potentially dead-letter
Unsupported operation	Potentially dead-letter
Poison message	Dead-letter after appropriate retries
Processing repeatedly fails	Dead-letter
Successful processing	Complete

The key is distinguishing transient failures from permanent failures.

21. Time to Live (TTL)

Messages can have a time-to-live (TTL).

TTL determines how long a message is considered valid.

For example:

			
Message created
      |
      |---------------- TTL ----------------|
      |                                      |
      v                                      v
   Valid                                 Expired

		

An expired message should generally no longer be processed.

If dead-lettering on message expiration is enabled for the entity, expired messages can be moved to the DLQ.

This can be useful when stale AI requests are no longer useful.

For example, an AI recommendation request that is several hours old may no longer have business value.

22. Idempotent AI Processing

At-least-once delivery means that duplicate processing is possible.

Consider:

			
Worker receives message
      |
      v
Generate embedding
      |
      v
Store embedding
      |
      X
Worker crashes before Complete

		

The message may be delivered again.

The worker might generate and store the embedding again.

A robust application should therefore make important operations idempotent.

One strategy is to use a deterministic identifier:

documentId + documentVersion

The worker can check whether that specific version has already been processed.

Another approach is to use Service Bus duplicate-detection capabilities where appropriate, combined with application-level safeguards.

Do not assume that messaging infrastructure alone eliminates every duplicate-processing scenario.

23. Sessions and Ordered Processing

Some applications require related messages to be processed in order.

Service Bus supports sessions for this purpose.

A session groups related messages using a session identifier.

For example:

			
Session: Customer-1001
Message 1
Message 2
Message 3
Message 4

		

A session-enabled consumer can process the messages associated with the session as an ordered sequence.

Sessions are useful when an AI workflow contains stateful or order-dependent operations.

For example:

			
Document uploaded
       |
       v
Text extracted
       |
       v
Embedding generated
       |
       v
Index updated

		

If later operations depend on earlier ones, ordering can become important.

24. Service Bus in an AI Architecture

A common AI architecture might look like:

                +----------------+
                | Client         |
                +-------+--------+
                        |
                        v
                +----------------+
                | AI API         |
                +-------+--------+
                        |
                        v
                +----------------+
                | Service Bus    |
                | Queue          |
                +-------+--------+
                        |
             +----------+----------+
             |          |          |
             v          v          v
          Worker 1   Worker 2   Worker 3
             |          |          |
             +----------+----------+
                        |
                        v
                +----------------+
                | Azure AI       |
                | Services       |
                +----------------+

This design provides:

Asynchronous processing.
Load leveling.
Horizontal scalability.
Failure isolation.
Retry capabilities.
Durable message storage.
Better control of downstream AI workloads.

25. Service Bus Topics in AI Event Architectures

Topics are especially useful when one AI event needs to trigger multiple independent workflows.

For example:

                    +--> Embedding pipeline
                    |
DocumentUploaded -->+--> Classification pipeline
                    |
                    +--> Audit pipeline
                    |
                    +--> Notification pipeline

Each pipeline can have its own subscription.

This avoids tightly coupling the document-uploading application to every downstream service.

26. Monitoring Service Bus Workloads

Operational monitoring is important because messaging problems can be difficult to see from the front-end application alone.

Useful indicators include:

Active message count.
Dead-letter message count.
Message processing failures.
Message age.
Processing latency.
Receiver throughput.
Queue backlog.
Delivery counts.

A growing active-message count can indicate that producers are generating messages faster than consumers can process them.

A growing DLQ count can indicate a processing or data-quality problem.

For AI workloads, also monitor downstream dependencies such as model-service throttling and latency.

27. Common AI-200 Exam Traps

Trap 1: Choosing a topic when only one worker should process each message

Use a queue for a competing-consumer workload.

Trap 2: Choosing a queue when multiple independent consumers need every event

Use a topic with subscriptions.

Trap 3: Assuming peek-lock means exactly-once processing

Peek-lock supports reliable processing, but duplicate processing can still occur.

Design consumers to be idempotent.

Trap 4: Using receive-and-delete for critical workloads

The message is removed before processing completes.

If the worker fails, the message can be lost.

Trap 5: Treating the DLQ as a retry queue

A DLQ is primarily a place to isolate messages that cannot be successfully processed or delivered.

Investigate the cause before reprocessing them.

Trap 6: Increasing MaxDeliveryCount to solve permanent failures

If the message itself is invalid, more retries simply waste resources.

Trap 7: Putting large documents directly into Service Bus messages

Consider storing large payloads in Blob Storage and placing a reference in the message.

Trap 8: Forgetting duplicate processing

At-least-once processing means consumers should tolerate duplicates.

28. Quick Decision Guide

Use this mental model for the exam:

			
Need asynchronous processing?
            |
            v
       Azure Service Bus
            |
      +-----+------+
      |            |
   One path      Many paths
      |            |
      v            v
    Queue        Topic
                   |
                   v
             Subscriptions

		

For message processing:

			
Critical message?
      |
      +---- Yes ---> Peek-lock
      |
      +---- No ----> Receive-and-delete may be acceptable

		

For processing failures:

			
Failure
  |
  +--> Temporary? ----> Retry
  |
  +--> Permanent? ----> Dead-letter
  |
  +--> Repeated failure? ----> DLQ

		

For large AI payloads:

			
Large file
    |
    v
Blob Storage
    |
    v
Service Bus message
(reference + metadata)

		

29. Key Takeaways

For AI-200, remember these concepts:

Queues provide point-to-point messaging and competing-consumer processing.
Topics provide publish/subscribe messaging.
Subscriptions allow independent consumers to receive copies of topic messages.
Peek-lock is appropriate when message loss is unacceptable.
Receive-and-delete removes a message before processing completes and can result in message loss.
Complete removes a successfully processed message.
Abandon makes a message available for another delivery attempt.
Dead-letter moves a message into the DLQ for isolation and investigation.
At-least-once processing means duplicate processing is possible.
AI workers should be designed to be idempotent where duplicate execution is possible.
Maximum delivery count controls how many delivery attempts occur before dead-lettering.
TTL controls message lifetime.
Topics are ideal for fan-out scenarios.
Subscription filters can selectively route messages.
Correlation IDs are valuable for distributed tracing and troubleshooting.
Large payloads should generally be stored externally, with a reference in the Service Bus message.
Sessions can be used when ordered, stateful message processing is required.
A growing DLQ is an operational signal that requires investigation.
A growing active-message backlog can indicate insufficient consumer capacity.
Service Bus is particularly valuable in AI architectures because it decouples request ingestion from potentially expensive or long-running AI processing.

Practice Exam Questions

Question 1

An AI application receives document-processing requests through an HTTP API. Each request should be processed by exactly one available worker. Multiple worker instances must be able to process requests concurrently.

Which Azure Service Bus entity should you use?

A. Queue

B. Topic with one subscription

C. Topic with multiple subscriptions

D. Event Grid topic

Answer: A. Queue

Explanation

A Service Bus queue is designed for point-to-point communication and competing consumers. Multiple workers can receive messages from the same queue while each message is processed by one consumer.

A topic is more appropriate when the same event needs to be delivered independently to multiple subscribers. Event Grid is primarily designed for event notification and event-driven architectures rather than work-queue semantics.

Question 2

An AI application publishes a DocumentUploaded event. Three independent services must receive the event: an embedding service, an auditing service, and a notification service.

Which Service Bus design should you use?

A. Three separate queues with the application sending the message to each queue

B. One queue with three competing consumers

C. One topic with three subscriptions

D. One subscription attached to three queues

Answer: C. One topic with three subscriptions

Explanation

A Service Bus topic with multiple subscriptions implements a publish/subscribe pattern. Each subscription can independently receive a copy of the event.

Using a queue with multiple competing consumers would not guarantee that all three services receive the message because competing consumers process a message rather than each receiving an independent copy.

Question 3

An AI worker receives a message using peek-lock mode. The worker successfully completes the AI operation but crashes before completing the Service Bus message.

What can happen?

A. The message is permanently deleted

B. The message can become available for redelivery

C. The message is automatically moved to another subscription

D. The message is converted into a scheduled message

Answer: B. The message can become available for redelivery

Explanation

With peek-lock, the message is not removed until the consumer successfully settles it, typically by completing it.

If the lock expires before completion, Service Bus can make the message available again. This creates the possibility of duplicate processing and is why consumers should be designed to be idempotent.

Question 4

An AI worker repeatedly receives a malformed message that cannot ever be processed successfully. The application should prevent the message from continually consuming worker capacity.

What is the most appropriate action?

A. Increase the message TTL

B. Dead-letter the message

C. Schedule the message for later

D. Extend the message lock indefinitely

Answer: B. Dead-letter the message

Explanation

A permanently invalid message is a good candidate for dead-lettering. The DLQ isolates the message from normal processing while allowing operators or application logic to investigate it.

Increasing retries or extending locks does not solve a permanent data problem.

Question 5

An AI application processes messages that occasionally fail because an external AI service is temporarily unavailable. What should the application generally do first?

A. Retry the operation

B. Immediately delete the message

C. Immediately dead-letter every message

D. Disable the Service Bus queue

Answer: A. Retry the operation

Explanation

A temporary service outage is a transient failure. Retrying the operation is generally appropriate, assuming the retry strategy is bounded and incorporates appropriate delay/backoff.

Permanent failures should generally be dead-lettered rather than repeatedly retried.

Question 6

An AI application uses Service Bus to process critical inference requests. The application must minimize the possibility of losing a request if a worker crashes while processing it.

Which receive mode should be used?

A. Receive-and-delete

B. Peek-lock

C. Browse-only

D. Scheduled delivery

Answer: B. Peek-lock

Explanation

Peek-lock allows the worker to receive and lock the message without immediately removing it. The worker completes the message after successful processing.

If the worker crashes before completion, the message can become available for redelivery after the lock expires.

Receive-and-delete removes the message as soon as it is received, so a worker failure can result in message loss.

Question 7

A document-processing AI solution needs to pass a 20-MB document to a background worker. The development team wants to avoid putting the entire document into the Service Bus message.

What is the best design?

A. Store the document in Blob Storage and place a reference to it in the Service Bus message

B. Convert the document to Base64 and place it directly in the message

C. Split the document into hundreds of unrelated messages

D. Store the document in the message’s correlation ID

Answer: A. Store the document in Blob Storage and place a reference to it in the Service Bus message

Explanation

The claim-check pattern is appropriate for large payloads. The document can be stored in Blob Storage while the Service Bus message contains the document identifier or URI plus relevant metadata.

This keeps the messaging layer focused on coordinating work rather than transporting large payloads.

Question 8

A Service Bus queue has a configured maximum delivery count of 10. A worker receives a message but repeatedly abandons it because processing fails.

What eventually happens when the message exceeds the configured delivery limit?

A. The message is automatically copied to every topic

B. The message is permanently deleted without any record

C. The message is moved to the dead-letter queue

D. The message is automatically sent to Event Grid

Answer: C. The message is moved to the dead-letter queue

Explanation

When a message repeatedly fails processing and exceeds the configured maximum delivery count, Service Bus moves it to the DLQ.

The DLQ provides a separate location where the message can be investigated and, when appropriate, corrected and reprocessed.

Question 9

An AI system publishes messages describing uploaded documents. The application has separate consumers for compliance, analytics, and embedding generation. Each consumer should receive its own copy of applicable messages.

Which feature should the developer use to route only relevant messages to each consumer?

A. Queue sessions

B. Topic subscription filters

C. Message lock renewal

D. Receive-and-delete mode

Answer: B. Topic subscription filters

Explanation

Topic subscriptions can use filters to determine which messages are delivered to each subscription.

For example, a compliance subscription could receive only documents belonging to a particular business category while an embedding subscription receives all document events.

Question 10

An AI worker processes a message successfully and writes the result to a database. Before the worker completes the Service Bus message, it crashes. The message is subsequently delivered again.

What is the best way for the application to handle this possibility?

A. Assume Service Bus guarantees exactly-once application processing

B. Disable message retries

C. Design the processing operation to be idempotent

D. Use receive-and-delete mode

Answer: C. Design the processing operation to be idempotent

Explanation

Peek-lock processing provides reliable message handling but does not eliminate the possibility of duplicate processing. A worker can successfully perform its business operation and then fail before completing the Service Bus message.

The message may therefore be delivered again.

An idempotent application can safely recognize that the operation has already been performed—for example, by using a document ID and version as an idempotency key—rather than creating duplicate results.

Receive-and-delete would actually increase the risk of losing messages if the worker fails before completing its work.

This exam topic is especially worth mastering for AI-200 because exam scenarios often combine Service Bus + asynchronous AI processing + retries + competing consumers + DLQs rather than asking about those features in isolation.

Go to the AI-200 Exam Prep Hub main page