Tag: Azure Security

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

Implement security policies for back-end API protection by using API Management (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 application platform services
      --> Implement security policies for back-end API protection by using API Management

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

APIs are a critical part of modern cloud applications. They allow web applications, mobile applications, business systems, AI applications, and other services to communicate with back-end resources.

However, exposing an API creates a significant security responsibility. Organizations must control:

Who can call an API
How callers authenticate
What callers are authorized to do
How frequently APIs can be called
Where requests originate
What traffic is allowed to reach back-end services
How API credentials are protected
How connections between API Management and back-end services are secured
How potentially malicious or malformed requests are handled

Azure API Management (APIM) provides an API gateway that can enforce security policies between API consumers and back-end APIs.

The SC-500 exam specifically expects knowledge of securing back-end APIs with API Management, including subscription keys, JWT validation, OAuth 2.0, IP filtering, rate limiting, virtual network integration, and mutual TLS (mTLS).

A useful way to think about API Management security is:

                    API Consumer
                         |
                         v
              +---------------------+
              | Azure API Management|
              |       Gateway       |
              +---------------------+
                 |       |       |
          Authentication  |   Network
          Authorization   |   Controls
                 |        |
                 v        v
             Policies   Filtering
                 |
                 v
              Backend API

API Management policies execute in the gateway and can inspect, validate, transform, route, and control API requests and responses. Microsoft currently provides more than 75 built-in policies covering scenarios such as authentication, rate limiting, filtering, transformation, and validation.

1. Understanding the API Management Security Model

API Management sits between the API consumer and the back-end API.

Without API Management:

			
Client
   |
   v
Backend API

With API Management:

			
Client
   |
   v
Azure API Management
   |
   |-- Authenticate
   |-- Authorize
   |-- Validate
   |-- Rate limit
   |-- Filter IPs
   |-- Transform
   |-- Log/monitor
   |
   v
Backend API

		

This creates a centralized enforcement point.

Instead of implementing every security control independently inside every API, organizations can implement common controls at the API gateway.

Important distinction

API Management policies are runtime API policies.

They should not be confused with Azure Policy.

Feature	Purpose
API Management policy	Controls API requests/responses at runtime
Azure Policy	Governs Azure resources and enforces organizational compliance
Azure RBAC	Controls who can manage Azure resources
Microsoft Entra ID	Provides identity and authentication
Network Security Group	Controls network traffic
Azure Firewall	Provides centralized network traffic filtering

Microsoft specifically distinguishes API Management policies from Azure Policy: APIM policies execute in the gateway, while Azure Policy evaluates and enforces compliance for Azure resources.

2. API Management Policy Scopes

Policies can be applied at different levels.

Common scopes include:

Global/API Management instance
Product
API
Operation

This allows security controls to be applied broadly or narrowly.

For example:

			
API Management
      |
      +-- Global policy
      |
      +-- Product policy
      |
      +-- API policy
              |
              +-- Operation policy

		

Why scope matters

Suppose every API requires a particular security header.

A global policy may make sense.

Suppose only the /payments API requires a particular JWT claim.

An API-level policy may be more appropriate.

Suppose only POST /payments requires an additional validation rule.

An operation-level policy may be appropriate.

Best practice

Apply security controls at the narrowest practical scope when the requirement is specific to a particular API or operation, while using broader scopes for controls that should consistently apply across the environment.

3. Subscription Keys

Azure API Management supports subscription keys as a mechanism for controlling access to APIs.

A subscription represents a relationship between an API consumer and one or more APIs or products.

The consumer can provide a subscription key with an API request.

Conceptually:

			
Client
   |
   | Subscription key
   v
API Management
   |
   | Validate subscription
   v
Backend API

		

Subscription keys provide a way to identify and control API consumers.

They can also be useful for:

Tracking API consumption
Managing subscriptions
Applying quotas or rate limits
Controlling access to products/APIs

Important exam distinction

A subscription key should not automatically be considered equivalent to strong user authentication.

A subscription key primarily identifies an API subscription.

It does not inherently prove the identity of an individual user in the same way that a Microsoft Entra access token can.

For applications requiring user or workload identity, OAuth 2.0 and JWT validation may be more appropriate.

4. Subscription Keys and Products

API Management products provide an important organizational mechanism for grouping APIs and managing consumer access.

For example:

			
Product: Customer APIs
       |
       +-- Customer API
       +-- Orders API
       +-- Account API

		

A subscription can provide access to a product.

This makes it possible to manage access to groups of APIs rather than independently configuring every API consumer for every individual API.

Example

A company might create:

Internal APIs

Employee API
HR API
Finance API

Partner APIs

Orders API
Inventory API
Shipping API

Different consumers can receive different subscriptions and access different products.

5. JWT-Based Authentication

JSON Web Tokens, or JWTs, are commonly used to authenticate API callers.

A JWT can contain claims about:

The caller
The issuer
The intended audience
Expiration
Permissions or scopes
Other identity information

A typical flow is:

			
Client
   |
   | Authorization: Bearer <JWT>
   v
API Management
   |
   | Validate JWT
   |
   +---- Invalid ----> Reject
   |
   +---- Valid ------> Backend API

		

API Management provides a validate-jwt policy that can validate JWT tokens. The policy can verify aspects such as token issuer, audience, signature, expiration, and claims depending on its configuration.

6. Validate JWT Policy

The validate-jwt policy is one of the most important policies for SC-500.

A simplified policy looks conceptually like:

			
<validate-jwt header-name="Authorization"
              require-scheme="Bearer">
    ...
</validate-jwt>

The actual configuration must specify the appropriate issuer/signing keys/audience and other requirements for the identity provider and API.

The policy can validate that:

A token exists
The token is properly signed
The token was issued by an expected issuer
The token is intended for the expected audience
The token has not expired
Required claims are present

Why audience matters

Consider a token issued for:

Audience = API-A

An attacker attempts to use that token against:

API-B

If API-B validates the audience correctly, it can reject the token.

This is an important security control.

7. Microsoft Entra ID and JWT Validation

Microsoft Entra ID is frequently used as the identity provider for API authentication.

The flow can look like:

			
User/Application
       |
       | Authenticate
       v
Microsoft Entra ID
       |
       | Access token
       v
API Management
       |
       | Validate JWT
       v
Backend API

		

API Management can validate Microsoft Entra-issued tokens using JWT validation policies. Current API Management policy support includes a dedicated validate Microsoft Entra token policy as well as the general JWT validation policy.

Exam concept

If the question asks:

“How can API Management verify that an incoming request contains a valid Microsoft Entra access token?”

Think:

JWT/token validation policy.

8. Claims-Based Authorization

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to do?

JWT claims can help API Management enforce authorization requirements.

For example, an API may require:

scope = Orders.Read

A more privileged API may require:

scope = Orders.Write

API Management can inspect token claims and reject requests that do not satisfy the required conditions.

This allows security decisions to occur before the request reaches the backend.

9. OAuth 2.0

OAuth 2.0 provides a standardized framework for delegated authorization.

A simplified flow is:

			
Client
   |
   | Request authorization
   v
Identity Provider
   |
   | Access token
   v
Client
   |
   | Bearer token
   v
API Management
   |
   | Validate
   v
Backend API

		

API Management can be configured to work with OAuth 2.0 authorization servers, including Microsoft Entra ID. Microsoft currently recommends the Microsoft identity platform v2 endpoint for OAuth scenarios where applicable.

OAuth vs subscription key

Capability	Subscription key	OAuth/JWT
API subscription identification	Yes	Not its primary purpose
User identity	Limited	Stronger identity model
Token expiration	No inherent token concept	Yes
Claims/scopes	No	Yes
Delegated authorization	No	Yes
Microsoft Entra integration	Possible as part of broader design	Strong integration

10. OAuth 2.0 for Backend APIs

API Management can also help manage credentials and authorization for calls from API Management to backend services.

This is an important distinction.

There are potentially two authentication relationships:

			
Consumer
   |
   | Authenticate
   v
API Management
   |
   | Authenticate
   v
Backend API

		

The authentication method used by the consumer does not necessarily have to be the same authentication method used by API Management when it calls the backend.

API Management’s current credential manager can manage OAuth 2.0 connections to backend APIs and can acquire, cache, and refresh tokens for supported scenarios.

11. Managed Identity for Backend Authentication

API Management can authenticate to supported backend services using a managed identity.

This can reduce the need to store credentials such as:

Client secrets
Passwords
Long-lived access tokens

Conceptually:

			
API Management
       |
       | Managed identity
       v
Azure Resource / Backend

		

The API Management policy reference currently includes an authenticate with managed identity policy for authenticating to backend services.

Why this is important

Managed identity follows the principle:

Don’t store a secret when Azure can provide an identity.

It is therefore generally preferable to hard-coded credentials.

12. IP Filtering

API Management can restrict API access based on the caller’s IP address.

For example:

			
Corporate network
10.20.0.0/16
       |
       v
API Management
       |
       +---- Allow

		

And:

			
Unknown source
203.0.113.0/24
       |
       v
API Management
       |
       +---- Deny

		

API Management provides a policy to restrict callers by IP address or IP address range.

When IP filtering is useful

It can be appropriate for:

Internal APIs
Partner APIs
Administrative APIs
Known integration platforms
Restricted enterprise networks

Important limitation

IP filtering should not be treated as a replacement for authentication.

An IP address identifies a network source, not necessarily an individual user.

13. Rate Limiting

An API can become unavailable or expensive when clients send excessive requests.

API Management can apply rate limiting policies.

For example:

			
Client
  |
  | 100 requests
  |-------------------->
  |
API Management
  |
  | Threshold = 50
  |
  +---- Additional requests rejected

		

Rate limiting can protect:

Application capacity
Backend systems
APIs with expensive operations
Shared services
APIs susceptible to abuse

API Management policies include rate-limiting capabilities for controlling incoming calls.

14. Rate Limiting vs Quotas

Rate limiting and quotas are related but different concepts.

Rate limiting

Controls how many requests can occur during a relatively short period.

Example:

No more than 100 calls per minute.

Quota

Controls consumption over a longer period.

Example:

No more than 100,000 calls per month.

Conceptually:

			
Rate limit:
100 calls / minute
Quota:
100,000 calls / month

Exam tip

If the scenario describes burst/excessive requests over a short period, think rate limiting.

If it describes total consumption over a longer period, think quota.

15. IP Filtering + Rate Limiting

Security policies can be combined.

For example:

			
Incoming request
       |
       v
IP filter
       |
       +---- Unauthorized source --> Reject
       |
       v
JWT validation
       |
       +---- Invalid token -------> Reject
       |
       v
Rate limit
       |
       +---- Too many requests ---> Reject
       |
       v
Backend API

		

This is an example of defense in depth.

No single policy has to solve every security problem.

16. Request and Response Validation

API Management can validate request and response content.

The validate-content policy can validate the size and/or content of request or response bodies against supported schemas, including JSON and XML.

This can help prevent unexpected or malformed content from reaching an API.

For example:

			
Client
   |
   | JSON request
   v
API Management
   |
   | Validate schema
   |
   +---- Invalid --> Reject
   |
   v
Backend API

		

This is particularly useful for APIs with strict data contracts.

17. Mutual TLS (mTLS)

Mutual TLS, or mTLS, provides certificate-based authentication between communicating parties.

With normal TLS:

Client  <---- TLS ---->  Server

The server proves its identity to the client.

With mTLS:

			
Client  <---- Mutual TLS ---->  Server
   |                            |
   +-- Client certificate       |
                                |
                    Server certificate

		

Both sides authenticate using certificates.

API Management supports policies for validating client certificates and authenticating to backend services using client certificates.

18. mTLS for Backend APIs

One particularly important use case is securing the connection between API Management and a backend API.

For example:

			
API Consumer
      |
      | HTTPS
      v
API Management
      |
      | mTLS
      v
Secure Backend API

		

The backend can require API Management to present a client certificate.

API Management supports an authentication-certificate policy for authenticating with a backend service using a client certificate.

When to use mTLS

mTLS is particularly appropriate when:

A backend requires certificate-based client authentication.
Strong machine-to-machine authentication is required.
An organization operates partner APIs requiring certificates.
Traditional API keys are insufficient.
The environment has established PKI infrastructure.

19. Network Security for API Management

API-level policies are only one layer of security.

API Management can also be integrated with Azure networking capabilities.

Current API Management networking options include:

Virtual network injection
Virtual network integration
Inbound private endpoints
Private Link
Network security controls

The exact capabilities depend on the API Management tier.

20. Virtual Network Integration

Virtual network integration can allow API Management to make outbound requests to APIs hosted in a connected virtual network.

For example:

                    Azure VNet
             +----------------------+
             |                      |
API Management -----> Private API   |
             |                      |
             +----------------------+

For current Standard v2 and Premium v2 configurations, virtual network integration supports outbound connectivity to APIs isolated in a connected or peered virtual network. However, this configuration does not by itself make the API Management gateway private; the gateway and developer portal remain publicly accessible unless additional controls are configured.

Exam trap

Do not assume:

VNet integration = private inbound API Management endpoint.

VNet integration in these v2 scenarios primarily provides outbound connectivity.

21. Inbound Private Endpoint

An inbound private endpoint provides private connectivity to the API Management instance.

Conceptually:

			
Private Client
      |
      v
Private Endpoint
      |
      v
Azure API Management
      |
      v
Backend API

		

The private endpoint receives an IP address from the virtual network.

Traffic can then travel through Azure Private Link rather than being exposed through the public internet.

Microsoft’s current documentation states that the inbound private endpoint is for inbound traffic and that public network access can be disabled after configuring a private endpoint.

Important distinction

Capability	Primary purpose
VNet integration	Outbound connectivity
Inbound private endpoint	Private inbound access
VNet injection	Network isolation of APIM, depending on tier/configuration

This distinction is highly relevant for exam questions.

22. Virtual Network Injection

Some API Management tiers support virtual network injection.

In this architecture, the API Management instance can be deployed into a delegated subnet.

For supported configurations, this can provide stronger network isolation for the API Management gateway and its backend connectivity.

The current Premium v2 documentation describes virtual network injection as providing both inbound and outbound network connectivity through the virtual network and is intended for scenarios where both the API Management instance and backend APIs need isolation.

Exam concept

When a scenario emphasizes:

“Isolate the API Management instance itself inside a private network.”

Think about virtual network injection/private networking, depending on the APIM tier and architecture.

23. Securing the Backend

Securing API Management does not automatically secure the backend API.

Consider:

			
Internet
   |
   v
API Management
   |
   v
Backend API

		

The backend should also be protected.

Potential controls include:

Private networking
Authentication
Managed identity
mTLS
IP restrictions
Network security groups where applicable
Firewall controls
Private endpoints
Network security perimeter capabilities where appropriate

The objective should be to ensure that the backend accepts traffic from legitimate API Management paths rather than becoming an independent publicly exposed API.

24. API Management as a Security Gateway

A mature architecture often uses APIM as the central policy enforcement point.

For example:

                       Clients
                          |
             +------------+------------+
             |            |            |
          Web App      Mobile App    Partner
             |            |            |
             +------------+------------+
                          |
                          v
               +---------------------+
               | Azure API Management|
               |                     |
               | Subscription keys   |
               | JWT validation      |
               | OAuth 2.0           |
               | IP filtering        |
               | Rate limiting       |
               | Content validation  |
               | mTLS                |
               +---------------------+
                          |
                          v
                 Private Backend APIs

This architecture centralizes common security requirements.

25. AI APIs and API Management

API Management can also be used as a security and governance layer for AI model endpoints.

This is increasingly important because AI applications often expose APIs to:

Language models
AI agents
AI applications
Retrieval systems
External consumers
Internal applications

The current SC-500 learning module explicitly includes AI Gateway capabilities for securing and governing AI model endpoints.

This extends the API gateway concept beyond traditional REST APIs.

An AI gateway can help organizations apply centralized policies to AI traffic, such as:

Authentication
Authorization
Rate limiting
Content controls
Usage governance
Monitoring

26. AI Gateway and Content Safety

API Management’s current policy framework includes AI-specific capabilities, including enforcing content-safety checks on LLM requests by sending prompts to Azure AI Content Safety before they are sent to the backend LLM.

Conceptually:

			
AI Application
      |
      v
API Management AI Gateway
      |
      +---- Authentication
      |
      +---- Rate limiting
      |
      +---- Content safety
      |
      +---- Governance
      |
      v
LLM / AI Backend

		

This is particularly relevant to the evolving SC-500 emphasis on securing cloud and AI workloads.

27. A Layered API Security Model

A useful way to remember the complete approach is to divide security into layers.

Layer	Example control
Identity	Microsoft Entra ID
Authentication	OAuth 2.0 / JWT
Subscription	Subscription keys
Authorization	JWT claims/scopes
Network	VNet/private endpoint
Source filtering	IP filtering
Abuse protection	Rate limiting
Content	Schema/content validation
Machine authentication	mTLS
Backend authentication	Managed identity
AI security	AI Gateway/content safety
Monitoring	API Management/Azure Monitor

No single control is sufficient for every API.

28. Example: Secure a Partner API

Consider a company exposing an Orders API to a business partner.

Requirements:

Only the partner can access the API.
Requests must contain valid Microsoft Entra tokens.
The partner’s network has known IP ranges.
Excessive API requests must be limited.
The backend must not be publicly exposed.
API Management must authenticate to the backend.

A possible design is:

			
Partner
   |
   | Microsoft Entra token
   v
API Management
   |
   +-- Validate JWT
   |
   +-- IP filtering
   |
   +-- Rate limiting
   |
   +-- Subscription management
   |
   v
Private Backend
   ^
   |
Managed Identity

		

This provides multiple independent controls.

If an attacker obtains an IP address within an allowed range but lacks a valid token, JWT validation can reject the request.

If a legitimate partner begins sending excessive traffic, rate limiting can protect the backend.

If the backend is private, network controls can prevent direct public access.

29. Example: Secure a Machine-to-Machine API

Suppose an enterprise application calls a sensitive internal API.

Requirements:

No interactive user sign-in
Strong workload identity
Private network connectivity
Certificate-based backend authentication

A suitable architecture could use:

			
Enterprise Application
        |
        | Token / approved authentication
        v
API Management
        |
        | Private network
        |
        | mTLS
        v
Internal Backend

		

The exact combination depends on the identity architecture, but the key concept is that machine identity, network isolation, and certificate authentication solve different security problems.

30. Common API Management Security Mistakes

Mistake 1: Treating a subscription key as complete authentication

A subscription key identifies API subscription access but should not automatically be treated as equivalent to strong user or workload identity.

Better: Use OAuth 2.0/JWT validation when identity and claims-based authorization are required.

Mistake 2: Using IP filtering instead of authentication

An IP address does not establish who the caller is.

Better: Combine IP filtering with strong authentication where appropriate.

Mistake 3: Confusing VNet integration with a private inbound gateway

In current v2 configurations, VNet integration primarily enables outbound connectivity to private backends while the gateway remains publicly accessible.

Better: Use the appropriate private endpoint or VNet injection architecture when private inbound access is required.

Mistake 4: Exposing the backend publicly

Putting API Management in front of an API does not automatically make the backend private.

Better: Restrict backend access and use private networking where appropriate.

Mistake 5: Hard-coding backend secrets

Storing long-lived credentials in application configuration increases security risk.

Better: Prefer managed identity or appropriate secure credential-management mechanisms.

Mistake 6: Applying rate limiting only inside application code

Application-level rate limiting may require every API to independently implement and maintain the same logic.

Better: Use API Management policies for centralized API traffic controls.

Mistake 7: Using broad policies when narrow policies are sufficient

A global security rule can unintentionally affect APIs that do not require it.

Better: Choose the appropriate policy scope.

31. API Management Security Decision Matrix

Requirement	APIM capability
Identify API subscription	Subscription key
Authenticate users/workloads	OAuth 2.0 / JWT
Validate Microsoft Entra access token	JWT/Entra token validation
Check token claims/scopes	JWT validation/authorization logic
Block specific source IPs	IP filtering
Limit requests per period	Rate limiting
Limit longer-term consumption	Quotas
Validate request body	Content/schema validation
Authenticate backend with Azure identity	Managed identity
Authenticate backend with certificate	mTLS/client certificate
Private inbound APIM access	Private endpoint
Reach private backend	VNet integration/injection as supported
Isolate APIM and backend	Appropriate VNet/private architecture
Protect AI endpoints	AI Gateway policies
Apply LLM content safety checks	AI/content-safety policy
Centralize API security	API Management policies

32. SC-500 Exam-Focused Comparison

Several capabilities can look similar in scenario questions.

If the question says…	Think…
“Identify the API consumer’s subscription”	Subscription key
“Validate an access token”	JWT validation
“Microsoft Entra authentication”	OAuth 2.0 / JWT
“Validate required token claims”	JWT validation
“Block calls from a specific IP range”	IP filtering
“Prevent excessive requests”	Rate limiting
“Limit total API usage over a period”	Quota
“Validate JSON/XML body”	Content validation
“Authenticate APIM to backend without a secret”	Managed identity
“Certificate-based backend authentication”	mTLS/client certificate
“Allow private clients to reach APIM”	Private endpoint
“Allow APIM to reach a private backend”	VNet integration/injection
“Keep APIM and backend isolated”	Private networking/VNet architecture
“Secure AI model endpoints”	AI Gateway

33. Key Takeaways

For SC-500, remember these principles:

API Management is a centralized API gateway and policy enforcement point.
Subscription keys provide subscription-based API access and identification.
JWT validation verifies access tokens and their claims.
OAuth 2.0 provides a standardized authorization framework.
Microsoft Entra ID can be used as the identity provider for OAuth/JWT scenarios.
IP filtering controls where API requests originate.
Rate limiting controls excessive short-term request activity.
Quotas control longer-term API consumption.
Managed identity can authenticate API Management to supported backend resources without storing credentials.
mTLS provides certificate-based authentication between communicating parties.
Content validation can reject requests or responses that do not conform to expected schemas or size requirements.
VNet integration and private endpoints solve different networking problems.
An inbound private endpoint provides private access to the API Management gateway.
VNet integration in current v2 tiers primarily enables outbound access to private backends; it does not automatically make the gateway private.
AI Gateway extends API Management security and governance to AI model endpoints.
Security controls should be layered rather than relying on one mechanism.

Practice Exam Questions

Question 1

A company exposes several APIs through Azure API Management. The company wants to identify API consumers and control which APIs they can access through an API subscription.

Which capability should the security engineer configure?

A. Azure Private Endpoint

B. Subscription keys

C. Client certificates

D. IP filtering

Answer: B

Explanation

Subscription keys are designed to provide subscription-based access to APIs and identify API consumers within the API Management subscription model.

Private endpoints address network connectivity, client certificates provide certificate-based authentication, and IP filtering restricts traffic based on source IP addresses.

Question 2

An organization exposes a sensitive API through API Management. The API should accept requests only when the caller presents a valid Microsoft Entra access token intended for the API and containing the required claims.

Which capability should be implemented?

A. Rate limiting

B. Subscription key validation only

C. IP filtering

D. JWT/token validation

Answer: D

Explanation

A JWT validation policy can validate the access token’s signature, issuer, audience, expiration, and required claims according to the configured policy.

A subscription key alone does not provide equivalent identity and claims-based authorization.

Question 3

An API Management instance must call an Azure backend service. The security team does not want to store a client secret or password in the API configuration.

Which authentication mechanism is most appropriate?

A. Managed identity

B. IP filtering

C. Subscription key

D. Anonymous access

Answer: A

Explanation

A managed identity allows API Management to authenticate to supported Azure resources without storing a long-lived credential in the application or API policy.

This supports a secretless authentication model and aligns with least-credential principles.

Question 4

A public API is being abused by a client that sends thousands of requests within a short period. The organization wants API Management to automatically restrict the number of requests the client can make during a defined interval.

Which capability should be used?

A. OAuth 2.0

B. mTLS

C. Rate limiting

D. Private endpoint

Answer: C

Explanation

Rate limiting is designed to control the number of calls received during a defined period.

OAuth 2.0 addresses authorization, mTLS provides certificate-based authentication, and private endpoints address network connectivity.

Question 5

An organization has API Management integrated with a virtual network. The API Management instance must call an API hosted on a private subnet. However, the security team also wants API consumers to continue reaching the API Management gateway through its public endpoint.

Which capability best satisfies the networking requirement?

A. Disable all public access to API Management

B. Configure outbound virtual network integration

C. Configure an API subscription key

D. Configure JWT validation

Answer: B

Explanation

Current Standard v2 and Premium v2 API Management configurations support virtual network integration for outbound requests to APIs isolated within a connected or peered virtual network.

Importantly, this does not by itself make the API Management gateway private; its gateway and developer portal can remain publicly accessible.

Question 6

A company wants only clients from a set of known corporate IP ranges to call a particular API through API Management.

Which policy should the security engineer use?

A. IP filtering

B. JWT validation

C. Content validation

D. Managed identity

Answer: A

Explanation

The API Management IP filtering capability can allow or deny calls based on specific IP addresses or address ranges.

However, IP filtering should generally complement rather than replace strong authentication.

Question 7

A company requires API Management to authenticate to a highly sensitive partner backend using a client certificate. The partner will reject requests unless API Management presents the expected certificate.

Which capability should be configured?

A. Subscription key

B. Rate limiting

C. OAuth authorization code

D. Client certificate authentication/mTLS

Answer: D

Explanation

mTLS/client certificate authentication is appropriate when a backend requires certificate-based authentication from API Management.

API Management provides an authentication-certificate policy for authenticating with a backend using a client certificate.

Question 8

A security engineer wants API Management to reject requests whose JSON body does not conform to the API’s expected schema.

Which capability should be used?

A. IP filtering

B. Subscription key validation

C. Content validation

D. Private endpoint

Answer: C

Explanation

The validate-content policy can validate the size and/or content of request or response bodies against supported schemas, including JSON and XML.

The other options address identity, network access, or subscription management.

Question 9

A company wants clients inside its private Azure network to connect to an API Management gateway without exposing the gateway through the public internet. The organization also wants to disable public network access to the API Management instance.

Which solution is most appropriate?

A. Inbound private endpoint

B. Rate limiting

C. Subscription key

D. JWT validation

Answer: A

Explanation

An inbound private endpoint provides private connectivity to the API Management instance using Azure Private Link and a private IP address from the virtual network.

Current API Management documentation states that public network access can be disabled after configuring an inbound private endpoint.

Question 10

A company is building an AI application that accesses an LLM through Azure API Management. The security team wants a centralized gateway that can apply authentication, traffic controls, and AI-specific protections before requests reach the model endpoint.

Which capability is most appropriate?

A. Azure Bastion

B. AI Gateway capabilities in API Management

C. Azure Network Security Group only

D. Azure Private DNS

Answer: B

Explanation

API Management’s AI Gateway capabilities extend gateway security and governance to AI model endpoints. Current policy capabilities include AI-specific controls such as content-safety checks for LLM requests, in addition to traditional API controls such as authentication and rate limiting.

Azure Bastion is designed for secure VM administration, NSGs provide network-level filtering, and Private DNS provides name resolution rather than centralized AI API governance.

Go to the SC-500 Exam Prep Hub main page

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

Identify security risks by using Defender CSPM (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
      --> Identify security risks by using Defender CSPM

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

Cloud environments are constantly changing. New resources are deployed, permissions are modified, workloads are exposed to the internet, vulnerabilities are discovered, and applications increasingly incorporate AI capabilities. Because of this, security teams need more than point-in-time security checks—they need continuous visibility into their overall security posture and a way to determine which security issues represent the greatest risk.

Microsoft Defender Cloud Security Posture Management (Defender CSPM) is a capability within Microsoft Defender for Cloud that helps organizations identify, understand, prioritize, and remediate security risks across their cloud environments.

For the SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads exam, Defender CSPM is particularly important because it brings together several concepts:

Security posture assessment
Secure Score
Security recommendations
Risk-based prioritization
Attack path analysis
Cloud Security Explorer
Cloud Security Graph
Agentless scanning
Sensitive data discovery
Identity and permission analysis
Internet exposure
Multicloud security posture
Security posture for AI and other modern workloads

The objective is not simply to find the largest number of security problems. The goal is to determine which problems represent the greatest likelihood and potential impact of a successful attack.

1. What Is Cloud Security Posture Management?

Cloud Security Posture Management (CSPM) is the practice of continuously assessing cloud resources and configurations to identify security weaknesses, misconfigurations, compliance issues, vulnerabilities, and other risks.

A CSPM solution helps answer questions such as:

Which cloud resources are exposed to the internet?
Which resources have insecure configurations?
Which identities have excessive permissions?
Which workloads contain vulnerabilities?
Which resources contain sensitive data?
Which security recommendations should be remediated first?
Can an attacker combine several individual weaknesses into a path toward a critical resource?
Are security controls consistently applied across cloud environments?

Defender CSPM provides posture-management capabilities across cloud environments and uses contextual information to help security teams move from a large collection of individual findings toward a more meaningful understanding of organizational risk.

Microsoft describes Defender CSPM as providing visibility into the organization’s security situation while continually assessing resources, subscriptions, and the broader environment.

2. Defender CSPM in Microsoft Defender for Cloud

Microsoft Defender for Cloud provides two important perspectives on cloud security:

Cloud Security Posture Management

CSPM focuses primarily on understanding and improving the security configuration and posture of cloud environments.

Cloud Workload Protection

Workload protection capabilities focus more heavily on protecting specific workload types such as:

Servers
Containers
Storage
Databases
App services
AI services

For the SC-500 exam, remember:

CSPM helps you understand and improve the security posture of your cloud environment.

Defender CSPM extends this capability by adding contextual risk analysis, attack paths, Cloud Security Explorer, agentless scanning, sensitive-data discovery, entitlement insights, and other advanced capabilities.

3. Foundational CSPM vs. Defender CSPM

One important SC-500 concept is understanding the distinction between the foundational posture capabilities and the enhanced Defender CSPM plan.

Foundational CSPM

Foundational CSPM provides basic security posture capabilities, including visibility into security recommendations and the organization’s security posture.

Defender CSPM

The Defender CSPM plan adds more advanced capabilities, including:

Enhanced security posture management
Governance capabilities
Regulatory compliance capabilities
Cloud Security Explorer
Attack path analysis
Agentless machine scanning
Agentless Kubernetes discovery
Agentless container vulnerability assessment
Sensitive data discovery
Cloud Infrastructure Entitlement Management (CIEM)
Serverless protection
Additional contextual risk analysis

Microsoft’s current documentation specifically identifies governance, regulatory compliance, Cloud Security Explorer, attack path analysis, and agentless machine scanning as capabilities available through Defender CSPM.

Exam Tip

If a question asks which capability provides contextual investigation of relationships and potential attack paths, think:

Defender CSPM

rather than basic security posture assessment alone.

4. Understanding Security Posture

Security posture represents the overall security condition of an organization’s environment.

A strong security posture generally means that:

Resources are securely configured.
Access is appropriately restricted.
Vulnerabilities are addressed.
Sensitive data is appropriately protected.
Internet exposure is minimized.
Security policies are consistently applied.
High-risk recommendations are prioritized.
Attack paths are eliminated.
Security controls are continuously monitored.

Defender for Cloud continuously evaluates resources and generates security findings and recommendations.

Instead of treating every finding equally, Defender for Cloud can use contextual information to determine which findings represent greater risk.

5. Microsoft Secure Score

One of the most visible posture-management concepts in Defender for Cloud is Secure Score.

Secure Score provides an aggregated representation of security findings and helps organizations understand their overall security posture.

In general:

A higher Secure Score indicates a stronger security posture and lower identified risk.

The score is based on security findings and recommendations across the environment.

Example

Suppose an organization has 100 security recommendations.

Some might involve:

A low-impact configuration issue
A publicly exposed storage resource
An administrator account with excessive permissions
A vulnerable internet-facing virtual machine
A database containing sensitive information

Secure Score helps provide an overall posture indicator, but security teams should not assume that improving the score always means they have addressed the most dangerous threat.

This distinction is important.

6. Secure Score Is Not the Same as Risk Prioritization

A common SC-500 trap is assuming that the recommendation that improves Secure Score the most is automatically the recommendation that should be fixed first.

That is not necessarily true.

Defender for Cloud’s risk prioritization uses contextual factors such as:

Internet exposure
Permissions
Data sensitivity
Lateral movement potential
Exploitability
Relationships between resources
Attack path context

Current Defender for Cloud documentation explicitly distinguishes risk prioritization from Secure Score: risk prioritization does not affect the Secure Score itself.

Example

Consider two recommendations:

Recommendation A

A development storage account has a minor configuration issue and would significantly improve Secure Score if remediated.

Recommendation B

A vulnerable internet-facing VM has excessive privileges and a network path to a production database containing sensitive data.

Recommendation B should likely receive much higher operational priority even if fixing Recommendation A produces a larger Secure Score improvement.

Exam Principle

Secure Score tells you about overall posture; risk prioritization helps determine what deserves attention first.

7. Security Recommendations

A security recommendation identifies a security issue and provides guidance for addressing it.

A recommendation can contain information such as:

Description of the issue
Affected resource
Severity
Risk factors
Remediation guidance
Related security controls
Attack-path context, when applicable

Recommendations can therefore move the security team from:

Detection → Understanding → Remediation

Current Defender for Cloud recommendations can include severity, risk factors, affected resources, remediation guidance, and attack-path context.

8. Security Recommendations vs. Attack Paths

These concepts are related but different.

Security Recommendation

Identifies a specific security weakness.

For example:

A virtual machine should have a more restrictive network security configuration.

Attack Path

Shows how one or more weaknesses could potentially be combined to allow an attacker to reach a valuable target.

For example:

Internet → Exposed VM → Excessive permissions → Storage account → Sensitive data

The individual configuration issues may each appear as separate recommendations.

Attack path analysis provides the additional context that explains why those issues may represent a much greater combined risk.

9. What Is Attack Path Analysis?

Attack path analysis identifies exploitable paths that an attacker could potentially use to move from an external entry point toward a valuable target.

An attack path can include:

An external entry point
A vulnerable or misconfigured resource
An identity or permission relationship
A lateral movement opportunity
A critical resource

Microsoft describes an attack path as a series of steps an attacker could use to breach an environment and reach a critical target.

Example

Imagine the following environment:

			
Internet
   |
   v
Public IP
   |
   v
Vulnerable Virtual Machine
   |
   v
Overprivileged Managed Identity
   |
   v
Storage Account
   |
   v
Sensitive Customer Data

		

Looking at the VM alone might produce one security recommendation.

Looking at the identity alone might produce another.

Looking at the storage account alone might produce another.

Attack path analysis connects these conditions together.

That context can reveal that the combined risk is substantially more serious than any individual finding suggests.

10. Attack Path Analysis Uses the Cloud Security Graph

Defender for Cloud uses a Cloud Security Graph to understand relationships between resources and security conditions.

The graph can incorporate information such as:

Cloud resources
Resource relationships
Network connections
Internet exposure
Permissions
Identities
Vulnerabilities
Lateral movement possibilities
Sensitive data
Other security context

Defender for Cloud uses this contextual graph to identify potential attack paths and prioritize high-risk issues.

Simplified Model

                 Cloud Security Graph
                         |
       +-----------------+-----------------+
       |                 |                 |
   Resources         Identities        Vulnerabilities
       |                 |                 |
       +-----------------+-----------------+
                         |
                   Risk Analysis
                         |
              +----------+----------+
              |                     |
        Attack Paths         Security Explorer

This graph-based approach is one of the most important concepts to understand for the exam.

11. What Makes an Attack Path High Risk?

Attack path analysis considers multiple contextual factors.

Examples include:

Internet exposure

Is the resource reachable from outside the organization’s environment?

Permissions

Does an identity associated with the resource have access to other important resources?

Lateral movement

Can an attacker move from the compromised resource to another resource?

Vulnerability

Does the resource contain a vulnerability that can potentially be exploited?

Data sensitivity

Does the target contain sensitive or business-critical information?

Exploitability

Is the identified weakness realistically exploitable?

The combination of these factors helps Defender for Cloud identify paths that deserve attention.

12. Why Attack Path Analysis Is Different from a Vulnerability List

A traditional vulnerability list might look like:

Resource	Finding
VM01	Critical vulnerability
VM02	High vulnerability
Storage01	Public access
SQL01	Excessive permissions

The list does not necessarily tell you how these findings relate to one another.

Attack path analysis adds context:

Attack Path	Risk
Internet → VM01 → Identity → SQL01	Critical
Internet → VM02	Medium
Storage01 → Sensitive data	High

This allows security teams to focus on security issues that can contribute to an actual attack scenario.

13. Cloud Security Explorer

Cloud Security Explorer provides a way to proactively investigate security risks by querying the Cloud Security Graph.

Instead of waiting for a predefined recommendation, security teams can use queries to investigate relationships and identify risks based on organizational requirements.

For example, a security team might want to find:

Internet-exposed resources with vulnerabilities
Resources with excessive permissions
Virtual machines that can reach sensitive databases
Resources containing sensitive data
Kubernetes resources with risky configurations
Resources connected to identities with excessive privileges

Cloud Security Explorer uses graph-based queries against contextual security information to help security teams proactively investigate risk.

14. Attack Path Analysis vs. Cloud Security Explorer

These two features are easy to confuse.

Capability	Primary Purpose
Attack Path Analysis	Identify exploitable paths attackers could use
Cloud Security Explorer	Proactively investigate and query security relationships
Security Recommendations	Identify and remediate individual security issues
Secure Score	Provide an aggregated view of security posture

Easy Way to Remember

Attack Path Analysis

“How could an attacker get from here to there?”

Cloud Security Explorer

“What security relationships and risks exist in my environment?”

15. Agentless Machine Scanning

Defender CSPM supports agentless machine scanning.

Agentless scanning can provide visibility into:

Installed software
Vulnerabilities
Secrets
Malware-related findings where supported by the applicable Defender plan

The important advantage is that scanning can occur without installing an agent on the machine and without requiring network access to the machine for the scanning process.

Current documentation states that agentless scanning does not require agents or network access and is designed not to affect machine performance. Running VMs are scanned on a recurring schedule.

Why This Matters

Agentless scanning can be especially useful when organizations need visibility into large numbers of machines without deploying and maintaining additional agents.

16. Agentless Kubernetes Discovery

Defender CSPM also provides agentless discovery capabilities for supported Kubernetes environments.

Agentless Kubernetes discovery can provide visibility into:

Kubernetes clusters
Cluster configuration
Workloads
Networking
Node pools
Kubernetes resources

This information can contribute to posture assessment, security investigation, and attack-path analysis.

Current Defender CSPM capabilities include API-based agentless discovery and contextual risk analysis for Kubernetes resources.

17. Sensitive Data Discovery

Security risk is not determined solely by whether a resource is vulnerable.

A vulnerability involving a system containing sensitive information may be considerably more important than an identical vulnerability involving a low-value development resource.

Defender CSPM provides sensitive data discovery capabilities that can identify managed cloud data resources containing sensitive information.

This information can then be incorporated into security investigations and attack-path analysis.

For example:

			
Internet Exposure
       |
       v
Vulnerable Resource
       |
       v
Identity with Permissions
       |
       v
Storage Resource
       |
       v
Sensitive Data

		

The presence of sensitive data increases the potential business impact of the attack path.

Defender for Cloud can use sensitive-data insights in attack paths and Cloud Security Explorer when the relevant capabilities are enabled.

18. Cloud Infrastructure Entitlement Management

Defender CSPM also provides Cloud Infrastructure Entitlement Management (CIEM) capabilities.

CIEM focuses on understanding identities, permissions, and access rights across cloud environments.

Security teams can use CIEM-related insights to identify situations such as:

Excessive permissions
Unused permissions
Overprivileged identities
Risky access relationships

This is particularly important because an attacker who compromises an identity may inherit all the permissions assigned to that identity.

Example

			
Compromised VM
      |
      v
Managed Identity
      |
      +---- Storage Account
      |
      +---- Key Vault
      |
      +---- Database

		

The security risk of the VM is therefore affected by the permissions associated with its identity.

This is another reason why CSPM evaluates relationships, rather than only individual resources.

19. Internet Exposure

Internet exposure is an important risk factor in cloud security.

A resource that is:

Internet accessible
Vulnerable
Overprivileged
Connected to sensitive resources

may represent a significantly greater risk than an equivalent resource that is completely isolated.

Defender CSPM incorporates internet exposure into contextual security analysis.

Defender CSPM also integrates external attack surface management capabilities to discover internet-facing cloud resources and identify exploitable paths originating from internet-exposed IP addresses.

20. Risk-Based Security Prioritization

One of the most important principles in Defender CSPM is:

Not every security finding deserves the same priority.

Security teams frequently face thousands of findings.

A simple severity-only approach can overwhelm security teams.

Instead, Defender for Cloud can consider contextual factors such as:

Exposure
Exploitability
Permissions
Data sensitivity
Lateral movement
Resource relationships
Attack-path context

This enables organizations to focus first on findings that could realistically contribute to a significant security incident.

21. Example: Prioritizing Two Vulnerabilities

Suppose an organization has two critical vulnerabilities.

VM-A

Critical vulnerability
No public exposure
No sensitive data
Limited permissions
Isolated network

VM-B

Critical vulnerability
Internet exposed
High-privilege identity
Can access production SQL
Production SQL contains sensitive data

Although both vulnerabilities are technically critical, VM-B represents the more concerning security scenario.

The reason is not merely the vulnerability severity.

It is the context surrounding the vulnerability.

22. Defender CSPM and AI Workloads

Modern cloud security posture management increasingly includes AI workloads.

Defender CSPM can incorporate security context involving AI resources and AI-related attack paths.

This is important for SC-500 because the certification specifically includes cloud and AI workloads.

Potential AI security concerns include:

Internet-exposed AI resources
Excessive permissions assigned to AI identities
Insecure connections between AI components
Sensitive data accessible to AI workloads
Vulnerable supporting infrastructure
Attack paths involving AI resources

The same fundamental principle applies:

An AI resource should be evaluated in the context of its identities, permissions, data, network exposure, vulnerabilities, and relationships with other resources.

23. Defender CSPM and Multicloud Environments

CSPM is not limited to Azure-only environments.

Defender for Cloud can provide CSPM capabilities across supported multicloud environments, including AWS and Google Cloud Platform.

After supported cloud environments are connected, Defender for Cloud can assess their security posture and surface relevant security information.

This provides a centralized security posture perspective rather than forcing security teams to use completely separate posture-management systems for every cloud provider.

24. Security Posture Management Workflow

A useful way to understand Defender CSPM is to think of it as a continuous cycle:

       Discover
          |
          v
       Assess
          |
          v
       Identify
          |
          v
     Contextualize
          |
          v
      Prioritize
          |
          v
       Remediate
          |
          v
       Reassess
          |
          +------------------+
                             |
                             v
                          Discover

Step 1 — Discover

Identify resources, identities, configurations, vulnerabilities, relationships, and exposure.

Step 2 — Assess

Evaluate resources against security standards and policies.

Step 3 — Identify

Generate security recommendations and other findings.

Step 4 — Contextualize

Use relationships, exposure, permissions, vulnerabilities, and data sensitivity to understand risk.

Step 5 — Prioritize

Focus on the risks that could have the greatest impact.

Step 6 — Remediate

Correct the underlying security weaknesses.

Step 7 — Reassess

Verify that the security posture has improved.

25. A Practical Defender CSPM Investigation

Consider an organization that receives a recommendation indicating that a virtual machine has a serious vulnerability.

A security analyst should not necessarily stop at the recommendation.

The analyst can investigate:

Question 1

Is the VM exposed to the internet?

Question 2

Does the VM have a managed identity?

Question 3

What permissions does that identity have?

Question 4

Can the VM communicate with production resources?

Question 5

Can it reach a database?

Question 6

Does that database contain sensitive information?

Question 7

Is the vulnerability actually exploitable?

Question 8

Does Defender for Cloud identify an attack path involving the VM?

Question 9

Are there additional related recommendations?

Question 10

What remediation would break the attack path most effectively?

This is the mindset the SC-500 exam is testing.

26. Attack Path Remediation

Attack path analysis isn’t simply about identifying problems.

The goal is to break the attack path.

For example:

			
Internet
   |
   v
Public VM
   |
   v
Overprivileged Identity
   |
   v
Sensitive Storage

		

There may be several ways to break this path:

Option 1

Remove unnecessary internet exposure.

Option 2

Fix the vulnerability.

Option 3

Reduce identity permissions.

Option 4

Restrict access to the storage account.

Option 5

Apply multiple controls.

The best remediation may not always be the one that addresses the original finding directly. The goal is to eliminate the exploitable path or substantially reduce its risk.

27. Security Explorer Example

Suppose a security team wants to investigate:

“Find internet-exposed resources that have vulnerabilities and can reach sensitive data.”

Cloud Security Explorer can be used to construct graph-based queries that examine these relationships.

Conceptually:

			
Internet Exposure
       |
       AND
       |
Vulnerable Resource
       |
       AND
       |
Network/Identity Relationship
       |
       AND
       |
Sensitive Data

		

This is fundamentally different from simply searching a list of vulnerabilities.

The security team is asking the platform to identify relationships and contextual risk.

28. Recommendations, Secure Score, Attack Paths, and Security Explorer

These four concepts should be clearly differentiated for the SC-500 exam.

Capability	What It Answers
Secure Score	How strong is our overall security posture?
Security Recommendations	What security weaknesses should we address?
Attack Path Analysis	How could an attacker exploit connected weaknesses to reach a valuable target?
Cloud Security Explorer	What security relationships and risks can we discover by querying the security graph?

Memorization Tip

Think:

Score → Recommendations → Paths → Explore

Score = posture
Recommendations = issues
Paths = attacker movement
Explorer = investigate relationships

29. Common Defender CSPM Mistakes

Mistake 1: Fixing recommendations solely based on severity

Severity is important, but contextual risk can change remediation priority.

Mistake 2: Assuming Secure Score represents total security risk

Secure Score is an important posture metric, but it should not be treated as a complete representation of business or attack-path risk.

Mistake 3: Looking at vulnerabilities individually

A vulnerability becomes more concerning when it is combined with:

Internet exposure
Excessive permissions
Lateral movement
Sensitive data
Other exploitable weaknesses

Mistake 4: Ignoring identities

A compromised workload with minimal permissions may have limited impact.

The same workload with excessive privileges may provide an attacker with access to many other resources.

Mistake 5: Ignoring sensitive data

The value of the target matters.

A vulnerability that leads to sensitive customer information should generally receive greater attention than an equivalent vulnerability affecting an isolated test resource.

Mistake 6: Confusing Attack Path Analysis with Cloud Security Explorer

Attack Path Analysis focuses on identifying exploitable attacker paths.

Cloud Security Explorer is designed for proactive graph-based exploration and investigation.

Mistake 7: Assuming CSPM only applies to virtual machines

Modern CSPM extends across many resource types, including:

Servers
Storage
Containers
Kubernetes
Serverless resources
Databases
Identities
AI workloads
Multicloud resources

30. SC-500 Exam-Focused Comparison

Scenario	Best Concept
Determine overall security posture	Secure Score
Identify a configuration weakness	Security Recommendation
Determine how an attacker can reach a sensitive resource	Attack Path Analysis
Query relationships across cloud resources	Cloud Security Explorer
Scan machines without installing an agent	Agentless Machine Scanning
Identify sensitive data that increases breach impact	Sensitive Data Discovery
Analyze excessive cloud permissions	CIEM
Find internet-facing cloud resources	External Attack Surface Management integration
Prioritize risks based on contextual factors	Risk-based prioritization
Understand resource relationships	Cloud Security Graph

31. Key SC-500 Takeaways

For the exam, remember these principles:

CSPM is about security posture management, not merely vulnerability scanning.
Secure Score provides an aggregated view of security posture.
Security recommendations identify specific security weaknesses and remediation actions.
Risk prioritization uses contextual factors to help determine which findings matter most.
Attack Path Analysis identifies exploitable paths that attackers could use to reach important resources.
The Cloud Security Graph provides contextual relationships between resources, identities, vulnerabilities, exposure, and other security information.
Cloud Security Explorer allows security teams to proactively investigate security relationships using graph-based queries.
Agentless scanning can provide machine visibility without installing an agent.
Sensitive data discovery adds data sensitivity to security-risk analysis.
CIEM helps organizations understand cloud identities, permissions, and entitlement risks.
Internet exposure is an important factor in contextual risk analysis.
Defender CSPM can provide posture capabilities across supported multicloud environments.
CSPM increasingly includes AI workloads and AI-related security risks.
The objective is not to eliminate every finding equally—it is to identify, prioritize, and remediate the risks most likely to result in meaningful compromise.

Practice Exam Questions

Question 1

A security administrator is reviewing thousands of security recommendations in Microsoft Defender for Cloud. The administrator wants to identify the recommendations that could represent the greatest risk of an actual breach.

Which capability should the administrator use?

A. Secure Score

B. Attack path analysis

C. Regulatory compliance dashboard

D. Azure Resource Graph

Answer: B

Explanation

Attack path analysis provides contextual information about exploitable paths through the environment. It considers relationships such as internet exposure, permissions, vulnerabilities, lateral movement, and critical targets.

Secure Score provides an overall posture indicator, but it is not designed to show how an attacker could move through the environment.

Question 2

An organization wants to proactively investigate whether virtual machines with internet exposure can reach storage accounts containing sensitive information.

Which Defender for Cloud capability is most appropriate?

A. Cloud Security Explorer

B. Secure Score

C. Regulatory compliance

D. Microsoft Defender for Endpoint

Answer: A

Explanation

Cloud Security Explorer allows security teams to perform graph-based queries against contextual security information.

The administrator can investigate relationships involving:

Internet exposure
Virtual machines
Network relationships
Identities
Permissions
Sensitive data

Secure Score does not provide this type of relationship-oriented investigation.

Question 3

A company has two security recommendations. Recommendation 1 would produce a larger improvement in Secure Score. Recommendation 2 involves an internet-facing vulnerable server with excessive permissions that can potentially access a sensitive production database.

Which statement is most accurate?

A. Recommendation 1 must always be remediated first because it produces the largest Secure Score improvement.

B. Recommendation 2 should be ignored until Recommendation 1 is remediated.

C. Recommendation 2 may represent greater risk because of its contextual attack-path factors.

D. Both recommendations must always receive exactly the same priority.

Answer: C

Explanation

Secure Score improvement and security-risk prioritization are not the same thing.

The second recommendation has multiple contextual risk factors:

Internet exposure
Vulnerability
Excessive permissions
Potential lateral movement
Access to sensitive data

Those factors can make the second recommendation substantially more important from a real-world security perspective.

Question 4

Which component provides the contextual relationship information used by Defender for Cloud to understand resources, permissions, vulnerabilities, network connections, and potential attacker movement?

A. Secure Score

B. Azure Policy

C. Cloud Security Graph

D. Microsoft Sentinel

Answer: C

Explanation

The Cloud Security Graph is the contextual graph used by Defender for Cloud to represent relationships across cloud resources and security information.

Defender for Cloud can use this graph for capabilities such as attack path analysis and Cloud Security Explorer.

Question 5

A security engineer wants to obtain software inventory and vulnerability information from Azure virtual machines without installing an agent on each machine.

Which Defender for Cloud capability should the engineer consider?

A. Agentless machine scanning

B. Cloud Security Explorer

C. Secure Score

D. Attack path analysis

Answer: A

Explanation

Agentless machine scanning provides visibility into machine software and vulnerabilities without requiring an agent to be installed on the machine.

Agentless scanning is an important Defender CSPM capability.

Question 6

A security team discovers that a compromised application identity has permissions to access several storage resources. The team wants to understand whether excessive cloud permissions are creating additional security risk.

Which capability is most directly associated with this requirement?

A. Cloud Infrastructure Entitlement Management (CIEM)

B. Secure Score

C. External Attack Surface Management

D. Azure DDoS Protection

Answer: A

Explanation

Cloud Infrastructure Entitlement Management (CIEM) provides visibility into cloud identities, permissions, and access rights.

Understanding excessive permissions is particularly important when evaluating the potential impact of a compromised identity.

Question 7

A security analyst sees a critical vulnerability on a server. The server is not publicly exposed and has no meaningful access to other resources.

Another server has the same vulnerability but is internet-facing and has an identity that can access a production database containing sensitive information.

Why might the second server receive a higher risk priority?

A. Its Secure Score contribution is necessarily higher.

B. Its operating system is necessarily newer.

C. It has fewer security recommendations.

D. Its vulnerability is combined with exposure, permissions, lateral movement, and sensitive-data context.

Answer: D

Explanation

Defender CSPM uses contextual risk factors to help prioritize security issues.

The second server presents a potentially exploitable chain:

Internet → Vulnerable server → Privileged identity → Sensitive database

The context surrounding the vulnerability is therefore much more significant than the vulnerability alone.

Question 8

Which statement best describes the primary purpose of Cloud Security Explorer?

A. Replace all vulnerability scanners in the environment

B. Provide graph-based investigation of security relationships and risks

C. Calculate only the organization’s Secure Score

D. Automatically patch every vulnerable resource

Answer: B

Explanation

Cloud Security Explorer allows security teams to proactively investigate the cloud security graph using graph-based queries.

It can help identify relationships involving resources, identities, vulnerabilities, exposure, permissions, and other security context.

It is an investigation and discovery capability—not an automatic patching engine.

Question 9

An organization wants to determine whether an internet-exposed resource provides an exploitable route to a critical database.

Which Defender for Cloud feature is specifically designed to identify this type of attacker route?

A. Attack path analysis

B. Secure Score

C. Azure Policy

D. Microsoft Defender Vulnerability Management

Answer: A

Explanation

Attack path analysis identifies exploitable paths beginning with potential external entry points and continuing through the environment toward valuable targets.

The feature is specifically designed to help security teams understand how multiple weaknesses could combine to create a realistic attack scenario.

Question 10

Which statement best describes the relationship between Secure Score and risk prioritization in Defender for Cloud?

A. Risk prioritization and Secure Score are identical measurements.

B. Secure Score is based exclusively on attack paths.

C. Risk prioritization can use contextual factors that are not represented simply by the Secure Score.

D. A recommendation with the largest Secure Score impact must always be remediated first.

Answer: C

Explanation

Secure Score provides an aggregated view of security posture, while risk prioritization evaluates contextual factors that can make one issue more dangerous than another.

Factors can include:

Internet exposure
Permissions
Data sensitivity
Lateral movement
Exploitability
Attack-path context

Therefore, improving Secure Score is valuable, but security teams should also consider the actual risk associated with each finding.

Final Exam Reminder

The central idea behind this SC-500 topic is:

Defender CSPM moves security teams from simply finding security problems to understanding which problems create the greatest real-world risk.

If you remember the progression:

Security Findings → Context → Risk → Attack Paths → Prioritization → Remediation

you will have a strong conceptual foundation for questions involving Defender CSPM, Secure Score, security recommendations, Cloud Security Explorer, Cloud Security Graph, attack paths, agentless scanning, sensitive data, and identity/permission risk.

Go to the SC-500 Exam Prep Hub main page

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

Cybersecurity, Microsoft Certification, SC-500, security October 10, 2026October 10, 2026

Implement and configure Microsoft Entra Private 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 storage, databases, and networking (25–30%)
   --> Implement security for Azure network services
      --> Implement and configure Microsoft Entra Private 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

Microsoft Entra Private Access is a cloud-delivered, identity-centric Zero Trust Network Access solution that allows users to access private applications and network resources without requiring a traditional VPN. It uses the Global Secure Access client on user devices and private network connectors deployed inside the organization’s network.

Instead of granting a user broad network-level access after connecting to a VPN, Microsoft Entra Private Access allows administrators to define which private resources users can access and apply Microsoft Entra ID-based controls such as user and group assignments, Conditional Access, multifactor authentication, and device compliance requirements.

Microsoft Entra Private Access is particularly useful for:

Remote access to on-premises applications.
Access to private applications hosted in Azure or other cloud environments.
Replacing or reducing reliance on traditional remote-access VPNs.
Applying different access policies to different applications.
Implementing least-privilege access to internal resources.
Supporting hybrid and distributed workforces.

1. Understanding the Microsoft Entra Private Access Architecture

Microsoft Entra Private Access includes several major components.

Microsoft Entra ID

Microsoft Entra ID provides the identity and access control layer. It determines:

Which users and groups can access private resources.
Whether Conditional Access requirements are satisfied.
Whether multifactor authentication is required.
Whether the device must be compliant or managed.
Which private applications are available to the user.

Microsoft Entra Private Access does not simply trust a user because the user is connected to a corporate network. Access is evaluated using identity and policy.

Global Secure Access Client

The Global Secure Access client is installed on supported end-user devices. It identifies traffic destined for configured private resources and forwards that traffic to the Global Secure Access service.

The client is responsible for acquiring the appropriate traffic and establishing the secure connection to the service. At the time of the current implementation guidance, Windows is the primary client platform used in the Private Access configuration tutorials.

Global Secure Access Service

The Global Secure Access service receives traffic from the client and brokers access to the configured private resources. The service applies the applicable traffic-forwarding and access policies before sending traffic toward the private network.

Private Network Connector

A Private Network Connector is a lightweight agent installed on a Windows Server inside the organization’s network. It creates outbound connections to the Microsoft service and provides access to private resources that the connector server can reach.

The connector does not require inbound firewall ports to be opened for users on the internet. The connector initiates outbound communication to the service, which reduces the need to expose internal resources directly to the public internet.

Private Resources

Private resources can include:

Internal websites.
Remote Desktop Protocol servers.
SSH servers.
File shares.
Internal application servers.
Private IP addresses.
Fully qualified domain names.
Private applications hosted in on-premises or cloud networks.

The connector server must be able to resolve and reach the private resource through the organization’s internal network.

2. Microsoft Entra Private Access Versus a Traditional VPN

A traditional VPN generally provides network-level connectivity. Once connected, a user may receive access to a broad address range or subnet.

Microsoft Entra Private Access is designed to provide more granular, application-aware access.

Traditional VPN	Microsoft Entra Private Access
Often grants broad network access	Grants access to configured resources
Usually depends on VPN credentials or certificates	Uses Microsoft Entra identity and policy
Frequently requires inbound VPN infrastructure	Uses outbound private network connectors
Access is commonly based on network location	Access is based on identity, device, and policy
Can expose many internal routes after connection	Can restrict access to specific applications
Often requires separate VPN client infrastructure	Uses the Global Secure Access client

Microsoft Entra Private Access is not automatically a complete replacement for every VPN scenario. It is best suited to private application and resource access where identity-based, least-privilege access is preferred.

3. Quick Access and Per-App Access

Microsoft Entra Private Access provides two primary ways to define private resources:

Quick Access.
Global Secure Access applications, also called per-app access.

Quick Access

Quick Access is used to define a broad collection of private resources that should be routed through Microsoft Entra Private Access.

Administrators can configure:

Fully qualified domain names.
Individual IP addresses.
IP ranges.
Private subnets.

Quick Access is useful when an organization is beginning a VPN replacement project or needs to provide access to a broad set of internal resources.

However, Quick Access can provide wider access than is desirable in a mature Zero Trust environment. Microsoft recommends using Quick Access as a transition stage and moving toward more granular per-application access where practical.

Per-App Access

Per-app access uses a dedicated Microsoft Entra enterprise application to represent a specific private application or group of related application segments.

For example, an organization could create separate private applications for:

Human resources.
Finance.
Internal customer support.
Development environments.
Production administration.
Corporate file services.

Each application can have its own:

User and group assignments.
Connector group.
Application segments.
Conditional Access policies.
Access lifecycle.

Per-app access supports least privilege because a user can be granted access to one private application without automatically receiving access to other resources on the network.

Quick Access and Per-App Access Comparison

Feature	Quick Access	Per-App Access
Scope	Broad group of private resources	Specific application or application segment
Primary use	VPN transition and broad private access	Granular Zero Trust access
Policy separation	More limited	Stronger policy separation
Typical configuration	FQDNs, IP addresses, and ranges	Enterprise application segments
Least-privilege alignment	Moderate	Strong
Recommended long-term approach	Use selectively	Prefer where practical

4. Traffic Forwarding Profiles

Traffic forwarding profiles determine which traffic is captured and sent through Global Secure Access.

The Private Access traffic forwarding profile identifies traffic destined for configured private resources. Traffic is forwarded only when it matches the configured private access destinations.

The traffic-forwarding process evaluates traffic against the applicable profiles. Traffic that does not match the configured profiles is not automatically forwarded through Global Secure Access.

For Microsoft Entra Private Access, the administrator must configure both:

The private resources that should be accessed.
The Private Access traffic forwarding profile.

Enabling the Private Access profile alone does not grant access to every private resource. The destinations must also be configured through Quick Access or a Global Secure Access application, and the appropriate users or groups must be assigned.

5. Prerequisites

Before implementing Microsoft Entra Private Access, verify the following requirements.

Licensing

The Private Access profile requires:

Microsoft Entra ID P1 or P2.
Microsoft Entra Private Access or Microsoft Entra Suite.

The exact licensing requirements should be verified before deployment because licensing and feature availability can change.

Administrative Roles

Depending on the operation, administrators may require roles such as:

Global Secure Access Administrator.
Application Administrator.
Security Administrator.
Global Administrator for certain initial registration tasks.

Use the least-privileged administrative role that supports the required operation. Privileged Identity Management can be used to provide temporary elevation for administrative tasks.

End-User Device

The user device must:

Run a supported operating system.
Have the Global Secure Access client installed.
Have internet connectivity.
Be appropriately registered or joined to Microsoft Entra ID, depending on the deployment scenario.
Be assigned to the relevant traffic profile or application.

Connector Server

The connector server must:

Run a supported version of Windows Server.
Be able to make outbound connections to the required Microsoft service endpoints.
Allow outbound traffic over the required ports, commonly ports 80 and 443.
Resolve the private resource’s DNS name.
Reach the private resource through the internal network.
Have sufficient capacity for expected traffic.
Be monitored and maintained.

Private Resource

The target resource must be reachable from the connector server. If the connector cannot resolve or reach the resource, Microsoft Entra Private Access cannot successfully broker the connection.

6. Configure a Private Network Connector

A Private Network Connector is the bridge between the Global Secure Access service and the private network.

Step 1: Prepare the Connector Server

Select a Windows Server located in a network that can reach the private applications.

The server should have:

Reliable network connectivity.
DNS resolution for internal resources.
Outbound connectivity to Microsoft services.
Appropriate security hardening.
Monitoring and maintenance procedures.

The connector does not need to be placed in a perimeter network solely for security purposes. Because the connector initiates outbound connections, inbound access from the internet is not required.

Step 2: Install the Connector

In the Microsoft Entra admin center:

Open Global Secure Access.
Navigate to the connectors and sensors area.
Download the Private Network Connector.
Install the connector software on the Windows Server.
Register the connector with the tenant.
Verify that the connector appears as active.

The first connector registration may require Global Administrator permissions. Subsequent registrations can generally use more limited administrative roles, depending on the operation.

Step 3: Validate Connector Diagnostics

Use the connector diagnostics tools to verify:

Outbound connectivity.
Required service endpoint access.
DNS resolution.
Connector registration.
Connectivity to private resources.
Connector health.

A connector can appear registered while still being unable to reach the target application. Therefore, registration status alone is not sufficient validation.

7. Use Connector Groups for Segmentation and High Availability

Every connector belongs to a connector group. Connectors in the same group operate together for load balancing and high availability.

A connector group can be associated with specific applications or environments.

Examples include:

North America connector group.
Europe connector group.
Production connector group.
Development connector group.
Corporate data center connector group.
Azure-hosted application connector group.

Use connector groups to:

Keep traffic close to the target resources.
Separate production and nonproduction applications.
Improve application segmentation.
Simplify troubleshooting.
Reduce latency.
Provide redundancy.

Microsoft recommends using at least two connectors in a group for high availability. If one connector becomes unavailable, another connector in the group can continue serving the application.

Example

An organization has two internal applications:

A production finance application in the primary data center.
A development application in a separate network.

The organization can create:

A production connector group containing two connectors that can reach the finance application.
A development connector group containing two connectors that can reach the development application.

The production application is then associated only with the production connector group. This reduces the risk of routing production traffic through an inappropriate connector.

8. Configure Quick Access

Quick Access is appropriate when an organization needs to provide access to a broad set of internal resources.

A typical Quick Access implementation includes:

Configure a private network connector.
Create or select a connector group.
Define private FQDNs, IP addresses, and ranges.
Assign users and groups.
Link Conditional Access policies.
Enable the Private Access traffic forwarding profile.
Install and configure the Global Secure Access client.
Test access from an assigned device.

Quick Access should be configured carefully. Broad IP ranges can unintentionally provide access to more resources than intended.

Example

An organization wants remote employees to access:

intranet.contoso.com
files.contoso.com
10.20.10.0/24

The administrator can define these destinations in Quick Access. However, the administrator should confirm that the subnet does not contain sensitive systems that should require separate authorization.

9. Configure Per-App Access

Per-app access provides a more granular alternative to broad Quick Access configuration.

Step 1: Create a Connector Group

Create a connector group containing connectors that can reach the target application.

Step 2: Create a Global Secure Access Enterprise Application

Create an enterprise application representing the private application.

Step 3: Configure Application Segments

Define the application’s private destinations, such as:

FQDNs.
IP addresses.
Ports.
Protocols.
Application-specific network segments.

The exact application segment options depend on the supported Private Access configuration.

Step 4: Assign Users and Groups

Assign only the users and groups that require access.

Avoid assigning all users by default unless broad access is explicitly required and approved.

Step 5: Configure Conditional Access

Apply policies that can require:

Multifactor authentication.
Compliant devices.
Approved client applications, where supported.
Specific user or group conditions.
Sign-in risk controls.
Location or network conditions.
Authentication strength.

Step 6: Enable Private Access and Test

Enable the Private Access traffic forwarding profile, install the Global Secure Access client, and verify that assigned users can access the application while unauthorized users cannot.

Per-app access allows network requests to be routed to the configured application segment without providing unrestricted access to other resources on the private network.

10. Configure Conditional Access

Conditional Access is a major security control for Microsoft Entra Private Access.

A Conditional Access policy can require users to satisfy conditions before accessing a private application.

Common requirements include:

Require multifactor authentication.
Require a compliant device.
Block access from risky sign-ins.
Restrict access to specific user groups.
Require an approved authentication strength.
Block legacy authentication scenarios.
Apply different policies to different private applications.

Example Policy

A company publishes an internal payroll application through Microsoft Entra Private Access.

The company creates a Conditional Access policy that:

Targets the payroll enterprise application.
Includes the payroll department group.
Requires multifactor authentication.
Requires a compliant device.
Blocks access when the sign-in risk is high.

This approach is more secure than allowing anyone connected to the corporate VPN to access the payroll application.

Important Distinction

Microsoft Entra Private Access provides network access to configured resources, but the application itself may still require its own authentication and authorization.

Private Access does not eliminate the need for:

Application-level permissions.
Database permissions.
File-system permissions.
Operating system security.
Resource-specific authorization.

Network access and application authorization are separate security layers.

11. Configure the Global Secure Access Client

After the administrator configures the service, the client must be installed on user devices.

The deployment process generally includes:

Install the Global Secure Access client.
Sign in with the user’s Microsoft Entra account.
Confirm that the device is registered or joined as required.
Verify that the user is assigned to the Private Access profile or application.
Confirm that the client is running.
Test access to a configured private resource.

The client forwards traffic only for destinations included in the applicable Private Access configuration. It does not automatically send all network traffic through Private Access.

12. Configure Private DNS

Private Access relies on correct name resolution when applications are accessed by FQDN.

For example, if an application is published as:

hrapp.contoso.com

the connector server must be able to resolve that name to the correct private IP address.

Verify:

The connector server uses the correct DNS servers.
Internal DNS zones are available.
Split-brain DNS is configured correctly, if used.
The FQDN in the application segment exactly matches the destination used by the client.
The resolved IP address is reachable from the connector server.

A common troubleshooting mistake is to verify DNS from the administrator’s workstation while failing to verify DNS from the connector server. The connector’s DNS resolution is what matters for the connection to the private resource.

13. Security Best Practices

Use Least Privilege

Assign access to specific users and groups rather than granting broad access to all users.

Prefer per-app access when the organization needs granular authorization.

Use Conditional Access

Require MFA and compliant devices for sensitive applications. Consider stronger authentication requirements for administrative resources.

Use Separate Connector Groups

Separate production, development, and geographically distinct resources into different connector groups.

Deploy Multiple Connectors

Use at least two connectors in each connector group to reduce the risk of service interruption.

Avoid Overly Broad Address Ranges

Do not publish an entire subnet if users only need access to one application.

Broad ranges can unintentionally expose unrelated systems.

Harden Connector Servers

Apply:

Security updates.
Endpoint protection.
Administrative access restrictions.
Monitoring.
Backup and recovery procedures.
Least-privilege local administration.

Monitor Access and Connector Health

Review:

Connector status.
Authentication events.
Application access.
Conditional Access results.
Failed connections.
DNS failures.
Network connectivity.
Unexpected access patterns.

Use PIM for Administrative Roles

Use Microsoft Entra Privileged Identity Management to provide just-in-time administrative access where appropriate. This reduces standing privilege for administrators.

Treat Private Access as One Security Layer

Private Access should be combined with:

Application authentication.
Resource authorization.
Network segmentation.
Endpoint security.
Data protection.
Logging and monitoring.

14. Troubleshooting Microsoft Entra Private Access

Problem: The Client Is Installed but Traffic Is Not Forwarded

Check:

Whether the Private Access profile is enabled.
Whether the user or group is assigned.
Whether the client is signed in.
Whether the destination matches a configured FQDN or IP address.
Whether the client is running the expected version.
Whether the device is properly registered.

Problem: The Connector Is Offline

Check:

Windows Server availability.
Connector service status.
Outbound ports 80 and 443.
Firewall and proxy configuration.
Required Microsoft service endpoints.
Connector diagnostics.
Server resource utilization.

Problem: The Connector Is Online but the Application Is Unreachable

Check:

DNS resolution from the connector server.
Routing from the connector server to the private resource.
Firewall rules.
Application listening ports.
Network security groups, if the resource is in Azure.
Whether the application is associated with the correct connector group.

Problem: Users Receive Access Denied

Check:

User and group assignments.
Conditional Access policies.
Device compliance status.
MFA requirements.
Application segment configuration.
Whether the user is using the correct Microsoft Entra account.

Problem: Only Some Applications Work

This may indicate:

An incomplete application segment.
Incorrect FQDNs or IP addresses.
Missing ports or protocols.
Different DNS behavior between applications.
The application is associated with the wrong connector group.
The connector can reach one application but not another.

Problem: The Application Works by IP Address but Not by Name

This usually indicates a DNS or name-matching issue.

Verify:

The FQDN is correctly configured.
The connector server can resolve the FQDN.
The application uses the same name configured in Private Access.
Internal DNS records are correct.

15. Common SC-500 Exam Traps

Trap 1: Enabling the Profile Grants Access to Everything

Incorrect. Enabling the Private Access traffic forwarding profile does not automatically grant access to every private resource. The destinations must be configured and the users must be assigned.

Trap 2: Private Access Requires Inbound Ports

Incorrect. Private Network Connectors initiate outbound connections to the Microsoft service. Inbound internet access to the connector is not required.

Trap 3: Quick Access Is Always the Best Long-Term Design

Incorrect. Quick Access is useful for broad access and VPN transition scenarios, but per-app access generally provides stronger segmentation and least-privilege control.

Trap 4: Connector Registration Guarantees Application Connectivity

Incorrect. The connector must also be able to resolve and reach the private resource.

Trap 5: Private Access Replaces Application Authorization

Incorrect. Private Access provides network access. The application, operating system, database, and file system may still enforce their own permissions.

Trap 6: One Connector Is Sufficient for Production

Incorrect. Use multiple connectors in a connector group for high availability.

Trap 7: All Private Traffic Is Automatically Forwarded

Incorrect. Traffic must match the configured Private Access destinations and applicable forwarding policies.

Trap 8: A Private Application Should Always Use the Default Connector Group

Incorrect. Dedicated connector groups can improve segmentation, routing, performance, and troubleshooting.

Practice Exam Questions

Question 1

An organization wants remote employees to access several internal applications without connecting to a traditional VPN. The organization wants access decisions to be based on Microsoft Entra users, groups, and Conditional Access policies.

Which solution should the organization implement?

A. Azure ExpressRoute only
B. Azure Bastion
C. Microsoft Entra Private Access with the Global Secure Access client
D. Azure Firewall without private application configuration

Correct answer: C

Explanation: Microsoft Entra Private Access provides identity-centric access to private resources through the Global Secure Access client and private network connectors. Azure Bastion is primarily used for secure management access to Azure virtual machines, while ExpressRoute and Azure Firewall do not independently provide this application access model.

Question 2

A security engineer is configuring Microsoft Entra Private Access. The engineer has enabled the Private Access traffic forwarding profile but users still cannot access an internal application.

What should the engineer configure next?

A. A public IP address for the internal application
B. A Quick Access configuration or Global Secure Access application containing the private destination
C. An inbound internet rule to the connector server
D. An Azure VPN gateway in every user’s network

Correct answer: B

Explanation: Enabling the traffic forwarding profile alone does not identify which private resources should be routed through Private Access. The administrator must configure the destination through Quick Access or a Global Secure Access application and assign the appropriate users or groups.

Question 3

An organization has two internal applications. One is hosted in the production data center, and the other is hosted in a development network. The security team wants to prevent the development connector from being used to access production applications.

What should the organization configure?

A. One connector group containing every connector
B. A separate Conditional Access policy for the Global Secure Access client only
C. Separate connector groups associated with the appropriate applications
D. A public load balancer for each application

Correct answer: C

Explanation: Connector groups allow administrators to associate applications with specific connectors. Separate groups can improve segmentation and help ensure that production applications use only connectors that can appropriately reach the production network.

Question 4

A company wants to provide access to one internal finance application but does not want users to access other systems on the same subnet.

Which configuration best supports this requirement?

A. Add the entire subnet to Quick Access
B. Assign all employees to the Private Access profile
C. Publish the entire data center through one connector group
D. Create a dedicated Global Secure Access application with a specific application segment

Correct answer: D

Explanation: Per-app access allows the organization to define a specific private application segment rather than granting broad subnet access. This supports least privilege and application-level segmentation.

Question 5

A Private Network Connector is registered and appears online. However, users cannot connect to an internal website through Microsoft Entra Private Access.

What should be checked first on the connector server?

A. Whether the connector server can resolve and reach the internal website
B. Whether the user has an Azure subscription
C. Whether the website has a public IP address
D. Whether the user has an Azure VPN Gateway

Correct answer: A

Explanation: The connector server must be able to resolve the private resource’s DNS name and reach the resource over the internal network. A registered connector can still be unable to access a specific application.

Question 6

An organization wants to require multifactor authentication and device compliance before users can access a private payroll application.

Which control should be used?

A. Conditional Access applied to the private application
B. A public network security group rule
C. A DNS forwarding rule
D. A connector server local firewall rule only

Correct answer: A

Explanation: Conditional Access can require MFA, compliant devices, and other conditions before access to the private application is permitted. Network and firewall rules alone do not provide identity-aware access decisions.

Question 7

An organization is deploying Microsoft Entra Private Access for a business-critical application. The organization wants the application to remain available if one connector server fails.

What should the organization do?

A. Install the connector on the user’s workstation
B. Publish the application through a public IP address
C. Use only Quick Access
D. Deploy multiple connectors in the same connector group

Correct answer: D

Explanation: Connectors in the same connector group provide load balancing and high availability. Deploying multiple connectors reduces the risk that a single connector failure will interrupt application access.

Question 8

Users can access an internal application by IP address but cannot access it by its fully qualified domain name.

What is the most likely issue?

A. The user must be assigned to Azure Firewall
B. The connector server cannot correctly resolve the application’s DNS name
C. The application requires an Azure VPN gateway
D. The Global Secure Access client only supports public DNS names

Correct answer: B

Explanation: When access works by IP address but not by name, DNS resolution or FQDN configuration is a likely cause. The connector server must be able to resolve the configured FQDN to the correct private address.

Question 9

An organization is beginning a VPN replacement project and needs to provide access to a broad set of internal resources while it develops a more granular Zero Trust design.

Which configuration is most appropriate as an initial transition?

A. Quick Access
B. Azure Bastion
C. Azure DDoS Protection
D. Microsoft Defender for Storage

Correct answer: A

Explanation: Quick Access can define a broad set of private FQDNs, IP addresses, and ranges. It is useful as a transition stage, although per-app access should be considered for more granular long-term segmentation.

Question 10

A security engineer wants to ensure that users assigned to Microsoft Entra Private Access cannot automatically access every application on the internal network.

Which statement is correct?

A. Private Access always grants full subnet access
B. The Global Secure Access client automatically bypasses Conditional Access
C. Private Access can route only configured destinations, and access still depends on assignments and policies
D. Private Access disables application-level authentication

Correct answer: C

Explanation: Microsoft Entra Private Access is destination-aware and identity-aware. Users must be assigned to the relevant profile or application, and Conditional Access policies can further restrict access. Private Access does not eliminate application-level authentication or authorization.

Key Takeaways

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

Microsoft Entra Private Access provides identity-centric access to private resources without requiring a traditional VPN.
The Global Secure Access client runs on user devices and forwards traffic for configured private destinations.
Private Network Connectors are installed inside the private network and initiate outbound connections.
Quick Access provides broad private resource access and is useful during VPN transition.
Per-app access provides more granular, least-privilege segmentation.
Connector groups support application association, geographic placement, segmentation, load balancing, and high availability.
Enabling the Private Access profile alone does not grant access to private resources.
Conditional Access can require MFA, compliant devices, and other access conditions.
The connector server must be able to resolve and reach the private resource.
Private Access provides network access but does not replace application-level authorization.
Multiple connectors should be deployed for production availability.
Avoid publishing unnecessarily broad IP ranges or subnets.

Go to the SC-500 Exam Prep Hub main page

azure, Microsoft Certification, SC-500, security October 10, 2026October 10, 2026

Configure Azure private endpoints to secure access to Azure platform as a service (PaaS) resources (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 storage, databases, and networking (25–30%)
   --> Implement security for Azure network services
      --> Configure Azure private endpoints to secure access to Azure platform as a service (PaaS) resources

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 platform as a service (PaaS) resources—such as Azure Storage, Azure SQL Database, Azure Key Vault, Azure Cosmos DB, Azure App Service, and Azure Container Registry—are commonly accessible through public endpoints by default.

A private endpoint allows an Azure resource to be accessed through a private IP address within an Azure virtual network. The connection uses Azure Private Link, allowing traffic between the virtual network and the supported PaaS resource to remain on the Microsoft backbone rather than traversing the public internet.

Private endpoints are an important component of a defense-in-depth and Zero Trust architecture because they can:

Remove public network exposure from supported PaaS resources.
Provide private IP-based access to specific resource instances.
Support access from Azure virtual networks.
Support access from on-premises networks through VPN or ExpressRoute connectivity.
Work with private DNS zones.
Integrate with network security groups and application security groups when private endpoint network policies are enabled.
Help enforce least-privilege network access.
Reduce the attack surface of data and application services.

However, creating a private endpoint does not automatically disable public access to the target resource. Public network access must be disabled separately, or the resource’s firewall and network access rules must be configured to prevent unwanted public connectivity.

1. What Is an Azure Private Endpoint?

An Azure private endpoint is a network interface deployed into a subnet in an Azure virtual network. The network interface receives a private IP address from the virtual network’s address space.

The private endpoint connects that private IP address to a specific Azure resource through Azure Private Link.

For example:

			
Application VM
10.10.1.4
     |
     | Private IP connection
     |
Private Endpoint
10.10.2.5
     |
     | Azure Private Link
     |
Azure Storage Account

		

From the application’s perspective, the PaaS resource is accessed through a private IP address. The resource does not need to expose its public endpoint to the application.

A private endpoint is associated with a particular resource instance. For example, a private endpoint can connect to:

One storage account.
One Azure SQL logical server or database resource.
One Key Vault.
One Azure Cosmos DB account.
One App Service application.
One Azure Container Registry.

This resource-specific association is important for security because a private endpoint does not automatically provide access to every resource of the same service type.

2. Understanding Azure Private Link

Azure Private Link is the underlying Azure technology that enables private connectivity to supported services.

Private Link can be used with:

Azure PaaS services.
Azure-hosted customer services.
Partner services.
Services published through Azure Private Link Service.

For a consumer connecting to an Azure PaaS service, the main components are:

Azure virtual network.
Private endpoint.
Private IP address.
Private DNS configuration.
Target PaaS resource.
Appropriate resource-level network access settings.

The private endpoint is the consumer-side interface. Private Link provides the private connectivity between that interface and the service.

Important distinction

A private endpoint and a private link service are not the same thing:

Component	Purpose
Private endpoint	Provides private access to a supported service from a virtual network
Azure Private Link	Technology that enables private connectivity
Private Link Service	Allows an organization or partner to publish its own service privately
Private DNS zone	Resolves the service name to the private endpoint IP address

For the SC-500 exam, when the requirement is to privately access Azure Storage, Azure SQL, Key Vault, or another supported PaaS service, the expected solution is generally a private endpoint.

3. Private Endpoints Versus Service Endpoints

Azure provides both private endpoints and virtual network service endpoints. They solve related but different problems.

Private Endpoint

A private endpoint:

Uses a private IP address from the virtual network.
Connects to a specific resource instance.
Uses Azure Private Link.
Supports private DNS integration.
Can be used to access supported PaaS resources privately.
Is generally preferred when private access and reduced public exposure are required.

Service Endpoint

A service endpoint:

Extends a virtual network subnet’s identity to supported Azure services.
Routes traffic over the Azure backbone.
Usually continues to access the service through its public service endpoint.
Allows the service firewall to restrict access to selected virtual networks or subnets.
Does not place a private IP address for the service inside the virtual network.

Microsoft recommends private endpoints when supported and when private service access is required. Service endpoints remain useful in scenarios where subnet-based service restrictions are sufficient or where private endpoints are not available.

Comparison

Feature	Private Endpoint	Service Endpoint
Service IP seen by client	Private IP address	Public service IP
Uses Private Link	Yes	No
Connects to a specific resource	Yes	Depends on service access rules
Private DNS integration	Yes	Usually not required
Public network exposure	Can be disabled	Usually remains part of service architecture
Resource-level isolation	Strong	More dependent on service firewall rules
Typical use	Private access to a specific PaaS resource	Restrict service access to selected subnets

4. Why Private Endpoints Improve Security

4.1 Reduce Public Exposure

A private endpoint allows clients to access a PaaS resource without using its public network path.

After confirming private connectivity, administrators can disable public network access on the target resource. This ensures that clients must use the private endpoint rather than bypassing it through the public endpoint.

4.2 Limit Access to a Specific Resource

A private endpoint maps to a specific resource instance. It does not automatically provide access to all storage accounts, SQL databases, or Key Vaults in the subscription.

This helps reduce the risk of unintended cross-resource access and data exfiltration.

4.3 Support Network Segmentation

Private endpoints can be placed in dedicated subnets or application-specific subnets. Organizations can separate:

Production resources.
Development resources.
Sensitive data services.
Shared services.
Regional deployments.
Business-unit resources.

4.4 Support Hybrid Connectivity

On-premises clients can access private endpoints when the on-premises network is connected to Azure through:

Site-to-site VPN.
ExpressRoute.
Appropriate virtual network routing.
Correct DNS forwarding.

Private endpoints do not automatically make a service reachable from on-premises. The network must have both:

A route to the private endpoint IP address.
DNS resolution that returns the private endpoint IP address.

4.5 Support Defense in Depth

Private endpoints should be combined with:

Microsoft Entra authentication.
Azure RBAC.
Resource-specific permissions.
Network security groups.
Azure Firewall.
Private DNS.
Azure Policy.
Microsoft Defender for Cloud.
Logging and monitoring.

A private endpoint controls the network path. It does not replace identity authorization or application-level permissions.

5. Private Endpoint Network Architecture

A common architecture is a hub-and-spoke design.

			
On-premises Network
        |
 VPN or ExpressRoute
        |
   Hub Virtual Network
        |
   Private DNS Resolver
        |
   Spoke Virtual Network
        |
   Private Endpoint Subnet
        |
   Private Endpoint
        |
 Azure PaaS Resource

		

The private endpoint can be deployed in:

A workload virtual network.
A centralized connectivity virtual network.
A dedicated private endpoint virtual network.
A hub or spoke architecture, depending on the organization’s design.

When using a centralized private endpoint model, ensure that:

Workload virtual networks can route to the private endpoint.
DNS zones are linked to the appropriate virtual networks.
Network security policies allow the required traffic.
The design does not create unnecessary transitive routing complexity.
Ownership and access approvals are clearly defined.

6. Plan the Private Endpoint Deployment

Before creating a private endpoint, identify the following.

Target Resource

Determine the exact PaaS resource that should be accessed privately.

Examples:

Specific storage account.
Specific Azure SQL server.
Specific Key Vault.
Specific App Service application.
Specific Azure Container Registry.

Do not assume that creating a private endpoint for one resource secures every resource of that service type.

Target Subresource

Some Azure services expose multiple subresources. For example, a storage account can have separate private endpoint connections for services such as:

Blob.
File.
Queue.
Table.
Data Lake Storage.
Web.

The correct subresource must be selected during private endpoint creation.

Virtual Network and Subnet

Select the virtual network and subnet where the private endpoint network interface will be deployed.

The subnet must have sufficient available IP addresses. Each private endpoint consumes an IP address from the subnet.

DNS Strategy

Determine how clients will resolve the PaaS resource’s normal FQDN to the private endpoint IP address.

Possible approaches include:

Azure Private DNS zones.
Custom DNS servers.
Azure DNS Private Resolver.
Conditional forwarding from on-premises DNS.
A centralized DNS architecture.

Public Access Requirement

Determine whether public network access should remain enabled.

For sensitive workloads, the preferred design is generally:

Create and validate the private endpoint.
Confirm that private DNS and routing work.
Restrict or disable public network access.
Confirm that public access is blocked.

7. Create an Azure Private Endpoint

A private endpoint can be created through the Azure portal, Azure CLI, PowerShell, or infrastructure as code.

Portal-Based Process

The general portal process is:

Open the target PaaS resource.
Navigate to its networking or private endpoint configuration.
Select Private endpoint connections or Private endpoints.
Select Create.
Choose the subscription and resource group.
Provide a private endpoint name.
Select the target region.
Select the target resource.
Select the appropriate target subresource.
Choose the virtual network and subnet.
Configure private DNS integration.
Review the configuration.
Create the private endpoint.
Approve the connection if approval is required.
Test connectivity.

The exact portal labels vary by Azure service.

Important Configuration Choices

During creation, pay particular attention to:

Subscription.
Resource group.
Region.
Target resource.
Target subresource.
Virtual network.
Subnet.
Private endpoint network policies.
Private DNS zone integration.
Connection approval state.

8. Private Endpoint Connection Approval

A private endpoint connection may require approval by the resource owner.

This is especially important when:

The private endpoint is created by a different team.
The consumer and provider are in different subscriptions.
The consumer and provider are in different tenants.
The target service is owned by another organization.
A partner service is being consumed.

The target resource owner can:

Approve the connection.
Reject the connection.
Disconnect an existing connection.
Review the requester and connection details.

A private endpoint that is still pending approval may exist in the virtual network but cannot provide usable access until the connection is approved.

Exam point

Creating a private endpoint and approving a private endpoint connection are separate operations.

9. Configure Private DNS

Private DNS is one of the most important parts of a successful private endpoint deployment.

Without correct DNS configuration, a client may continue resolving the PaaS resource’s public endpoint instead of the private endpoint’s IP address.

Example

A storage account might normally be accessed using a name such as:

storageaccount.blob.core.windows.net

With a private endpoint, the name-resolution process uses a private DNS zone such as:

privatelink.blob.core.windows.net

The private DNS zone contains an A record that maps the private endpoint name to its private IP address.

Common Private DNS Zones

Azure service	Common private DNS zone
Azure Blob Storage	`privatelink.blob.core.windows.net`
Azure Files	`privatelink.file.core.windows.net`
Azure SQL Database	`privatelink.database.windows.net`
Azure Key Vault	`privatelink.vaultcore.azure.net`
Azure Container Registry	`privatelink.azurecr.io`
Azure Cosmos DB SQL API	`privatelink.documents.azure.com`
Azure App Service	`privatelink.azurewebsites.net`

The exact zone depends on the service and subresource.

Recommended Azure DNS Integration

For many Azure-only deployments:

Create the private endpoint.
Select integration with an Azure Private DNS zone.
Create or select the appropriate private DNS zone.
Link the zone to the virtual network.
Allow the private endpoint’s DNS record to be created.

This allows Azure resources in the linked virtual network to resolve the PaaS FQDN to the private endpoint IP address.

DNS Zone Links

A private DNS zone must be linked to each virtual network that needs to resolve records in that zone.

For example:

			
Private DNS Zone
privatelink.blob.core.windows.net
        |
        +--- Link to spoke VNet
        |
        +--- Link to hub VNet
        |
        +--- Link to management VNet

		

A virtual network link does not automatically make the zone available to every virtual network in the tenant. Each required virtual network must be configured appropriately.

10. Hybrid DNS with Azure DNS Private Resolver

In a hybrid environment, on-premises clients may need to resolve Azure private endpoint names.

A common design uses Azure DNS Private Resolver.

Inbound Endpoint

An inbound endpoint allows on-premises DNS servers to send queries into Azure DNS Private Resolver.

The on-premises DNS server can be configured with a conditional forwarder for the relevant private DNS zones.

Outbound Endpoint

An outbound endpoint allows Azure workloads to forward DNS queries to:

On-premises DNS servers.
Other cloud DNS servers.
External DNS resolvers.

Forwarding rulesets determine which DNS suffixes are forwarded and where the queries are sent.

Example

			
On-premises Client
        |
On-premises DNS
        |
Conditional Forwarder
        |
Azure DNS Private Resolver
        |
Private DNS Zone
        |
Private Endpoint IP

		

The DNS resolver requires dedicated subnets for its inbound and outbound endpoints. These subnets cannot be used for unrelated resources.

11. Configure Network Policies for Private Endpoint Subnets

By default, network policies are disabled for private endpoints in a subnet. This behavior allows private endpoint traffic to function without standard subnet network policy processing.

Azure supports enabling network policies for private endpoints so that network security groups and related controls can be applied to private endpoint traffic.

This is useful when an organization needs to:

Restrict which subnets can communicate with private endpoints.
Apply inbound and outbound network rules.
Use application security groups.
Enforce additional segmentation.

Microsoft recommends enabling network security group support on private endpoint subnets when the organization requires network-level filtering.

Important distinction

A private endpoint does not automatically bypass every network security control. The behavior of network policies must be understood and configured deliberately.

When troubleshooting, verify:

Whether private endpoint network policies are enabled.
Whether the relevant NSG is associated with the subnet.
Whether the NSG allows the required traffic.
Whether an application security group is being used.
Whether Azure Firewall or another security appliance is affecting the route.

12. Use Application Security Groups

Application security groups, or ASGs, allow administrators to group network interfaces logically.

ASGs can simplify NSG rules by allowing rules to reference application groups instead of individual IP addresses.

For example:

asg-private-endpoints-production
asg-application-servers
asg-data-services

An NSG rule could allow application servers to communicate with the production private endpoint group while denying access from unrelated subnets.

This is easier to maintain than creating individual rules for every private endpoint IP address.

13. Disable Public Network Access

Creating a private endpoint does not necessarily disable the target service’s public endpoint.

For example, an Azure Storage account may have both:

A private endpoint.
A publicly accessible endpoint.

If public network access remains enabled, users or applications might bypass the private endpoint.

A secure deployment should generally follow this sequence:

Create the private endpoint.
Configure private DNS.
Validate access from the intended virtual network.
Validate access from on-premises if applicable.
Disable public network access or restrict it with service firewall rules.
Confirm that public access is denied.
Confirm that private access still works.

The exact public access setting depends on the target PaaS service. Some services expose a setting such as Public network access: Disabled, while others use firewall or networking configuration options.

Exam trap

The statement “The resource is secure because it has a private endpoint” is incomplete.

The correct security design usually requires both:

Private endpoint connectivity.
Public access restriction or disablement.

14. Private Endpoints and Identity-Based Access

Private endpoints control the network path, not the identity permissions.

For example, a user may be able to reach an Azure Storage account through its private endpoint but still be denied access because the user lacks:

Azure RBAC permissions.
A storage data-plane role.
A valid access token.
Appropriate database permissions.
Key Vault permissions.
Application authorization.

A complete security design combines private networking with identity controls.

Example

An application uses managed identity to access a Key Vault through a private endpoint.

The configuration requires:

The application can resolve the Key Vault FQDN to the private endpoint IP.
The application can route to the private endpoint.
Public access to the Key Vault is restricted or disabled.
The application’s managed identity has the required Key Vault data-plane permissions.
The application uses the correct authentication method.

A private endpoint alone does not grant the managed identity permission to read secrets.

15. Private Endpoints and Azure Firewall

Azure Firewall can be used as part of a centralized network security architecture.

Depending on the routing design, traffic to private endpoints can be inspected or controlled by Azure Firewall. However, administrators must carefully design:

User-defined routes.
Firewall routing.
DNS proxy behavior.
Private DNS resolution.
Network rules.
Application rules.
Return paths.

Do not assume that deploying a private endpoint automatically sends traffic through Azure Firewall.

Similarly, do not assume that all private endpoint traffic should be forced through a firewall. The appropriate design depends on the organization’s security, inspection, performance, and routing requirements.

16. Use Azure Policy to Govern Private Endpoints

Azure Policy can help enforce consistent private connectivity.

Possible governance requirements include:

Require private endpoints for selected PaaS services.
Audit resources that do not have private endpoints.
Deploy private endpoints where supported.
Deny public network access for selected services.
Require approved private DNS configurations.
Restrict private endpoints to approved virtual networks.
Require resource tags on private endpoints.
Restrict deployment to approved regions.

For example, an organization might require all production storage accounts to:

Use a private endpoint.
Disable public network access.
Use approved private DNS zones.
Be deployed in approved virtual networks.

Azure Policy should complement, not replace, the actual service configuration and connectivity testing.

17. Use Infrastructure as Code

Private endpoint deployments should be managed through infrastructure as code when possible.

An infrastructure-as-code definition should include:

Private endpoint.
Target resource ID.
Target subresource.
Virtual network.
Subnet.
Private DNS zone.
Virtual network link.
NSG rules.
Route tables.
Public network access setting.
Required tags.
Connection approval requirements.

Infrastructure as code helps provide:

Repeatability.
Version control.
Consistent security settings.
Easier disaster recovery.
Change tracking.
Reduced configuration drift.

Private DNS records and network security rules should be treated as part of the private endpoint deployment rather than as optional afterthoughts.

18. Monitor Private Endpoint Security

Monitor the following areas:

Private Endpoint Connection State

Review whether the connection is:

Pending.
Approved.
Rejected.
Disconnected.

DNS Resolution

Verify that clients resolve the PaaS FQDN to the private endpoint IP address.

Network Connectivity

Test:

Routing.
TCP connectivity.
Required service ports.
NSG rules.
Firewall rules.
Return traffic.

Resource-Level Logs

Review logs for the target PaaS service, such as:

Storage diagnostic logs.
SQL auditing.
Key Vault logging.
App Service logs.
Container Registry logs.

Azure Activity Log

Use the Azure Activity Log to identify changes to:

Private endpoints.
Private endpoint connections.
Network interfaces.
DNS zones.
Public network access settings.
Firewall rules.
NSGs.

Defender for Cloud

Microsoft Defender for Cloud can help identify security recommendations related to network exposure, configuration weaknesses, and protection of supported resources.

19. Troubleshooting Private Endpoint Connectivity

Problem: The Client Resolves the Public IP

Possible causes include:

The private DNS zone is missing.
The private DNS zone is not linked to the client’s virtual network.
The client uses custom DNS servers that do not forward private DNS queries correctly.
The FQDN is incorrect.
The private DNS record was not created.
The client is outside the network where private DNS resolution is available.

Problem: The Private Endpoint Is Pending

Check:

Whether the target resource owner must approve the connection.
Whether the request was created in the correct subscription or tenant.
Whether the connection request was rejected.
Whether the requester has permission to create the connection.

Problem: DNS Works but the Connection Fails

Check:

The private endpoint’s private IP address.
Routing from the client to the private endpoint.
NSGs.
User-defined routes.
Azure Firewall rules.
Network virtual appliances.
Service-specific firewall settings.
Required ports and protocols.

Problem: Private Access Works but Public Access Also Works

This usually means public network access remains enabled.

Review the target service’s networking configuration and disable public access or restrict it according to the organization’s security requirements.

Problem: The Application Can Reach the Endpoint but Receives Access Denied

This may be an identity or authorization issue rather than a networking issue.

Check:

Microsoft Entra authentication.
Azure RBAC assignments.
Data-plane permissions.
Managed identity configuration.
Application credentials.
Service-specific authorization settings.

Problem: On-Premises Clients Cannot Resolve the Private Name

Check:

VPN or ExpressRoute connectivity.
On-premises DNS conditional forwarders.
Azure DNS Private Resolver inbound endpoint.
Private DNS zone links.
Firewall rules for DNS traffic.
Whether the on-premises DNS server forwards the correct zone.

20. Common SC-500 Exam Traps

Trap 1: A Private Endpoint Automatically Disables Public Access

Incorrect. Public network access usually must be disabled or restricted separately.

Trap 2: Private Endpoints Use Public IP Addresses

Incorrect. A private endpoint receives a private IP address from the selected virtual network subnet.

Trap 3: A Private Endpoint Provides Access to Every Resource in the Subscription

Incorrect. A private endpoint is associated with a specific target resource and, where applicable, a specific subresource.

Trap 4: Private DNS Is Optional for FQDN-Based Access

Incorrect. Without correct DNS resolution, clients may resolve the public endpoint instead of the private endpoint.

Trap 5: Private Endpoint Access Grants Data Permissions

Incorrect. Identity and data-plane permissions are still required.

Trap 6: Service Endpoints and Private Endpoints Are Identical

Incorrect. Service endpoints secure access using subnet identity and service firewall rules, while private endpoints provide a private IP address through Private Link.

Trap 7: Creating a Private Endpoint Automatically Makes It Available to On-Premises Clients

Incorrect. On-premises access also requires routing and DNS resolution.

Trap 8: A Pending Private Endpoint Connection Is Ready for Use

Incorrect. The connection may require approval by the target resource owner.

Trap 9: Private Endpoint Subnets Always Ignore Network Security Groups

Incorrect. Network policies can be enabled for private endpoint subnets when network filtering is required.

Trap 10: Private Endpoints Replace All Other Security Controls

Incorrect. Private endpoints should be combined with identity, authorization, firewall, NSG, logging, policy, and monitoring controls.

Practice Exam Questions

Question 1

An organization wants an Azure Storage account to be accessible from an application subnet using a private IP address. The organization also wants traffic to avoid the public internet.

Which solution should be implemented?

A. Azure Private Endpoint
B. Public IP address with an NSG
C. Azure service tag only
D. Azure Bastion

Correct answer: A

Explanation: An Azure private endpoint provides a private IP address in the virtual network and connects the application to the Storage account through Azure Private Link.

Question 2

A private endpoint has been created for an Azure SQL Database server. Applications still resolve the server’s normal FQDN to a public IP address.

What should the administrator configure?

A. A public load balancer
B. An Azure VPN gateway
C. The appropriate private DNS zone and virtual network link
D. A new SQL firewall rule allowing all IP addresses

Correct answer: C

Explanation: Private DNS configuration allows the normal service FQDN to resolve to the private endpoint IP address. The private DNS zone must be linked to the virtual network used by the clients.

Question 3

A company creates a private endpoint for a production Key Vault but wants to ensure that users cannot bypass the private endpoint by connecting through the public endpoint.

What should the company do after validating private connectivity?

A. Enable a public IP address on the Key Vault
B. Disable or restrict public network access to the Key Vault
C. Remove the private DNS zone
D. Add the Key Vault to a public subnet

Correct answer: B

Explanation: A private endpoint does not automatically disable public network access. The target service must be configured to block or restrict public access.

Question 4

An administrator needs to allow an on-premises application to access an Azure Storage account through a private endpoint.

Which two components are required in addition to the private endpoint? Choose two.

A. A route from the on-premises network to the private endpoint
B. A public IP address assigned to the storage account
C. DNS resolution from on-premises to the private endpoint IP address
D. Azure Bastion deployed in the storage account’s subnet

Correct answers: A and C

Explanation: On-premises clients require network connectivity, such as VPN or ExpressRoute, and DNS resolution that maps the service FQDN to the private endpoint’s private IP address.

Question 5

An organization wants to restrict access to a specific storage account rather than allow a subnet to access all storage resources permitted by a service firewall rule.

Which solution provides the most resource-specific private access?

A. A service endpoint
B. A private endpoint
C. A network security group only
D. A public IP restriction

Correct answer: B

Explanation: A private endpoint connects to a specific resource instance. A service endpoint generally uses subnet identity and service firewall rules and does not provide the same private IP-based resource connection.

Question 6

A private endpoint connection remains in a Pending state. The private endpoint was created successfully, but the application cannot access the target resource.

What is the most likely next action?

A. Approve the private endpoint connection on the target resource
B. Delete the virtual network
C. Enable public access for all networks
D. Remove the target resource’s firewall

Correct answer: A

Explanation: Some private endpoint connections require approval by the owner of the target resource. A pending connection is not ready for normal use.

Question 7

A security team wants to apply NSG rules to private endpoint traffic. By default, private endpoint network policies are disabled on the subnet.

What should the team do?

A. Move the private endpoint to a public IP subnet
B. Enable the appropriate private endpoint network policies and configure the NSG
C. Replace the private endpoint with Azure Bastion
D. Disable all routing between the application and private endpoint

Correct answer: B

Explanation: Private endpoint network policies can be enabled when the organization needs NSG-based filtering for private endpoint traffic.

Question 8

An application can resolve the private endpoint IP address and establish a network connection, but Azure Storage returns an authorization error.

What is the most likely cause?

A. The private DNS zone is missing
B. The private endpoint has no private IP address
C. The application lacks the required storage data-plane permissions
D. The virtual network has no public IP address

Correct answer: C

Explanation: Private endpoint connectivity does not grant data access. The application identity must have the appropriate Azure RBAC or storage data-plane permissions.

Question 9

An organization wants to centralize DNS resolution for private endpoints across multiple spoke virtual networks and on-premises networks.

Which service is most appropriate for hybrid DNS forwarding?

A. Azure DNS Private Resolver
B. Azure Bastion
C. Azure DDoS Protection
D. Azure Load Balancer

Correct answer: A

Explanation: Azure DNS Private Resolver supports inbound and outbound DNS endpoints and can centralize DNS forwarding between Azure and on-premises networks.

Question 10

A company wants to require all production storage accounts to use private connectivity and prevent public network access.

Which governance approach is most appropriate?

A. Require users to manually check each storage account
B. Use Azure Policy to audit or enforce private endpoint and public network access requirements
C. Deploy Azure Bastion to every storage account
D. Use a public IP address allowlist without private endpoints

Correct answer: B

Explanation: Azure Policy can provide consistent governance by auditing or enforcing private endpoint deployment and public network access settings across subscriptions or management groups.

Key Takeaways

For the SC-500 exam, remember these principles:

A private endpoint provides a private IP address inside an Azure virtual network.
Azure Private Link enables private connectivity to supported PaaS resources.
Private endpoints connect to specific resource instances.
Private DNS is essential for resolving normal service FQDNs to private endpoint IP addresses.
Public network access must usually be disabled or restricted separately.
Private endpoint approval may be required.
On-premises access requires both routing and DNS resolution.
Private endpoints do not grant identity or data-plane permissions.
Service endpoints and private endpoints are different technologies.
Network policies can be enabled for private endpoint subnets when NSG filtering is required.
Azure DNS Private Resolver supports hybrid DNS scenarios.
Azure Policy can help enforce private connectivity and public access requirements.
Private endpoints should be combined with identity, authorization, firewall, NSG, monitoring, and governance controls.

Go to the SC-500 Exam Prep Hub main page

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

Configure Azure Private Link services to secure access to network resources (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 storage, databases, and networking (25–30%)
   --> Implement security for Azure network services
      --> Configure Azure Private Link services to secure access to network resources

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

This topic belongs to the Secure storage, databases, and networking section of the SC-500 exam, under Implement security for Azure network services.

The focus is on configuring Azure Private Link services so that consumers can access privately hosted applications or network resources without exposing those resources through a public endpoint.

What is Azure Private Link?

Azure Private Link provides private connectivity between a consumer’s virtual network and a service. Traffic travels through Azure’s private network rather than across the public internet.

Private Link supports two related scenarios:

Private endpoints allow consumers to privately access supported Azure platform as a service (PaaS) resources.
Private Link services allow service providers to publish their own applications or services privately to consumers.

A private endpoint is created in the consumer’s virtual network. It receives a private IP address from that virtual network and connects to a specific resource or Private Link service.

A Private Link service is created by the service provider and exposes an application running behind an Azure Standard Load Balancer. Consumers then create private endpoints in their own virtual networks to connect to that service.

What is an Azure Private Link service?

An Azure Private Link service is the provider-side component of Azure Private Link.

It enables an organization to publish an application or network service running in its own virtual network so that authorized consumers can access it privately from their own virtual networks.

For example, a company might operate a custom payment-processing application behind an internal Standard Load Balancer. Rather than requiring business partners to connect through a public IP address, the company can publish the application through a Private Link service.

The partners create private endpoints in their own virtual networks. Their applications then connect to the private endpoint’s IP address, while Azure privately transports the traffic to the provider’s service.

A Private Link service:

Is associated with an Azure Standard Load Balancer.
Uses a selected frontend IP configuration of that load balancer.
Provides a private connectivity path for consumers.
Can be accessed by private endpoints in different virtual networks.
Can support consumers from different subscriptions or Microsoft Entra tenants.
Allows the service provider to approve or reject connection requests.
Uses provider-side NAT IP addresses for traffic arriving at the service.

Private Link service architecture

A typical architecture contains the following components:

Provider virtual network
Contains the application or network resource being published.
Backend application or service
Runs on virtual machines, virtual machine scale sets, or other supported network resources.
Azure Standard Load Balancer
Distributes traffic to the backend application.
Private Link service
References the Standard Load Balancer frontend IP configuration.
Consumer virtual network
Contains the private endpoint used by the consumer application.
Private endpoint
Provides a private IP address in the consumer’s virtual network.
Private DNS configuration
Allows applications to resolve the service name to the private endpoint’s IP address when name-based access is required.

The simplified traffic flow is:

			
Consumer application
        |
        v
Private endpoint
(private IP in consumer VNet)
        |
        v
Azure Private Link
        |
        v
Provider Private Link service
        |
        v
Standard Load Balancer
        |
        v
Backend application

		

The consumer does not need direct network-level access to the provider’s virtual network. The private endpoint provides the connection boundary between the consumer and the published service.

Important distinction: Private Link service versus private endpoint

These terms are closely related but serve different roles.

Component	Primary purpose	Managed by
Private Link service	Publishes a provider-owned service for private access	Service provider
Private endpoint	Provides private access to a Private Link service or supported Azure resource	Service consumer
Standard Load Balancer	Fronts and distributes traffic to the provider application	Service provider
Private DNS zone	Resolves service names to private endpoint IP addresses	Usually consumer or central network team

A common exam mistake is to assume that a Private Link service itself is the private IP address used by consumers. The consumer actually connects to the private endpoint, which has a private IP address in the consumer’s virtual network.

Requirements for an Azure Private Link service

For the standard Private Link service deployment model, the provider must have:

An application or service running in an Azure virtual network.
An Azure Standard Load Balancer.
A frontend IP configuration on that load balancer.
A subnet from which the Private Link service can obtain NAT IP addresses.
Appropriate permissions to create and manage the Private Link service.
A connection approval process for consumer requests.

Azure Private Link service is supported with Standard Load Balancer, not Basic Load Balancer. The standard load balancer backend pool must use network interfaces rather than IP-address-based backend configuration. Private Link service also supports IPv4 and TCP/UDP traffic in the standard deployment model.

How traffic is processed

When a consumer connects to a Private Link service:

The consumer application connects to the private endpoint.
The private endpoint forwards the traffic through Azure Private Link.
The traffic reaches the provider’s Private Link service.
The Private Link service performs destination-side NAT.
The traffic is delivered to the selected frontend IP configuration of the Standard Load Balancer.
The load balancer distributes the traffic to a healthy backend resource.

The provider normally sees incoming consumer traffic as originating from the Private Link service’s configured NAT IP address pool.

This is important because the provider should not assume that the original consumer IP address will always be visible to the backend application. If the application needs additional connection information, the provider may need to configure and process TCP Proxy Protocol version 2, where supported.

Configure an Azure Private Link service

Step 1: Prepare the provider application

The application must be reachable through an Azure Standard Load Balancer.

The provider should:

Deploy the application in a virtual network.
Create or identify the backend pool.
Configure a health probe.
Configure a load-balancing rule.
Select the frontend IP configuration that will receive Private Link traffic.
Confirm that the application is listening on the required port and protocol.

The load balancer frontend selected for the Private Link service is the entry point for traffic destined for the published service.

Step 2: Prepare the NAT subnet

A Private Link service requires a subnet for its NAT IP configurations.

The NAT IP addresses are used when traffic from consumers reaches the provider’s service. Microsoft recommends planning sufficient address capacity, with at least eight NAT IP addresses available in the subnet as a general recommendation for scalability.

The NAT subnet must be configured appropriately for Private Link service use. In particular, the subnet’s privateLinkServiceNetworkPolicies setting must be disabled for the subnet used by the Private Link service NAT configuration.

A dedicated subnet is not strictly required, but using a dedicated subnet can simplify:

Network security group management.
IP address planning.
Monitoring.
Troubleshooting.
Separation of provider networking components.

Step 3: Create the Private Link service

In the Azure portal, the general process is:

Search for Private link services.
Select Create.
Select the subscription and resource group.
Specify the region.
Select the Standard Load Balancer.
Select the load balancer frontend IP configuration.
Select the source NAT subnet.
Configure the required NAT IP settings.
Configure access security and approval settings.
Review and create the Private Link service.

The Private Link service must be deployed in the same region as the provider virtual network and Standard Load Balancer.

After creation, Azure provides an alias for the Private Link service. The provider can share this alias with consumers so that they can create private endpoints without requiring direct access to the provider’s subscription or resource hierarchy.

Private Link service aliases

A Private Link service receives a globally unique alias.

The alias can be shared with consumers who need to establish a connection. Consumers can use the alias or the resource ID when creating a private endpoint.

Using an alias is especially useful when:

The consumer is in another subscription.
The consumer is in another Microsoft Entra tenant.
The provider does not want to grant the consumer broad access to the provider’s Azure resources.
The service is offered to multiple customers or business partners.

The alias identifies the published Private Link service, but it does not automatically authorize every connection. The provider still controls connection visibility, approval, and access policies.

Control access to a Private Link service

A Private Link service provides private connectivity, but the provider must still control who can connect.

Connection approval

When a consumer creates a private endpoint connection, the provider can:

Approve the request.
Reject the request.
Leave the request pending until it is reviewed.

Manual approval is useful when the service is exposed to external organizations or cross-tenant consumers.

The provider should validate:

The consumer organization.
The consumer subscription.
The intended application.
The business relationship.
The requested access scope.
The expected network and security requirements.

A pending connection does not mean that the consumer has completed access. The provider must approve the connection before the private endpoint can use the service.

Automatic approval

Private Link service supports an auto-approval list based on subscriptions.

Subscriptions included in the auto-approval list can have their private endpoint connections approved automatically.

Automatic approval should be used carefully. It is appropriate only when the provider trusts the listed subscriptions and has a reliable process for managing the list.

For external consumers, manual approval is generally safer because it prevents an unexpected subscription from automatically connecting to the service.

Visibility settings

The provider can control which subscriptions are allowed to request connections.

This helps limit the exposure of the Private Link service and prevents arbitrary consumers from requesting access.

Visibility and auto-approval are different:

Visibility controls who can discover or request access.
Auto-approval controls which requests are approved automatically.
Connection approval determines whether a specific connection is allowed.

Private Link service and cross-tenant access

A Private Link service can be consumed by private endpoints in:

Different virtual networks.
Different subscriptions.
Different resource groups.
Different Microsoft Entra tenants.

This makes Private Link useful for:

Business-to-business applications.
Managed service providers.
SaaS platforms.
Shared services.
Centralized application platforms.
Partner integrations.

Cross-tenant connectivity should be governed carefully. The provider should use restricted visibility, explicit approval, least-privilege administrative roles, and clear ownership of DNS and network configuration.

Private Link does not eliminate the need for application authentication and authorization. A consumer that can connect to the service must still be authorized by the application itself.

DNS considerations

Private Link connectivity and DNS name resolution are separate concerns.

A consumer application may connect to a private endpoint by IP address, but most applications use a fully qualified domain name. The DNS name must resolve to the correct private endpoint IP address.

For Azure PaaS private endpoints, this is commonly handled through Azure Private DNS zones. For a custom Private Link service, the provider and consumer must agree on how the service name will resolve.

A typical DNS design may include:

A private DNS zone.
An A record that maps the service name to the private endpoint IP address.
A virtual network link to the consumer VNet.
DNS forwarding for on-premises or hybrid clients.

In hub-and-spoke or hybrid environments, Azure Private DNS Resolver can help forward DNS queries between on-premises networks and Azure without requiring custom DNS forwarder virtual machines.

DNS troubleshooting example

Suppose an application connects to:

orders.contoso.com

If the name resolves to a public IP address, the application may bypass the intended private endpoint.

The expected behavior is:

			
orders.contoso.com
        |
        v
Private endpoint IP address
        |
        v
Private Link service

		

Useful validation commands include:

nslookup orders.contoso.com

or:

dig orders.contoso.com

The result should be checked from the actual client network, not only from an administrator’s workstation.

Network security controls

Private Link is a network isolation mechanism, but it should be combined with other security controls.

Network security groups

Network security group support for private endpoint subnets is disabled by default. If the organization needs NSG rules to apply to private endpoint traffic, network policies must be enabled for the subnet.

NSGs can be used to restrict:

Which client subnets can reach the private endpoint.
Which ports are allowed.
Which protocols are allowed.
Which application security groups can communicate with the endpoint.

When NSG support is enabled, verify that the rules do not unintentionally block required Private Link traffic.

Application security groups can simplify NSG management by grouping private endpoints according to application or security function.

Route tables and firewalls

Private Link traffic should be tested with the organization’s routing and inspection architecture.

Depending on the design, the organization may use:

Network security groups.
Azure Firewall.
Network virtual appliances.
User-defined routes.
Azure Monitor.
Flow logs or equivalent network diagnostics.

Do not assume that all traffic will automatically traverse a centralized firewall. Private Link is a private connectivity service, and its traffic behavior must be evaluated against the organization’s routing and inspection requirements.

Disable public exposure where appropriate

Private Link provides a private access path, but it does not automatically disable public access to the provider application.

If the application should be accessible only through Private Link, the provider should:

Remove unnecessary public IP addresses.
Restrict public inbound access.
Configure the application firewall appropriately.
Use NSGs and load balancer rules to limit traffic.
Validate private connectivity.
Disable public network access where the service supports that setting.

For supported Azure PaaS resources, Microsoft recommends disabling public network access after private connectivity has been validated.

For a custom application behind a load balancer, the provider must secure the load balancer and backend application separately. Creating a Private Link service does not automatically secure every other path to the application.

Private Link does not replace identity security

A private connection does not automatically mean that the caller is trusted.

The application should still use appropriate authentication and authorization, such as:

Microsoft Entra authentication.
Managed identities.
Mutual TLS, where appropriate.
Application tokens.
Role-based authorization.
API keys or certificates when required by the application.
Tenant or customer-level authorization.

For example, a partner may successfully connect to a private endpoint but still be denied by the application because the partner does not have permission to access a particular API or dataset.

Private Link provides network-level privacy. It does not replace application-level access control.

Private Link does not replace encryption

Private Link keeps traffic on Azure’s private network path, but it does not automatically guarantee that the application protocol is encrypted.

The provider should still use:

HTTPS for web applications.
TLS for database connections.
Secure application protocols.
Valid certificates.
Strong cipher suites.
Appropriate certificate rotation procedures.

Private Link does not change the underlying encryption behavior of the application or service.

Monitoring and governance

Private Link services should be governed like other sensitive network resources.

Recommended controls include:

Azure Policy to audit or enforce Private Link configurations.
Resource locks to prevent accidental deletion.
Activity logs for creation, modification, approval, and deletion.
Monitoring of private endpoint connection states.
Monitoring of Standard Load Balancer health.
Monitoring of backend application availability.
Documentation of approved consumers.
Periodic review of visibility and auto-approval settings.
Alerts for unexpected connection requests.
Infrastructure-as-code deployment for repeatability.

A Private Link service can be deleted only after its associated private endpoint connections have been handled. Before deletion, the provider should reject or remove active connections and verify that dependent consumers have been notified.

Common configuration problems

The Private Link service cannot be created

Possible causes include:

The load balancer is a Basic Load Balancer.
The load balancer backend pool uses unsupported IP-based configuration.
The load balancer and Private Link service are in different regions.
The NAT subnet has incorrect network policy settings.
The selected frontend IP configuration is invalid.
The administrator lacks required permissions.

The consumer cannot connect

Check the following:

The private endpoint connection has been approved.
The private endpoint is in a connected state.
The consumer subnet has appropriate routing.
NSG rules allow the required traffic.
The application is listening on the expected port.
The Standard Load Balancer health probe is healthy.
The load-balancing rule points to the correct backend pool.
The provider firewall or application firewall is not blocking the traffic.
The DNS name resolves to the private endpoint IP address.

DNS resolves to a public address

Possible causes include:

The private DNS zone is missing.
The zone is not linked to the consumer VNet.
The client uses an on-premises DNS server that does not forward queries correctly.
The DNS record points to the wrong address.
DNS caching is returning an old result.
The application uses a hostname that is not configured for private resolution.

The backend sees unexpected source IP addresses

Private Link service traffic is normally translated through the provider’s NAT IP configuration.

The backend may therefore see the NAT IP address rather than the original consumer IP address.

If the application needs connection metadata, consider whether TCP Proxy Protocol version 2 is appropriate and supported for the deployment. Ensure that the application and load balancer configuration are compatible with the selected proxy protocol behavior.

Private Link service versus service endpoints

Private Link services and virtual network service endpoints are not the same.

Feature	Private Link service	Service endpoint
Primary purpose	Privately publish a provider-owned service	Secure access from a subnet to supported Azure services
Consumer connection	Private endpoint	Service endpoint on a subnet
Consumer receives private IP for service	Yes, through the private endpoint	No
Supports custom provider applications	Yes, behind Standard Load Balancer	No
Cross-tenant provider publishing	Supported	Not the primary design
Resource-level mapping	Maps to a specific Private Link service	Restricts service access from a subnet
Public exposure	Can provide private access without requiring public access	Service remains a public Azure service endpoint
Typical use	SaaS, partner services, custom applications	Storage, SQL, and other supported Azure services

Service endpoints provide optimized connectivity from a subnet to supported Azure services and allow service-level network restrictions. Private Link is generally preferred when the requirement is to provide a private IP-based connection to a specific resource or service.

Exam-focused facts to remember

A Private Link service is the provider-side component.
A private endpoint is the consumer-side component.
A Private Link service normally requires an Azure Standard Load Balancer.
Basic Load Balancer is not supported.
The Private Link service references a load balancer frontend IP configuration.
Consumer traffic reaches the provider through the Private Link service’s NAT IP configuration.
The provider can approve or reject private endpoint connection requests.
Visibility and auto-approval settings control who can request or automatically receive access.
Private Link can support cross-subscription and cross-tenant consumers.
Private Link does not automatically disable public access.
Private Link does not replace application authentication.
Private Link does not replace TLS or application encryption.
DNS must resolve the application name to the private endpoint’s IP address.
NSG policies for private endpoint subnets are disabled by default.
The Private Link service NAT subnet requires appropriate private link service network policy settings.
A private endpoint connects to a specific published resource or service, not automatically to every resource in the provider’s environment.

Practice Exam Questions

Question 1

An organization hosts a custom application behind an Azure Standard Load Balancer. Business partners must access the application privately from their own virtual networks.

What should the organization create?

A. An Azure service endpoint on the provider subnet
B. An Azure Private Link service associated with the Standard Load Balancer
C. An Azure VPN gateway in the provider virtual network
D. A public load balancer with a public IP address

Answer: B

Explanation: An Azure Private Link service publishes a provider-owned application for private access. The service is associated with a frontend IP configuration of an Azure Standard Load Balancer. Consumers then create private endpoints in their own virtual networks.

Question 2

A company wants to publish an application through Azure Private Link service. The application is currently behind a Basic Load Balancer.

What should the company do?

A. Enable a service endpoint on the Basic Load Balancer
B. Add a public IP address to the Basic Load Balancer
C. Configure Azure Bastion for the application
D. Replace or migrate the Basic Load Balancer to a supported Standard Load Balancer

Answer: D

Explanation: Standard Azure Private Link service deployments require an Azure Standard Load Balancer. Basic Load Balancer is not supported.

Question 3

A consumer creates a private endpoint to connect to a provider’s Private Link service. The private endpoint connection remains in a pending state.

What is the most likely explanation?

A. The provider has not approved the private endpoint connection
B. The consumer must create a public IP address for the private endpoint
C. The provider must configure a service endpoint instead
D. The consumer must disable all NSGs in the provider virtual network

Answer: A

Explanation: Private endpoint connections to a Private Link service may require provider approval. Until the provider approves the request, the connection can remain pending.

Question 4

A Private Link service provider wants only approved subscriptions to be able to connect automatically. Other subscriptions must require manual review.

Which configuration should the provider use?

A. A route table on the provider subnet
B. A network security group on the load balancer
C. Visibility restrictions and an auto-approval subscription list
D. A public IP prefix attached to the consumer VNet

Answer: C

Explanation: Private Link service visibility controls which subscriptions can request access, while the auto-approval list identifies subscriptions whose requests can be approved automatically. Other requests can be reviewed manually.

Question 5

A provider creates a Private Link service and shares its alias with a partner in another Microsoft Entra tenant.

Which statement is correct?

A. The partner can create a private endpoint using the alias, subject to the provider’s connection controls
B. Cross-tenant private endpoints are not supported
C. The provider must give the partner Owner access to the provider subscription
D. The partner must deploy the Private Link service in the provider’s virtual network

Answer: A

Explanation: Private Link service supports consumers from different subscriptions and Microsoft Entra tenants. The provider can share the service alias without granting broad subscription access. The connection remains subject to visibility and approval settings.

Question 6

A provider wants to control traffic reaching private endpoints using network security groups. The private endpoints are located in a subnet where private endpoint network policies are disabled.

What should the provider do?

A. Enable public network access on the Private Link service
B. Replace the private endpoints with service endpoints
C. Add a public IP address to each private endpoint
D. Enable network policies for private endpoints in the subnet

Answer: D

Explanation: Network policies for private endpoints are disabled by default. They must be enabled on the subnet for NSG rules and supported route-table policies to apply to private endpoint traffic.

Question 7

A consumer application connects to a Private Link service by using a DNS name. The name resolves to a public IP address instead of the private endpoint’s IP address.

What should be investigated first?

A. Whether the provider has enabled TCP Proxy Protocol version 2
B. Whether private DNS records and virtual network links are configured correctly
C. Whether the provider has added a second Standard Load Balancer
D. Whether the consumer has configured a public IP prefix

Answer: B

Explanation: Private Link connectivity depends on correct name resolution. The DNS name should resolve to the private endpoint’s private IP address. Missing private DNS zones, missing VNet links, or incorrect hybrid DNS forwarding can cause the name to resolve publicly.

Question 8

Which statement best describes the source address seen by a backend application behind a Private Link service?

A. It is always the original public IP address of the consumer
B. It is always the private IP address of the consumer’s virtual machine
C. It normally appears to originate from the Private Link service’s NAT IP address pool
D. It is always the public IP address of the Standard Load Balancer

Answer: C

Explanation: Private Link service performs destination-side NAT, and consumer traffic normally appears to originate from the NAT IP configuration associated with the Private Link service.

Question 9

An organization creates a Private Link service for a sensitive application. The application is still reachable through another public load balancer frontend.

What is the best security conclusion?

A. Private Link automatically blocks all public access
B. The application is secure because private endpoints always require Microsoft Entra authentication
C. The public frontend is acceptable because Private Link encrypts all application traffic
D. The organization must separately restrict or disable the unnecessary public access path

Answer: D

Explanation: Creating a Private Link service does not automatically remove other access paths. Public load balancer frontends, public IP addresses, firewall rules, and application access controls must be secured separately.

Question 10

A provider wants to ensure that consumers connecting through Private Link are also authorized to use specific application functions.

Which control is required in addition to Private Link?

A. Application-level authentication and authorization
B. A second private endpoint in the provider VNet
C. A service endpoint on the consumer subnet
D. A public IP address for the backend application

Answer: A

Explanation: Private Link provides private network connectivity, but it does not determine whether a caller is authorized to use the application. The application must still enforce authentication and authorization, such as Microsoft Entra authentication, tokens, roles, certificates, or other appropriate controls.

Go to the SC-500 Exam Prep Hub main page