Tag: Cloud Security

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

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

Evaluate effective security rules by using Azure Network Watcher diagnostics (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
      --> Evaluate effective security rules by using Azure Network Watcher diagnostics

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 Network Watcher provides diagnostic tools that help security engineers determine why network traffic is allowed or denied in Azure. For the SC-500 exam, an important capability is evaluating the effective security rules applied to a virtual machine’s network interface and using diagnostic tools to identify the rule responsible for a connectivity decision.

These capabilities are especially useful when a workload cannot connect to another resource, a management connection such as SSH or RDP fails, or an application unexpectedly has access to a network destination.

Azure Network Watcher can evaluate network security group rules and, where applicable, administrative network rules configured through Azure Virtual Network Manager. It can also help distinguish a security-rule problem from a routing, application, or service-availability problem.

What Are Effective Security Rules?

An effective security rule is the combined set of security rules that actually applies to a network interface.

The effective rules can include:

Rules from an NSG associated with the subnet.
Rules from an NSG associated with the network interface.
Default NSG security rules.
Applicable administrative rules configured through Azure Virtual Network Manager.
Both inbound and outbound rules.

The effective rules view is therefore different from looking at only one NSG in isolation. A rule configured on the subnet-level NSG may affect a virtual machine even if the network interface itself has a different NSG.

Example

A virtual machine might have:

A subnet-level NSG allowing TCP port 443.
A network-interface-level NSG denying TCP port 443.
A default outbound rule allowing Internet traffic.

Looking at only the subnet-level NSG would not provide a complete picture. The effective security rules view helps you determine which rules are applied to the selected network interface.

Why Effective Security Rules Matter

Effective security rules are useful for both troubleshooting and security governance.

Troubleshooting

You can use effective security rules to investigate:

Failed SSH or RDP connections.
Blocked application traffic.
Unexpected inbound exposure.
Unexpected outbound Internet access.
Communication failures between virtual machines.
Connectivity problems involving Azure Bastion.
Conflicting rules at the subnet and network-interface levels.

Security auditing

Security teams can compare the effective rules applied to network interfaces against an approved security baseline. This can help identify:

Unintended open ports.
Overly broad source or destination ranges.
Unexpected administrative rules.
Missing deny rules.
Differences between the intended and actual security configuration.

Azure Network Watcher also allows effective security rules to be downloaded as a CSV file, which can support documentation, review, and compliance activities.

Azure Network Watcher Diagnostic Tools

Several Network Watcher capabilities work together when evaluating security rules.

1. IP Flow Verify

IP Flow Verify determines whether a specific packet is allowed or denied by the security rules applied to a virtual machine.

You specify the characteristics of the traffic, including:

Direction: inbound or outbound.
Protocol: TCP or UDP.
Local IP address.
Local port.
Remote IP address.
Remote port.

The tool returns:

Whether access is allowed or denied.
The security rule responsible for the decision.
The NSG containing the rule, when applicable.

For example, you can test whether a source IP address is allowed to connect to a virtual machine over TCP port 3389. If the traffic is denied, IP Flow Verify can identify the rule causing the denial.

Important limitation

IP Flow Verify tests TCP and UDP traffic. It does not test ICMP traffic. To evaluate ICMP-related rules, use NSG diagnostics instead. IP Flow Verify also focuses on rules applied to a virtual machine’s network interface and is not the appropriate tool for testing rules applied to virtual machine scale sets.

Example scenario

A user cannot connect to a VM using RDP.

You can run IP Flow Verify with:

Direction: Inbound.
Protocol: TCP.
Local IP: The VM’s private IP address.
Local port: 3389.
Remote IP: The user’s source IP address.
Remote port: The client’s source port.

If the result is:

Access denied by DenyAllInBound

you know that the traffic is being blocked by the default inbound deny rule because no higher-priority rule allows the connection.

2. Effective Security Rules

The Effective security rules feature displays the aggregated inbound and outbound rules applied to a network interface.

It helps answer questions such as:

Which NSG rules apply to this VM?
Is the rule associated with the subnet or network interface?
Is an administrative rule affecting the traffic?
Which source and destination prefixes are associated with a rule?
Is the traffic allowed by a custom rule or a default rule?

In the Azure portal, effective security rules are grouped into inbound and outbound sections. You can select an individual rule to view additional details, including associated address prefixes.

Azure portal navigation

A typical portal workflow is:

Open the affected virtual machine.
Select Networking or Network settings.
Select the virtual machine’s network interface.
Select Effective security rules.
Review the inbound and outbound rules.
Expand or select rules to inspect their details.

If the virtual machine has multiple network interfaces, select the specific interface involved in the traffic.

Azure CLI

You can retrieve effective NSG information for a network interface by using:

			
az network nic list-effective-nsg \
  --resource-group <resource-group> \
  --name <nic-name>

Azure PowerShell

The equivalent PowerShell command is:

			
Get-AzEffectiveNetworkSecurityGroup `
  -NetworkInterfaceName "<nic-name>" `
  -ResourceGroupName "<resource-group>"

These commands provide the combined view of the rules applied to the network interface, including subnet-level rules, network-interface-level rules, and default rules.

3. NSG Diagnostics

NSG diagnostics checks whether traffic is allowed or denied by the security and administrative rules applied to a virtual machine.

It is useful when you need to evaluate traffic characteristics that may not be covered by IP Flow Verify, including ICMP traffic.

NSG diagnostics can help identify:

The rule allowing the traffic.
The rule denying the traffic.
Whether the decision comes from a custom rule.
Whether the decision comes from a default rule.
Whether the issue is related to inbound or outbound filtering.

Microsoft’s troubleshooting guidance demonstrates using NSG diagnostics to investigate a connection failure involving Azure Bastion and a virtual machine.

4. Connection Troubleshoot

Connection troubleshoot evaluates connectivity between a source and destination. It is broader than simply checking an individual NSG rule.

It can help identify:

Whether the destination is reachable.
Whether a security rule allows or denies the traffic.
Whether a route exists.
The next hop used for the traffic.
Whether the destination VM is running or listening.
Whether the problem is related to routing rather than security filtering.

You can test connectivity from a virtual machine to:

Another virtual machine.
An IP address.
A URI.
An FQDN.
An on-premises destination, depending on the network configuration.

For example, if a VM cannot connect to another VM over TCP port 3389, Connection troubleshoot can show that the traffic is allowed by the NSG but that no valid route exists. This prevents you from incorrectly changing security rules when the actual problem is routing.

Azure CLI example

			
az network watcher test-connectivity \
  --resource-group <resource-group> \
  --source-resource <source-vm> \
  --dest-address <destination-address> \
  --protocol TCP \
  --dest-port 443

		

Connection troubleshoot can also be used with a destination IP address:

			
az network watcher test-connectivity \
  --resource-group <resource-group> \
  --source-resource <source-vm> \
  --dest-address 10.10.10.10 \
  --protocol TCP \
  --dest-port 3389

		

5. Next Hop

Although Next hop does not directly evaluate NSG rules, it is valuable when diagnosing connectivity problems.

Next hop determines how Azure routes traffic from a virtual machine to a specified destination. It reports information such as:

Next-hop type.
Next-hop IP address.
Route table information.

Possible next-hop types include:

Virtual network.
Internet.
Virtual network gateway.
Virtual appliance.
None.

If a security rule allows traffic but the next hop is None, the problem may be a missing route rather than an NSG denial.

How Azure Evaluates NSG Rules

Understanding NSG evaluation is essential when interpreting Network Watcher results.

Inbound traffic

For inbound traffic, Azure evaluates the rules associated with the subnet and network interface.

The effective result depends on the applicable rules and their priorities. A matching rule with a higher priority takes precedence over a matching rule with a lower priority.

Outbound traffic

Outbound traffic is evaluated against outbound rules associated with the network interface and subnet.

A VM may be able to receive traffic from a source but still be unable to initiate outbound traffic if an outbound rule denies it.

Default rules

NSGs include default rules such as:

Allow virtual network inbound.
Allow Azure Load Balancer inbound.
Deny all inbound.
Allow virtual network outbound.
Allow Internet outbound.
Deny all outbound.

Custom rules with priorities from 100 through 4096 are evaluated before the default rules. If no custom rule matches, a default rule may determine the result.

Example

Suppose a VM receives an inbound TCP connection on port 80:

A custom rule allows TCP 80 from a specific source with priority 200.
A default inbound deny rule has lower precedence.

The custom allow rule wins because it matches the traffic and is evaluated before the default deny rule.

If no custom allow rule matches, the default inbound deny rule blocks the traffic.

Effective Rules Versus Configured Rules

The distinction between configured and effective rules is a common exam concept.

Concept	Description
Configured rules	Rules defined in a particular NSG
Effective rules	Combined rules actually applied to a network interface
Subnet-level NSG	Applies to resources within the subnet
NIC-level NSG	Applies to the specific network interface
Default rules	Built-in rules used when no higher-priority custom rule determines the result
Administrative rules	Rules applied through Azure Virtual Network Manager

When troubleshooting, do not inspect only the NSG that appears most obvious. Always inspect the effective rules for the affected network interface.

Recommended Troubleshooting Workflow

Use the following process when a VM or application cannot communicate.

Step 1: Define the exact traffic

Record:

Source VM or source IP.
Destination VM, IP, URI, or FQDN.
Direction.
Protocol.
Destination port.
Source port, if relevant.
Expected result.

A vague test such as “the server cannot connect” is less useful than:

VM-A cannot connect to VM-B over TCP port 443.

Step 2: Run IP Flow Verify

Use IP Flow Verify to determine whether the packet is allowed or denied.

If the result is Access denied, record:

The rule name.
The NSG name.
The direction.
The traffic parameters.

Step 3: Review effective security rules

Inspect the effective inbound or outbound rules on the affected network interface.

Look for:

A custom deny rule.
A missing allow rule.
An unexpected subnet-level rule.
A network-interface-level rule.
A default deny rule.
An administrative rule.

Step 4: Check rule priority

If multiple rules could match the traffic, compare their priorities.

Remember:

Lower numerical priority values are evaluated first.
A rule with priority 100 is evaluated before a rule with priority 500.
A broad deny rule with a higher priority can override a more specific allow rule with a lower priority.

Step 5: Check routing

If the security rules allow the traffic, use:

Next hop to inspect routing.
Connection troubleshoot to test the complete path.

Check for:

Missing routes.
Incorrect user-defined routes.
An unexpected virtual appliance.
Incorrect peering or gateway configuration.
Asymmetric routing.
A destination that is not running.

Step 6: Check the destination service

If the traffic is allowed and the route is correct, verify that:

The destination VM is running.
The application is listening on the expected port.
The operating system firewall allows the traffic.
The service is bound to the correct IP address.
The destination application is healthy.

Network Watcher can identify Azure network filtering and routing issues, but it does not replace application-level troubleshooting.

Step 7: Re-test after changes

After modifying an NSG rule or route:

Run the same diagnostic test again.
Confirm that the decision changed as expected.
Verify that the new rule did not create unintended exposure.
Document the reason for the change.

Common Troubleshooting Scenarios

Scenario 1: RDP is blocked

A user cannot connect to a VM over TCP port 3389.

Possible causes include:

No inbound allow rule for the user’s source IP.
A higher-priority deny rule.
The default DenyAllInBound rule.
An NSG associated with the subnet.
An NSG associated with the NIC.
The VM’s operating system firewall.
RDP not running on the VM.

Use IP Flow Verify first to determine whether Azure NSG rules are blocking the connection.

Scenario 2: Internet access is blocked

A VM cannot access an external website over TCP port 443.

Possible causes include:

An outbound NSG deny rule.
A missing route.
A firewall or virtual appliance.
DNS resolution failure.
The destination website being unavailable.

Use IP Flow Verify for outbound filtering, then use Connection troubleshoot and Next hop to evaluate routing and reachability.

Scenario 3: Traffic is unexpectedly allowed

A VM is accessible from a source that should be blocked.

Review:

Effective inbound rules.
Broad source prefixes such as *.
Rules allowing VirtualNetwork.
Rules allowing Internet.
Administrative rules.
Rule priorities.
NSGs applied at both subnet and NIC levels.

Do not assume that the absence of a custom allow rule means traffic is blocked. Default rules may allow certain traffic.

Scenario 4: Azure Bastion cannot connect to a VM

Azure Bastion requires appropriate connectivity to the target VM. A misconfigured NSG can block the connection.

Review the effective inbound rules on the target VM’s network interface and confirm that the required traffic from the Bastion subnet is allowed. NSG diagnostics can help identify the blocking rule.

Security Best Practices

Use least-privilege rules

Avoid broad rules such as:

Any source to Any destination.
Any protocol.
Any port.
Any Internet source.

Instead, restrict rules by:

Source IP or service tag.
Destination IP or subnet.
Protocol.
Destination port.
Business requirement.

Use explicit rule names

Use descriptive names such as:

Allow-AppSubnet-To-Database-1433
Deny-Internet-To-Management
Allow-BastionSubnet-To-VM-RDP

Clear names make Network Watcher results easier to interpret.

Review effective rules regularly

A subnet-level or NIC-level NSG change may alter the effective security posture of a VM. Periodically review effective rules for sensitive workloads.

Treat default rules as part of the security model

Do not review only custom rules. Default rules can determine whether traffic is allowed or denied.

Use diagnostics before changing rules

Do not immediately create a new allow rule when connectivity fails. First determine:

Whether the traffic is actually denied by an NSG.
Which rule caused the decision.
Whether routing or the destination service is the real problem.

Avoid unnecessary public exposure

If a management connection is required, prefer controlled access methods such as Azure Bastion, private connectivity, or restricted source ranges rather than exposing management ports broadly to the Internet.

Export and document results

Use the effective rules export capability to support:

Security reviews.
Change management.
Compliance evidence.
Troubleshooting records.
Baseline comparisons.

Important Exam Distinctions

IP Flow Verify versus Effective Security Rules

IP Flow Verify answers: “Is this specific packet allowed or denied, and which rule caused the result?”
Effective security rules answers: “What combined rules are applied to this network interface?”

IP Flow Verify versus Connection Troubleshoot

IP Flow Verify focuses on security-rule evaluation.
Connection troubleshoot evaluates the broader connection path, including reachability and routing.

NSG diagnostics versus Next hop

NSG diagnostics evaluates security filtering.
Next hop evaluates routing.

Network Watcher versus the operating system firewall

Network Watcher can identify Azure-level filtering and routing problems. It does not automatically prove that the guest operating system firewall or application is configured correctly.

Configured NSG versus effective NSG

A configured NSG is only one source of rules. Effective rules represent the aggregate configuration that applies to the network interface.

Practice Exam Questions

Question 1

A security engineer must determine whether a specific TCP connection from an external IP address to a virtual machine is allowed or denied by Azure network security rules. Which Network Watcher feature should the engineer use?

A. Next hop
B. Connection troubleshoot
C. IP Flow Verify
D. Traffic Analytics

Answer: C

Explanation: IP Flow Verify evaluates a specific traffic flow using the direction, protocol, local and remote IP addresses, and local and remote ports. It returns whether access is allowed or denied and identifies the applicable security rule.

Question 2

A virtual machine has one NSG associated with its subnet and another NSG associated with its network interface. The security engineer wants to view the complete set of inbound and outbound rules applied to the VM. What should the engineer use?

A. Effective security rules
B. Azure Monitor metrics
C. Next hop
D. Connection monitor

Answer: A

Explanation: Effective security rules display the aggregated rules from the subnet-level NSG, network-interface-level NSG, default rules, and applicable administrative rules.

Question 3

A VM cannot connect to another VM over TCP port 443. IP Flow Verify reports that the traffic is allowed. Which tool should the engineer use next to determine whether the traffic is being routed correctly?

A. Azure Policy
B. Microsoft Defender for Cloud
C. NSG diagnostics
D. Next hop

Answer: D

Explanation: Next hop identifies the route and next-hop type used for traffic to a destination. If the security rules allow the traffic, the next step is to investigate routing.

Question 4

A security engineer runs IP Flow Verify for an inbound TCP connection to port 3389. The result is Access denied by DenyAllInBound. What does this indicate?

A. The VM is powered off.
B. No higher-priority rule allowed the inbound traffic.
C. The destination route is missing.
D. The operating system firewall blocked the connection.

Answer: B

Explanation: DenyAllInBound is a default inbound NSG rule. The result indicates that no applicable custom allow rule matched the traffic before the default deny rule was reached.

Question 5

Which traffic type cannot be tested by IP Flow Verify?

A. ICMP
B. TCP
C. UDP
D. TCP over IPv4

Answer: A

Explanation: IP Flow Verify tests TCP and UDP traffic. It does not test ICMP traffic. NSG diagnostics can be used when ICMP rule evaluation is required.

Question 6

A VM’s effective security rules show that outbound traffic is allowed, but Connection troubleshoot reports that the destination is unreachable and the next-hop type is None. What is the most likely issue?

A. A higher-priority outbound NSG deny rule
B. An invalid DNS record only
C. A missing or incorrect route
D. A missing inbound NSG rule on the destination

Answer: C

Explanation: A next-hop type of None indicates that Azure does not have a valid route to the destination. The issue is routing rather than the outbound NSG decision.

Question 7

A security engineer wants to identify whether an NSG rule associated with the subnet or the network interface is blocking access to a VM. Which approach is most appropriate?

A. Review only the subnet-level NSG.
B. Review only the NIC-level NSG.
C. Review the VM’s public IP configuration.
D. Run IP Flow Verify and inspect the effective security rules.

Answer: D

Explanation: The effective rules view combines the rules applied from both the subnet and network interface. IP Flow Verify can then identify the rule responsible for a specific traffic decision.

Question 8

Which statement correctly describes Azure Network Watcher Connection troubleshoot?

A. It only lists the NSGs associated with a VM.
B. It tests connectivity and can provide information about filtering and routing.
C. It automatically changes a denied NSG rule to allow traffic.
D. It replaces the guest operating system firewall.

Answer: B

Explanation: Connection troubleshoot evaluates the broader connection path. It can identify reachability problems, security-rule decisions, and routing issues, but it does not replace the guest firewall or automatically correct configuration.

Question 9

A custom inbound NSG rule allows TCP port 22 from a trusted administrator IP address with priority 200. Another custom rule denies all inbound TCP traffic with priority 100. What is the result for an SSH connection from the trusted IP address?

A. The allow rule wins because it is more specific.
B. Both rules are evaluated and traffic is allowed.
C. The deny rule wins because it has the higher evaluation priority.
D. The default inbound rule determines the result.

Answer: C

Explanation: Lower numerical priority values are evaluated first. The deny rule with priority 100 is evaluated before the allow rule with priority 200 and therefore blocks the connection.

Question 10

A VM can connect to a destination according to IP Flow Verify, but the application still fails to communicate. Which action should be performed next?

A. Use Connection troubleshoot and verify the route, destination service, and application listener.
B. Delete all NSGs from the VM.
C. Add an allow rule for all Internet traffic.
D. Disable the VM’s operating system firewall permanently.

Answer: A

Explanation: If IP Flow Verify allows the traffic, the problem may involve routing, service availability, the application listener, DNS, or the operating system firewall. Connection troubleshoot and destination-side checks are more appropriate than broadly weakening security controls.

Summary

For the SC-500 exam, remember the following:

Effective security rules show the combined rules applied to a network interface.
Rules can come from subnet-level NSGs, NIC-level NSGs, default rules, and applicable administrative rules.
IP Flow Verify evaluates a specific TCP or UDP flow and identifies the rule allowing or denying it.
NSG diagnostics can evaluate security rules and is useful for scenarios such as ICMP traffic.
Connection troubleshoot evaluates the broader connection path.
Next hop helps identify routing problems.
A denied connection is not always caused by an NSG; routing, the operating system firewall, and the destination application must also be considered.
Lower numerical NSG priorities are evaluated first.
Always inspect effective rules rather than reviewing only one NSG in isolation.
Use diagnostics before modifying security rules to avoid unnecessary or overly broad access.

Go to the SC-500 Exam Prep Hub main page

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

Identify overexposure of data in SharePoint (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 AI
      --> Identify overexposure of data in SharePoint

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

SharePoint is commonly used to store documents, collaboration content, business records, and information accessed by Microsoft 365 Copilot and other AI applications. Although SharePoint permissions determine what users can access, poorly configured permissions and sharing links can expose information to a much broader audience than intended.

For the SC-500 exam, security engineers should understand how to use Microsoft Purview Data Security Posture Management for AI, SharePoint data access governance reports, and related SharePoint controls to identify potentially overshared content and prioritize remediation.

The central security principle is:

AI applications generally respect the permissions of the user making the request. However, if SharePoint content is incorrectly shared with a broad audience, that content may become available to Copilot or other authorized AI experiences through the user’s existing access.

What Is SharePoint Data Overexposure?

Data overexposure occurs when information is accessible to more people, groups, applications, or AI experiences than the organization intended.

Overexposure can result from:

Excessive SharePoint site permissions.
Broad Microsoft 365 group membership.
Broken permission inheritance.
Sharing links that are too permissive.
Files shared with Everyone.
Files or sites shared with Everyone except external users.
Anonymous or “Anyone” links.
Content shared with large internal groups.
Former employees or inappropriate groups retaining access.
Sensitive files stored in broadly accessible collaboration sites.
Inadequate review of site ownership and permissions.

Oversharing does not necessarily mean that a file is publicly available on the Internet. A file shared with Everyone except external users may be accessible to every authenticated user in the organization, which can still represent a significant security risk.

Why SharePoint Overexposure Matters for AI

Microsoft 365 Copilot and other AI experiences can use organizational content that the current user is authorized to access. Copilot does not need a separate permission assignment to every document. Instead, it can use the user’s existing Microsoft 365 permissions.

This creates an important relationship:

A SharePoint file is shared with a broad audience.
A user receives access through that broad permission.
The user asks Copilot a question.
Copilot may use the accessible content when generating a response.

Therefore, an organization may unintentionally expose sensitive information through AI without directly configuring Copilot to share that information.

Examples include:

Human resources documents shared with all employees.
Financial forecasts accessible to a broad department.
Customer records stored in a site with excessive membership.
Legal documents shared through an “Anyone” link.
Executive meeting notes accessible through a large internal group.
Confidential project files inherited from a parent site.

The security issue is usually not that Copilot bypasses SharePoint security. The issue is that the underlying SharePoint permissions are too broad.

Microsoft Purview Data Security Posture Management for AI

Microsoft Purview Data Security Posture Management for AI, often abbreviated as DSPM for AI, helps organizations identify risks involving sensitive data and AI usage.

For SharePoint, DSPM can help security teams:

Discover potentially overshared content.
Identify sites containing sensitive information.
Review sharing links and permission exposure.
Understand how data may be used as AI grounding data.
Prioritize remediation.
Apply sensitivity labels.
Notify site owners.
Remove inappropriate sharing links.
Track and review data exposure over time.

The relevant DSPM capability is the data risk assessment. Microsoft Purview provides default assessments and allows administrators to create custom assessments for selected users or SharePoint sites.

Accessing Data Risk Assessments

A typical workflow is:

Open the Microsoft Purview portal.
Navigate to Data Security Posture Management.
Select Discover.
Open Data risk assessments.
Select the Microsoft 365 assessment area.
Review an existing assessment or create a custom assessment.
Examine potentially overshared sites and items.
Prioritize remediation based on sensitivity and exposure.

The default assessment automatically runs weekly for the top SharePoint sites based on usage. Custom assessments can be used when the organization needs to evaluate particular sites, users, or business areas.

Default and Custom Data Risk Assessments

Default assessments

Default assessments provide a recurring view of oversharing risks in frequently used SharePoint sites.

They are useful for:

Establishing an initial baseline.
Finding high-usage sites with potential exposure.
Identifying sites that should be reviewed before or during Copilot deployment.
Monitoring common oversharing patterns.

The default assessment is not a guarantee that every risky file in the organization has been identified. It focuses on the supported scope of the assessment and its scanning limits.

Custom assessments

Custom assessments allow an administrator to target specific:

SharePoint sites.
Users.
Business units.
Sensitive data locations.
High-risk collaboration areas.

Custom assessments are useful when:

A department is preparing to deploy Copilot.
A site contains regulated information.
A security incident involves a specific location.
A business owner requests a permission review.
A previous assessment identifies a high-risk site.
The organization wants to validate remediation.

After a custom assessment runs, results may take time to become available. Assessment results should therefore not be treated as real-time permission telemetry.

Potentially Overshared Items

For supported Microsoft 365 assessments, Purview can identify items that are potentially overshared based on sharing links for:

External users.
Anonymous users.
Broadly accessible audiences.

The item-level results can show information such as:

The potentially overshared item.
The SharePoint site containing the item.
The item owner.
The applied sensitivity label.
The type of sharing link or exposure identified.

This allows security teams to investigate individual files rather than reviewing every document in a site manually.

Important distinction

A potentially overshared item is not automatically confirmed to be a security incident.

For example:

A public marketing brochure may legitimately use an “Anyone” link.
A confidential financial forecast should not normally use an “Anyone” link.
A project file may be intentionally shared with external partners.
A file may have an overly broad link but contain no sensitive information.

The correct response is to evaluate the item’s business purpose, sensitivity, audience, and sharing method.

SharePoint Data Access Governance Reports

SharePoint provides Data access governance reports that help administrators understand how broadly content is exposed.

These reports are available through the SharePoint admin center and can be used alongside Purview assessments.

Important report categories include:

Site permissions across the organization.
Site permissions for selected users.
Sites and files shared through special SharePoint groups.
Sensitivity labels applied to files.
Sharing links activity.
Content shared with Everyone except external users.

These reports provide a broader governance view than an individual file’s sharing dialog.

Site Permissions Across the Organization

The organization-wide site permissions report provides a snapshot of permission exposure across SharePoint and OneDrive sites.

Useful information can include:

Approximate file count.
Number of items with unique permissions.
Number of “People in your organization” links.
Number of “Anyone” links.
Number of permissions granted to Everyone except external users.
Number of permissions granted to Everyone.
Site sensitivity label information.

This report helps identify sites with:

Large numbers of users.
Many unique permissions.
Extensive use of broad sharing links.
Large amounts of content with weak access boundaries.

A site with many unique permissions may be difficult to govern because access is granted individually at many levels. A site with many broad links may be easier to use but more difficult to secure.

Site Permissions for a Specific User

The site permissions for users report helps determine which sites a particular user can access and how that access is granted.

Access may be granted:

Directly to the user.
Through a SharePoint group.
Through a Microsoft 365 group.
Through another group.
Through site membership.
Through item-level permissions.

This report is useful for questions such as:

Which SharePoint sites can this employee access?
Does the user have access to sensitive sites unrelated to their role?
Is access direct or inherited through a group?
Does a user retain access after changing departments?
Can a privileged or high-risk account access excessive content?

This is especially important when investigating insider-risk concerns, inappropriate access, or the potential impact of a compromised account.

Everyone and Everyone Except External Users

Everyone

The Everyone group represents an extremely broad audience. Depending on the context, content shared with Everyone may be accessible to a very large population.

Files containing confidential information should generally not be shared with Everyone unless the organization has explicitly approved that exposure.

Everyone except external users

The Everyone except external users group, often abbreviated EEEU, includes users inside the organization but excludes external users.

Although this group does not include external guests, it can still expose information to all internal users.

Examples of potentially risky content include:

Employee compensation information.
Internal investigations.
Strategic planning documents.
Security architecture.
Customer information.
Unreleased product plans.
Legal or regulatory material.

The EEEU report identifies sites and files where this group is used as a permission recipient. These permissions may be assigned at different levels, including sites, libraries, folders, and files.

Sites and Files Shared Through Special SharePoint Groups

The special-groups report is useful when the security team needs to identify the exact items affected by permissions granted to:

Everyone.
Everyone except external users.

The report can identify:

The affected site.
The affected file or folder.
The permission level.
The permission hierarchy.
The parent group through which access was granted.

This is more actionable than simply knowing that a site is overshared. It allows administrators to create a targeted cleanup plan or use scripting to address the affected permissions.

Sharing Links That Can Cause Overexposure

SharePoint supports several types of sharing links.

Anyone links

An Anyone link can allow access without requiring the recipient to authenticate with an organizational account.

Depending on the configuration, an Anyone link may allow:

Viewing.
Editing.
Downloading.
Sharing with others.

Anyone links should be carefully controlled because the link may be forwarded beyond the original intended audience.

People in your organization links

A People in your organization link can make content available to authenticated users in the organization.

This may be appropriate for general internal communications but risky for sensitive content.

Specific people links

A Specific people link is more restrictive because it is intended for named recipients.

However, administrators should still review:

Whether the recipients are correct.
Whether the recipients still need access.
Whether the link allows editing.
Whether the content should have a sensitivity label.
Whether the link has been forwarded or replaced.

The presence of a sharing link is not automatically a problem. The security risk depends on the link type, content sensitivity, intended audience, and organizational policy.

Activity Reports

Snapshot reports show the current or baseline state of permissions. Activity reports help identify recent sharing behavior.

Important activity reports include:

Sharing links created recently.
Content shared with Everyone except external users.
Sites with unusually high sharing activity.

Activity reports can help detect emerging risks before they become widespread.

For example, a site may not currently have a large number of overshared files, but a sudden increase in Anyone links could indicate:

A change in business process.
A new collaboration project.
User misunderstanding.
An inappropriate sharing practice.
A compromised account.

Sharing link activity reports focus on recently active sites and can be used with baseline reports to understand both current exposure and recent changes.

Snapshot Reports Versus Activity Reports

Report type	Primary purpose
Snapshot report	Shows the current or baseline permission state
Activity report	Shows recent sharing behavior
Site permissions report	Shows how broadly a site is accessible
User permissions report	Shows which sites a particular user can access
Special-groups report	Identifies specific files and sites shared with Everyone or EEEU
Sharing links report	Identifies sites with recent sharing-link activity
Sensitivity label report	Helps identify how sensitive content is labeled

A mature governance program uses both snapshot and activity reports:

Use snapshot reports to understand the current exposure.
Use activity reports to identify new or increasing risks.
Investigate high-risk sites and files.
Remediate inappropriate access.
Repeat the assessment periodically.

Sensitivity Labels and SharePoint Overexposure

Sensitivity labels help classify and protect content based on its sensitivity.

Examples of classification categories include:

Public.
General.
Confidential.
Highly confidential.

A sensitivity label may provide:

Visual classification.
Encryption.
Access restrictions.
Content marking.
Protection that persists with the file.
Policy-based protection.

Sensitivity labels can help security teams distinguish between:

Content that is intentionally broadly shared.
Content that is sensitive and should have restricted access.
Content that is unlabeled and requires review.

An unlabeled file is not necessarily insecure, but unlabeled sensitive content is harder to govern consistently. Purview assessments can help identify potentially overshared items that are unlabeled or may require a different sensitivity label.

Remediation Options

After identifying overexposure, choose remediation based on:

Sensitivity of the content.
Number of users with access.
Whether external users are involved.
Whether AI applications may use the content.
Business impact.
Whether access is intentional.
Whether the content is still required.

1. Resolve the finding

Use Resolve when the item has been reviewed and the apparent risk is acceptable.

Examples:

The file is an approved public document.
The business owner confirms the sharing is intentional.
The content is not sensitive.
The item has already been remediated outside the assessment.

Resolving a finding does not necessarily change the permissions. It records that the finding has been reviewed.

2. Apply or change a sensitivity label

Apply a sensitivity label when:

The item is unlabeled.
The existing label is too permissive.
The content requires encryption or access restrictions.
The organization needs better classification.

3. Notify the site owner

Site owners often understand the business context better than central security teams.

A notification can request that the owner:

Review the affected item.
Confirm the intended audience.
Remove unnecessary access.
Replace a broad sharing link.
Apply an appropriate sensitivity label.
Move the content to a more restricted site.

4. Remove a sharing link

Removing an inappropriate sharing link prevents that link from being used to access the content.

This action should be used carefully because it may disrupt legitimate collaboration. After removing the link, the owner may need to create a more restrictive link for authorized users.

5. Restrict access temporarily

SharePoint capabilities such as Restricted Access Control can be used to limit access to specified groups while remediation is performed.

This can be useful when:

A site contains highly sensitive information.
Permissions cannot be reviewed immediately.
Copilot exposure must be reduced quickly.
A security investigation is underway.

6. Use restricted content discovery

Restricted content discovery can help prevent high-risk SharePoint sites and files from surfacing in Microsoft Copilot and related agentic experiences while the organization works on remediation.

This is an interim control. It should not replace correcting the underlying permissions and content governance problems.

7. Initiate a site access review

A site access review sends a request to the site owner to review and update access.

A site owner can review:

Users with access.
Groups with access.
Items with broad permissions.
Sharing links.
Items with unusually high exposure.

This approach distributes remediation to the people most familiar with the site’s business purpose.

Recommended Investigation Workflow

Step 1: Identify the site or user at risk

Use:

DSPM data risk assessments.
Site permissions reports.
User permissions reports.
Sharing link activity reports.
EEEU reports.

Step 2: Determine the exposure type

Identify whether access is granted through:

An Anyone link.
A People in your organization link.
A Specific people link.
A SharePoint group.
A Microsoft 365 group.
Everyone.
Everyone except external users.
Direct permissions.
Inherited permissions.

Step 3: Determine the data sensitivity

Review:

Sensitivity labels.
File content.
Business owner.
Regulatory classification.
Customer or employee information.
Intellectual property.
Security or legal information.

Step 4: Determine whether the exposure is intentional

Ask:

Is the audience appropriate?
Is the file still needed?
Is external sharing required?
Is broad internal access justified?
Is the link type appropriate?
Is the access temporary or permanent?

Step 5: Prioritize remediation

A useful priority model is:

Sensitive content shared externally or anonymously.
Sensitive content shared with Everyone.
Sensitive content shared with Everyone except external users.
Sensitive content accessible to large groups.
Unlabeled content with broad access.
Low-risk content with legitimate broad sharing.

Step 6: Apply the least disruptive effective control

Possible actions include:

Remove a broad link.
Replace it with a Specific people link.
Remove unnecessary group membership.
Change site permissions.
Apply a sensitivity label.
Initiate a site access review.
Restrict access temporarily.
Restrict content discovery while remediation is performed.

Step 7: Validate and document

After remediation:

Re-run the assessment or report.
Confirm that access is reduced as intended.
Verify that legitimate users retain access.
Document the business justification.
Record the owner and remediation date.
Monitor for recurrence.

Important Limitations and Considerations

Assessments are not necessarily real-time

Reports and assessments may have processing delays. A newly changed permission may not appear immediately.

Do not assume that a report showing no issue proves that the current configuration is risk-free.

OneDrive and SharePoint coverage can differ

Some item-level scanning capabilities are limited to SharePoint sites. OneDrive support and reporting methods may differ depending on the specific feature and current service capabilities.

Broad access is not always inappropriate

A public brochure, product announcement, or company policy may legitimately be shared broadly.

Security engineers must evaluate the context rather than automatically removing every broad link.

Removing links may disrupt business operations

Removing a sharing link can prevent legitimate recipients from accessing the content. Use owner review and business validation where possible.

Fix permissions, not just AI visibility

Restricted content discovery can reduce the chance that content appears in Copilot or agentic experiences, but the underlying SharePoint permissions should still be corrected.

Common Exam Traps

Trap 1: Copilot bypasses SharePoint permissions

Incorrect. Copilot generally uses the current user’s authorized access. The risk often comes from excessive SharePoint permissions.

Trap 2: Everyone except external users means secure

Incorrect. It excludes external users but may grant access to every internal user.

Trap 3: An Anyone link always indicates a security incident

Incorrect. The link may be intentional for public content. The content’s sensitivity and business purpose must be evaluated.

Trap 4: A site permissions report identifies every affected file

Not necessarily. Site-level reports identify exposure patterns. Item-level reports, such as the special-groups report, are needed to identify specific files and folders affected by certain broad permissions.

Trap 5: Restricted content discovery fixes the permissions

Incorrect. It is an interim control that can reduce AI discovery exposure. The underlying permissions should still be remediated.

Trap 6: A resolved finding automatically removes access

Incorrect. Resolving a finding records that it has been reviewed. It does not necessarily change the item’s permissions.

Trap 7: Activity reports and snapshot reports serve the same purpose

Incorrect. Snapshot reports describe the current or baseline state. Activity reports focus on recent sharing behavior.

Trap 8: Every unlabeled file is insecure

Incorrect. Lack of a sensitivity label is a governance concern, but the actual risk depends on the content and access permissions.

Practice Exam Questions

Question 1

An organization is preparing to deploy Microsoft 365 Copilot. The security team wants to identify SharePoint content that may be accessible to a broader audience than intended. Which capability is most appropriate?

A. Microsoft Defender for Endpoint
B. Microsoft Purview Data Security Posture Management data risk assessments
C. Azure Network Watcher
D. Azure Firewall

Answer: B

Explanation: Purview DSPM data risk assessments help identify potentially overshared Microsoft 365 content, including SharePoint data that may affect AI grounding and Copilot responses.

Question 2

A SharePoint document is shared with Everyone except external users. What is the primary security concern?

A. The document is automatically encrypted with a Microsoft-managed key.
B. Only the site owner can access the document.
C. The document is available only to external guests.
D. The document may be accessible to all authenticated users inside the organization.

Answer: D

Explanation: Everyone except external users excludes external users but can expose the document to the entire internal organization.

Question 3

A security engineer needs to identify the exact files and folders that have permissions granted to Everyone or Everyone except external users. Which report should be used?

A. Sites and files shared via special SharePoint groups report
B. Azure Activity Log
C. Microsoft Defender for Servers report
D. Site collection storage report

Answer: A

Explanation: The special-groups report identifies the specific sites, files, and folders affected by permissions granted to Everyone or Everyone except external users.

Question 4

A security team wants to understand which SharePoint sites a particular employee can access and whether access is direct or inherited through groups. Which report is most appropriate?

A. Sharing links activity report
B. Site permissions for users report
C. Sensitivity labels for files report
D. External attack surface report

Answer: B

Explanation: The site permissions for users report shows the sites a specified user can access and how access is granted.

Question 5

A potentially overshared file is identified in Purview. The file contains confidential financial information and is currently unlabeled. What is an appropriate remediation action?

A. Apply an appropriate sensitivity label and review the sharing permissions.
B. Resolve the finding without reviewing it.
C. Make the file available to Everyone.
D. Disable Microsoft 365 Copilot for the entire tenant.

Answer: A

Explanation: Sensitive unlabeled content should be classified and its permissions reviewed. Applying a sensitivity label can improve protection and governance.

Question 6

A site owner confirms that a file identified by a Purview assessment is an approved public marketing brochure. What should the security engineer do if the sharing is intentional and acceptable?

A. Delete the SharePoint site.
B. Remove all site members.
C. Resolve the finding after documenting the business justification.
D. Apply a highly confidential label automatically.

Answer: C

Explanation: Not every broad sharing configuration is inappropriate. If the exposure is intentional and approved, the finding can be resolved after review.

Question 7

A security team wants to identify newly created sharing links that may introduce oversharing risks. Which capability should it use?

A. Site storage metrics
B. Sharing links activity reports
C. Azure Resource Graph
D. Microsoft Entra Connect Health

Answer: B

Explanation: Sharing links activity reports identify sites with recent sharing-link activity and help detect emerging oversharing risks.

Question 8

An organization discovers that a high-risk SharePoint site may expose sensitive content to Copilot users. The permissions cannot be fully reviewed immediately. Which interim control may help reduce the content’s visibility in Copilot and agentic experiences?

A. Disable all Microsoft Entra users.
B. Delete all sensitivity labels.
C. Enable restricted content discovery for the high-risk content.
D. Remove every NSG from the organization.

Answer: C

Explanation: Restricted content discovery can help prevent high-risk SharePoint content from surfacing in Copilot and related agentic experiences while the organization remediates the underlying access risks.

Question 9

Which statement best describes the difference between a snapshot report and an activity report?

A. A snapshot report shows a permission baseline, while an activity report focuses on recent sharing behavior.
B. A snapshot report only applies to Azure virtual machines, while an activity report applies to SharePoint.
C. A snapshot report changes permissions automatically, while an activity report deletes files.
D. A snapshot report identifies malware, while an activity report identifies vulnerabilities.

Answer: A

Explanation: Snapshot reports describe the current or baseline permission state. Activity reports focus on recent sharing activity that may introduce new exposure.

Question 10

A security engineer removes an inappropriate Anyone sharing link from a sensitive SharePoint file. What should the engineer do next?

A. Assume that all access to the file is now impossible.
B. Validate that authorized users still have appropriate access and confirm that the broad link is no longer usable.
C. Grant Everyone access as a replacement.
D. Disable SharePoint for the entire organization.

Answer: B

Explanation: Removing a sharing link may affect legitimate collaboration. The engineer should validate the resulting access and ensure that authorized users retain an appropriate, more restrictive access method.

Summary

For the SC-500 exam, remember these key points:

SharePoint overexposure occurs when content is accessible to a broader audience than intended.
Copilot generally uses the current user’s existing permissions.
Excessive SharePoint permissions can therefore create AI data exposure risks.
Purview DSPM data risk assessments help identify potentially overshared content.
SharePoint Data access governance reports provide organization-wide, user-specific, item-level, and activity-based visibility.
Everyone except external users can expose content to all internal users.
Anyone links can expose content beyond the organization and should be reviewed carefully.
Snapshot reports show the current or baseline state.
Activity reports identify recent sharing behavior.
Sensitivity labels help classify and protect sensitive content.
Remediation may include changing permissions, removing links, applying labels, notifying site owners, initiating access reviews, or temporarily restricting content discovery.
Restricted content discovery is an interim AI-visibility control, not a replacement for correcting SharePoint permissions.
Always validate the business purpose before removing legitimate access.

Go to the SC-500 Exam Prep Hub main page

AI Governance, AI Security, azure, Microsoft Certification, SC-500, security October 10, 2026

Identify risks related to Microsoft Copilot and AI apps by using Microsoft Purview Data Security Posture Management (DSPM) (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 AI
      --> Identify risks related to Microsoft Copilot and AI apps by using Microsoft Purview Data Security Posture Management (DSPM)

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 focuses on using Microsoft Purview Data Security Posture Management (DSPM) to identify risks associated with Microsoft Copilot and other AI applications.

You should understand how to:

Discover which AI applications are being used.
Identify sensitive information involved in AI interactions.
Detect potential data exposure and oversharing.
Review prompts, responses, and referenced content when permitted.
Use DSPM insights and recommendations to prioritize security controls.
Understand the relationship between DSPM, Microsoft Purview, Microsoft Defender, and Microsoft 365 security controls.

Why AI-related data risks matter

Generative AI applications can make sensitive information easier to discover, summarize, combine, and distribute. A user might ask Copilot to summarize documents, analyze business information, or answer questions using organizational data. If the underlying data is incorrectly shared or insufficiently protected, AI can amplify the exposure by making that information easier to retrieve and use.

Microsoft 365 Copilot is designed to respect existing user permissions. Therefore, many Copilot data-exposure risks are not caused by Copilot bypassing permissions. Instead, they occur because users already have access to information that is too broadly shared, improperly classified, stale, or insufficiently governed.

Microsoft Purview DSPM helps organizations understand these risks by bringing together information about data, users, AI interactions, sensitive information, and existing security controls. It provides analytics, trends, recommendations, and guided actions that help security and compliance teams improve their data security posture.

What is Microsoft Purview DSPM?

Microsoft Purview Data Security Posture Management is a centralized capability for discovering, assessing, and managing data security risks across an organization.

DSPM can help organizations:

Understand where sensitive data exists.
Identify how data is accessed and used.
Detect potential oversharing and exposure.
Identify risky AI interactions.
Review recommendations for improving protection.
Connect findings to Microsoft Purview security and compliance controls.

DSPM for AI provides visibility into AI-related risks, including sensitive data in prompts and responses, risky AI usage, and interactions involving enterprise or third-party AI applications. Microsoft Purview also provides related capabilities through auditing, data classification, sensitivity labels, Data Loss Prevention, Insider Risk Management, and eDiscovery.

Microsoft documentation now distinguishes between the current Data Security Posture Management experience and the earlier DSPM for AI (classic) experience. The current DSPM experience provides broader data-security workflows, while some older one-click policies and documentation may still use the “DSPM for AI” terminology.

Important AI-related risks

1. Overshared data

Oversharing occurs when sensitive information is accessible to more users than necessary.

Examples include:

A confidential SharePoint site accessible to all employees.
A document shared through an “Anyone” link.
A sensitive file available through a broad Microsoft 365 group.
A former project site that still contains confidential information.
A document with unique permissions that were never reviewed.
A file that lacks an appropriate sensitivity label.

When Copilot or an agent can access data through a user’s existing permissions, overshared information may become easier to discover in AI-generated responses. DSPM and related SharePoint governance reports help identify these conditions.

2. Sensitive information in prompts and responses

Users may enter sensitive information into AI applications, such as:

Customer information.
Financial data.
Employee records.
Intellectual property.
Credentials or secrets.
Health-related information.
Legal or regulatory information.
Confidential source code.

Microsoft Purview data classification can use sensitive information types and trainable classifiers to identify sensitive data in AI prompts and responses. These findings can appear in Microsoft Purview reports and Activity Explorer.

3. Risky AI usage

Risky AI usage can include:

Attempted prompt injection.
Attempts to access protected material.
Use of AI to expose confidential information.
Unusual or potentially malicious AI activity.
Inappropriate use of AI applications.
Copying sensitive organizational data into an unapproved AI service.

Microsoft Purview Insider Risk Management can use AI-related signals to help identify potentially risky behavior. For example, the risky AI usage policy template can detect activities such as prompt injection attempts and attempts to access protected materials.

4. Use of unapproved third-party AI applications

Employees may use public AI websites without organizational approval. Examples include consumer versions of ChatGPT, Google Gemini, or other generative AI services.

These applications can create risks when users:

Paste sensitive business information into prompts.
Upload confidential files.
Use organizational data in an application without approved controls.
Circumvent organizational AI policies.
Use an AI service that does not meet organizational compliance requirements.

Microsoft Purview supports visibility into certain third-party AI interactions. Network-based data security capabilities can help audit prompts and responses through supported Secure Access Service Edge or Security Service Edge integrations. The Microsoft Purview browser extension and onboarded devices may also be required for particular discovery and endpoint DLP scenarios.

Microsoft Purview DSPM capabilities for AI

AI activity discovery

DSPM helps organizations understand which AI applications are being used and how users interact with them.

Depending on the application and configuration, organizations may be able to identify:

The AI application involved.
The user or activity associated with an interaction.
The presence of sensitive information.
Risk indicators.
Related prompts and responses.
Referenced files or data sources.
Potentially unethical or inappropriate interactions.

The level of detail available depends on the application, licensing, permissions, collection policies, and supported integration.

Sensitive-data insights

DSPM can use Microsoft Purview classification capabilities to identify sensitive information in AI interactions.

Classification may be based on:

Sensitive information types.
Trainable classifiers.
Existing sensitivity labels.
Other Microsoft Purview classification signals.

These insights help security teams determine whether users are submitting or receiving information that requires additional protection.

Risk assessments and recommendations

DSPM provides data risk assessments and recommendations that help organizations identify security weaknesses and determine appropriate next steps.

Examples of recommendations may include:

Protecting sensitive data with sensitivity labels.
Reviewing overshared SharePoint content.
Capturing AI interactions for investigation or compliance.
Creating DLP policies.
Creating Insider Risk Management policies.
Reviewing risky users or activities.
Restricting access to sensitive content.

DSPM is not simply a reporting dashboard. Its purpose is to help transform data-discovery findings into practical security and compliance actions.

How to access DSPM

The current Microsoft Purview experience provides DSPM functionality through the Microsoft Purview portal.

A typical workflow is:

Sign in to the Microsoft Purview portal.
Open Data Security Posture Management.
Review the available security objectives, dashboards, assessments, and recommendations.
Select the relevant AI or data-risk area.
Review the affected applications, users, data, or activities.
Drill into details using available reports or Activity Explorer.
Apply or configure the recommended security controls.

Some older documentation refers to:

Microsoft Purview portal → Solutions → DSPM for AI (classic)

The exact navigation and available capabilities may vary as Microsoft transitions functionality from the classic experience to the current DSPM experience.

Recommended setup tasks

Before DSPM can provide meaningful insights, several prerequisites and setup tasks may be required.

Activate Microsoft Purview Audit

Auditing provides visibility into activities that occur in supported Microsoft services and applications. In many new tenants, auditing is already enabled, but administrators should verify that it is available and configured appropriately.

Configure AI interaction collection

Some AI investigations require collection policies to capture prompts and responses.

For example, Microsoft Purview provides one-click policies for capturing interactions from supported Copilot experiences and enterprise AI applications. These policies allow the interactions to be analyzed by supported Purview solutions such as DSPM, eDiscovery, Data Lifecycle Management, and compliance workflows.

Configure sensitive-data discovery

Organizations can extend insights into sensitive data shared with AI applications by configuring the appropriate data-classification and network-based discovery capabilities.

Onboard devices when required

Device onboarding may be required for scenarios such as:

Discovering sensitive information shared with third-party AI sites.
Applying endpoint DLP policies.
Detecting users who paste sensitive information into public AI applications.

Configure sensitivity labels

Sensitivity labels help classify and protect files, emails, and other supported content. Labels can provide protection even when content is moved or downloaded, depending on the configured label settings.

Configure pay-as-you-go billing when required

Some DSPM and AI-related data storage or processing capabilities require pay-as-you-go billing. The applicable requirements depend on the specific feature and configuration.

Reviewing AI risk dashboards

DSPM for AI can provide reports and dashboards that help security teams identify patterns such as:

Total AI interactions over time.
Sensitive interactions by AI application.
Risky AI usage.
Potentially unethical interactions.
Insider Risk severity.
AI applications associated with sensitive data.
Activities involving protected material.

Security teams can select View details or similar drill-down options to inspect individual activities in Activity Explorer. The ability to view prompts, responses, and referenced files is controlled by Microsoft Purview permissions and role groups. For example, viewing content details may require membership in an appropriate Content Explorer or related role group.

Why activity-level investigation matters

A dashboard may show that sensitive AI interactions are increasing, but it may not explain:

Which application is involved.
Which users are involved.
What type of sensitive data was used.
Whether the activity was accidental or intentional.
Whether a policy violation occurred.
Which control should be applied.

Activity-level investigation provides the context needed to determine whether the issue requires:

User education.
A sensitivity label.
A DLP policy.
An Insider Risk Management policy.
Access remediation.
An investigation.
A change to the approved AI application list.

Relationship between DSPM and other Microsoft Purview capabilities

DSPM is not a replacement for all other security and compliance solutions. It provides visibility and recommendations while working with other Microsoft Purview capabilities.

Capability	Primary purpose in AI risk management
DSPM	Discover and assess data-security risks and provide recommendations
Microsoft Purview Audit	Record and investigate supported AI and user activities
Data classification	Identify sensitive information in supported content and interactions
Sensitivity labels	Classify and protect sensitive content
Data Loss Prevention	Detect, warn, or block inappropriate sharing of sensitive data
Insider Risk Management	Identify potentially risky user behavior
Communication Compliance	Detect inappropriate or policy-violating communications
eDiscovery	Search and preserve supported AI interaction content for investigations or legal matters
Data Lifecycle Management	Retain or delete content according to organizational requirements

For example, DSPM might identify that users are frequently submitting sensitive information to an AI application. A security team could then use the finding to create a DLP policy, configure an Insider Risk Management policy, or improve sensitivity-label coverage.

Microsoft Copilot and permission-based access

Microsoft 365 Copilot uses the permissions available to the user. This means that an organization should not assume that deploying Copilot automatically creates a new permission model or bypasses SharePoint and Microsoft 365 access controls.

However, existing permissions may be too broad.

For example:

A user may belong to a large group that has access to a confidential site.
A document may be shared with everyone in the organization.
A file may be available through an overly broad sharing link.
A site may contain outdated information that is still accessible.
A sensitive document may not have an appropriate label or protection.

In these cases, Copilot may make the information more discoverable, but the underlying problem is usually the organization’s data-access or governance configuration. DSPM and SharePoint data-access governance capabilities help identify these issues.

Important distinction: DSPM versus SharePoint data-access governance

Both DSPM and SharePoint data-access governance can help identify exposure risks, but they serve different purposes.

DSPM

DSPM focuses on the broader data-security posture, including:

Sensitive data.
AI interactions.
Risk trends.
Recommendations.
Data exposure.
User and application activity.
AI-related security objectives.

SharePoint data-access governance

SharePoint data-access governance reports focus more directly on SharePoint and OneDrive permissions, sharing links, and access patterns.

Examples include:

Site permissions across the organization.
Site permissions for individual users.
Sites or files shared with everyone in the organization.
Sites or files shared with everyone except external users.
Sharing-link activity.
Sensitivity labels applied to files.
Site-access reviews.

These reports can help identify the underlying access configuration that may cause sensitive data to be exposed to Copilot or other authorized users.

Recommended process for identifying AI-related data risks

Step 1: Identify approved AI applications

Create an inventory of:

Microsoft 365 Copilot.
Microsoft Copilot Studio agents.
Microsoft Security Copilot.
Enterprise AI applications.
AI applications connected through Microsoft Entra.
AI applications built with Microsoft Foundry.
Approved third-party AI applications.
Unapproved or consumer AI applications.

This inventory helps distinguish expected business use from potentially unauthorized AI usage.

Step 2: Identify sensitive data

Review the organization’s use of:

Sensitive information types.
Sensitivity labels.
Trainable classifiers.
Confidentiality classifications.
DLP policies.
Data-retention requirements.

AI-risk detection is more effective when sensitive data has already been classified consistently.

Step 3: Configure the required collection and auditing

Verify that:

Microsoft Purview Audit is enabled.
Required AI interaction collection policies are configured.
Devices are onboarded where required.
Network integrations are configured for supported third-party AI scenarios.
Required licensing and billing prerequisites are satisfied.

Step 4: Review DSPM dashboards and recommendations

Look for:

Sensitive AI interactions.
Risky AI usage.
High-risk applications.
Repeated policy violations.
Users interacting with sensitive data.
AI activities involving protected material.
Recommendations for improving security posture.

Step 5: Investigate individual activities

Use available drill-down capabilities to determine:

Which user performed the activity.
Which AI application was used.
What data was involved.
Whether the data was sensitive.
Whether the activity was permitted.
Whether the activity was accidental or suspicious.
Which policy or control should be applied.

Step 6: Remediate the underlying risk

Possible actions include:

Applying or improving sensitivity labels.
Reducing SharePoint permissions.
Removing unnecessary sharing links.
Restricting access to sensitive sites.
Creating DLP policies.
Creating Insider Risk Management policies.
Blocking or restricting unapproved AI applications.
Educating users.
Archiving or deleting unnecessary content.
Reviewing AI agent permissions and data sources.

Step 7: Monitor continuously

AI usage and data exposure change over time. Organizations should regularly review:

New AI applications.
New agents.
Changes to permissions.
New sensitive-data findings.
Risk trends.
DLP incidents.
Insider Risk alerts.
Newly overshared content.
Changes in AI application usage.

Licensing and permissions considerations

The available DSPM capabilities depend on the organization’s licensing, tenant configuration, application support, and assigned administrative roles.

Some capabilities may require:

Microsoft Purview licensing.
Microsoft 365 licensing.
Microsoft Defender licensing.
Pay-as-you-go billing.
Appropriate Microsoft Entra or Microsoft Purview roles.
Device onboarding.
Audit configuration.
AI interaction collection policies.
Supported application integrations.

For example, some AI investigations require additional permissions before administrators can view prompt and response text or referenced files. Administrators should follow least-privilege principles and assign only the roles necessary for the investigation or compliance task.

Common exam traps

Trap 1: Assuming Copilot bypasses permissions

Copilot generally works with the permissions available to the user. The issue may be that the user already has excessive access.

Trap 2: Confusing DSPM with DLP

DSPM primarily helps discover, assess, and understand risks. DLP is used to enforce policies that can warn, block, or restrict certain data-sharing activities.

Trap 3: Confusing Audit with DSPM

Audit provides activity records. DSPM provides broader risk analysis, dashboards, assessments, and recommendations.

Trap 4: Assuming every AI application is monitored automatically

Coverage depends on the application, integration, licensing, configuration, and collection policies.

Trap 5: Assuming all prompt and response content is visible to every administrator

Viewing detailed content is controlled by permissions and role groups.

Trap 6: Treating every risk finding as proof of malicious behavior

A DSPM finding may indicate potential exposure or risky activity. It requires investigation and context before a conclusion is reached.

Trap 7: Confusing sensitivity labels with permissions

A sensitivity label can classify and protect content, but labeling alone does not necessarily replace SharePoint permissions or correct an incorrectly configured access group.

Trap 8: Ignoring third-party AI applications

AI risks can exist outside Microsoft Copilot. Microsoft Purview can provide supported visibility into certain enterprise and third-party AI scenarios, but coverage is not universal.

Summary

Microsoft Purview DSPM helps organizations identify and manage risks associated with Microsoft Copilot and other AI applications.

The most important concepts are:

AI can amplify existing data oversharing.
Microsoft 365 Copilot generally respects existing permissions.
DSPM provides centralized visibility into data-security risks.
DSPM for AI can identify sensitive AI interactions and risky usage.
Microsoft Purview Audit provides activity records.
Data classification identifies sensitive information.
Sensitivity labels classify and protect content.
DLP can enforce data-sharing restrictions.
Insider Risk Management helps identify potentially risky behavior.
Activity Explorer supports detailed investigation when the administrator has the required permissions.
AI-risk monitoring requires appropriate configuration, licensing, and collection policies.
DSPM findings should lead to investigation, remediation, and continuous monitoring.

Practice Exam Questions

Question 1

An organization wants to identify whether users are submitting sensitive information to Microsoft Copilot and other supported AI applications. Which Microsoft Purview capability is the best starting point?

A. Microsoft Purview Data Lifecycle Management
B. Microsoft Purview Communication Compliance
C. Microsoft Purview Records Management
D. Microsoft Purview Data Security Posture Management

Answer: D

Explanation: Microsoft Purview DSPM provides dashboards, assessments, and recommendations for identifying data-security risks, including sensitive information involved in AI interactions. Data Lifecycle Management focuses on retention and deletion, while Communication Compliance focuses primarily on inappropriate communications.

Question 2

A user asks Microsoft 365 Copilot to summarize a confidential document. The user can access the document because it is shared with a large Microsoft 365 group. What is the most likely underlying security issue?

A. Copilot has bypassed SharePoint permissions.
B. Copilot has trained its model on the document.
C. Copilot has disabled the document’s sensitivity label.
D. The document may be overshared through existing permissions.

Answer: D

Explanation: Microsoft 365 Copilot generally respects the user’s existing permissions. The likely problem is that the document is accessible to more users than necessary through the group’s permissions.

Question 3

An administrator needs to investigate individual AI activities and, where authorized, view the prompts, responses, and referenced files. Which capability should the administrator use?

A. Activity Explorer in Microsoft Purview
B. Azure Resource Graph
C. Azure Policy compliance results
D. Microsoft Defender for Containers

Answer: A

Explanation: Activity Explorer can provide detailed information about supported AI activities. Viewing prompt, response, and referenced-file content requires the appropriate Microsoft Purview permissions and role-group membership.

Question 4

Which Microsoft Purview capability is primarily responsible for identifying sensitive information in AI prompts and responses?

A. Microsoft Purview eDiscovery
B. Microsoft Purview Data Lifecycle Management
C. Microsoft Purview data classification
D. Microsoft Purview resource locks

Answer: C

Explanation: Data classification uses sensitive information types, trainable classifiers, and other classification mechanisms to identify sensitive information in supported AI interactions.

Question 5

An organization wants to capture supported Copilot prompts and responses so they can be analyzed for security and compliance purposes. What should the organization configure?

A. An Azure subscription lock
B. A Microsoft Entra access package
C. A network security group
D. An appropriate Microsoft Purview AI interaction collection policy

Answer: D

Explanation: Some AI interaction scenarios require collection policies to capture prompts and responses. The collected information can then be used by supported Purview solutions for investigation, compliance, and risk analysis.

Question 6

A security team wants to detect potentially risky behavior such as prompt injection attempts and attempts to access protected material. Which Microsoft Purview capability is most relevant?

A. Data Lifecycle Management
B. Insider Risk Management
C. Records Management
D. Information Barriers only

Answer: B

Explanation: Microsoft Purview Insider Risk Management can use AI-related signals and a risky AI usage policy template to help identify potentially risky or suspicious user behavior.

Question 7

Which statement best describes the relationship between DSPM and Data Loss Prevention?

A. DSPM replaces all DLP policies.
B. DLP identifies all AI applications, while DSPM blocks them.
C. DSPM helps identify risks and recommend actions, while DLP can enforce data-sharing controls.
D. DSPM and DLP are identical capabilities with different names.

Answer: C

Explanation: DSPM provides visibility, assessments, analytics, and recommendations. DLP is used to detect, warn about, or block certain activities involving sensitive information.

Question 8

An organization wants to investigate whether employees are using consumer AI websites and submitting sensitive company information. Which combination may be required for supported third-party AI scenarios?

A. Microsoft Purview capabilities, appropriate collection or network integration, and device onboarding where required
B. Azure Bastion and Azure Firewall only
C. Azure Backup and resource locks
D. Microsoft Defender for Containers and Azure Kubernetes Service

Answer: A

Explanation: Visibility into third-party AI usage depends on supported integrations and configuration. Some scenarios require network-based discovery, the Microsoft Purview browser extension, and onboarded devices.

Question 9

An administrator sees an increase in sensitive AI interactions in a DSPM dashboard. What should the administrator do next?

A. Immediately delete all AI applications.
B. Investigate the detailed activities and determine the appropriate remediation.
C. Disable Microsoft Entra ID for all users.
D. Remove all sensitivity labels.

Answer: B

Explanation: A dashboard finding is an indicator of potential risk, not necessarily proof of malicious activity. The administrator should investigate the affected users, applications, data, and circumstances before selecting a remediation.

Question 10

Which statement about viewing AI prompts and responses in Microsoft Purview is correct?

A. Every Microsoft 365 administrator can automatically view all prompt and response content.
B. Prompt and response content is always publicly visible to all security analysts.
C. Prompt and response content can be viewed only by the AI application owner.
D. Access to detailed content is controlled by Microsoft Purview permissions and applicable role groups.

Answer: D

Explanation: Detailed AI interaction content is protected by role-based access controls. Administrators need the appropriate permissions and role-group membership to view prompts, responses, and referenced files where supported.

Go to the SC-500 Exam Prep Hub main page

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

Implement conditional access for Microsoft Entra Agent ID (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 AI
      --> Implement conditional access for Microsoft Entra Agent ID

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

AI agents increasingly perform tasks that were previously completed by users or applications. They may access files, call APIs, read databases, send messages, or execute business processes. Because agents can operate autonomously and at high speed, granting them unrestricted access creates significant security risks.

Microsoft Entra Agent ID provides identity and access-management capabilities designed specifically for AI agents. Microsoft Entra Conditional Access can then evaluate the agent’s identity, context, and risk before allowing it to access protected resources.

The objective is to apply Zero Trust principles to agents:

Never trust an agent automatically. Verify the agent’s identity, evaluate its risk and context, and grant only the access it requires.

Microsoft Entra Agent ID introduces dedicated agent identities that can be governed and protected similarly to other identities, while also providing agent-specific controls and policy scenarios.

Why Conditional Access Is Important for AI Agents

Traditional applications generally operate according to predefined workflows. AI agents, however, can dynamically interpret instructions, select tools, and decide which actions to perform.

For example, an agent might:

Receive a user request.
Retrieve information from a business application.
Call a database or API.
Generate a response.
Perform an additional action based on the information it discovered.

If the agent is compromised, misconfigured, or manipulated through prompt injection, it may attempt to access resources outside its intended scope.

Conditional Access helps reduce this risk by allowing an organization to define policies such as:

Block high-risk agent identities.
Allow only selected agents to access production resources.
Restrict agents based on security attributes.
Apply different policies to development and production agents.
Require access to occur through approved network conditions.
Apply different controls to autonomous agents and agents acting on behalf of users.

Conditional Access does not replace authorization. It determines whether access is permitted under specific conditions. The agent must still have the necessary permissions to access the target resource.

Microsoft Entra Agent ID Concepts

Agent identity

An agent identity is a dedicated identity representing an AI agent in Microsoft Entra ID. It provides a distinct security principal that can be authenticated, authorized, governed, and monitored.

Using a separate identity is preferable to allowing many agents to share a broad application identity because it improves:

Accountability.
Permission management.
Risk evaluation.
Access reviews.
Incident investigation.
Lifecycle management.

Agent identity blueprint

An agent identity blueprint represents the definition or source from which agent identities are created.

Conditional Access policies can be applied at the blueprint level so that agent identities created from that blueprint inherit the applicable policies. This is useful when an organization wants consistent controls across a group of related agents.

Agent user

An agent user is an identity associated with an agent for scenarios in which the agent operates on behalf of a user. This is different from an autonomous agent that acts without a user context.

The distinction matters because an organization may need different policies for:

Autonomous agents that act independently.
Agents acting on behalf of users.
Agents with delegated access.
Agents using application-only permissions.

Microsoft Entra documentation provides separate policy scenarios for autonomous agents and agents acting on behalf of users.

How Conditional Access Works for Agents

A Conditional Access policy is essentially an if-then statement:

If a specified identity attempts to access a specified resource under specified conditions, then grant access, require an applicable control, or block access.

For agent identities, the policy can evaluate information such as:

Which agent is requesting access.
Whether the agent belongs to a particular blueprint.
The resource being accessed.
The agent’s risk level.
Agent attributes.
Network or location-related signals.
Whether the agent is autonomous or acting on behalf of a user.

All applicable Conditional Access policies must be satisfied before access is granted. If one applicable policy blocks access, the request is blocked.

Conditional Access Policy Assignments for Agents

A Conditional Access policy generally contains three major areas:

Assignments
Conditions
Access controls

1. Assignments

Assignments determine which identities and resources are included in the policy.

For agent policies, supported targeting options include:

All agent identities.
Selected agents acting as users.
Agents selected by attributes.
Individual agent identities.

This allows an organization to create broad policies or highly targeted policies.

2. Target resources

The policy can target the cloud applications or resources that agents are attempting to access.

For example, an organization could create a policy that applies to agents accessing:

Production databases.
Sensitive document repositories.
Microsoft Graph resources.
Business applications.
Administrative services.
High-value APIs.

The agent may be allowed to access low-risk resources while being blocked from sensitive resources unless additional conditions are satisfied.

3. Conditions

Conditions determine when the policy applies. Depending on the supported agent scenario, conditions can include:

Agent risk.
Agent attributes.
Network location.
Other applicable identity or resource context.

Agent-specific Conditional Access guidance emphasizes using risk, identity filters, and named locations rather than relying on interactive user controls.

Agent Risk and Microsoft Entra ID Protection

One of the most important capabilities is the ability to use Microsoft Entra ID Protection risk signals in Conditional Access policies.

An agent may be considered high risk because of suspicious behavior, such as:

Accessing unfamiliar resources.
Making an unusually high number of sign-in attempts.
Exhibiting behavior associated with a compromised identity.
Displaying other risk indicators detected by Microsoft Entra ID Protection.

An organization can create a Conditional Access policy that blocks agent identities identified as high risk.

Example

A company has an autonomous purchasing agent that normally accesses inventory and approved purchasing APIs. Microsoft Entra ID Protection detects that the agent is attempting to access unfamiliar resources at an unusually high rate.

A Conditional Access policy can be configured to:

Include all agent identities.
Target the relevant resources.
Use high agent risk as a condition.
Block access.

This helps prevent a potentially compromised agent from continuing to access organizational resources.

Agent Attributes and Fine-Grained Policies

Organizations can use attributes to classify agents and apply more precise controls.

Examples of useful attributes include:

Environment: Development, Test, or Production.
Department: Finance, Human Resources, or Operations.
Data sensitivity: Public, Internal, Confidential, or Restricted.
Business owner.
Agent type.
Regulatory classification.

For example, an organization might apply a policy that blocks agents classified as Development from accessing production resources.

This approach is more scalable than manually creating a separate policy for every agent. It also makes it easier to enforce consistent security standards across large agent inventories.

Important Agent-Specific Consideration: Interactive Controls

Many traditional Conditional Access policies are designed for human users. They may require controls such as:

Multifactor authentication.
A compliant device.
A user-approved client application.
A password change.
Acceptance of terms of use.

Agents generally cannot complete interactive controls in the same way that human users can.

For this reason, organizations should not simply apply a broad user policy to agents and assume it will work correctly. Instead, create dedicated agent policies that use controls appropriate for noninteractive or agent-based access, such as:

Agent identity targeting.
Risk-based blocking.
Attribute-based filtering.
Resource restrictions.
Network controls.
Least-privilege authorization.

Microsoft recommends creating agent-specific policies rather than relying exclusively on policies designed for users.

Autonomous Agents Versus Agents Acting on Behalf of Users

Autonomous agents

An autonomous agent operates without a user context. It may run on a schedule, respond to events, or independently perform tasks.

Examples include:

An agent that monitors inventory.
An agent that processes incoming support requests.
An agent that checks compliance conditions.
An agent that performs scheduled data analysis.

Policies for autonomous agents should focus on the agent’s own identity, permissions, risk, and resource access.

Agents acting on behalf of users

An agent acting on behalf of a user performs actions in the context of a human user or uses delegated permissions.

Examples include:

An assistant retrieving a user’s calendar.
An agent preparing a report using the user’s permitted files.
An agent submitting a request on behalf of an employee.

These scenarios require careful consideration of both:

The agent’s identity.
The user context and delegated permissions.

Microsoft Entra provides separate Conditional Access policy scenarios for autonomous agents and agents acting on behalf of users.

Example Conditional Access Policies

Policy 1: Block high-risk agents

Purpose: Prevent risky agents from accessing organizational resources.

Example configuration:

Include: All agent identities.
Target resources: Selected organizational resources.
Condition: High agent risk.
Access control: Block access.

This is one of the most important baseline policies for agent security.

Policy 2: Restrict development agents

Purpose: Prevent development agents from accessing production resources.

Example configuration:

Include: Agents with an Environment attribute of Development.
Target resources: Production applications or databases.
Access control: Block access.

Policy 3: Protect sensitive resources

Purpose: Apply stricter controls to agents accessing confidential data.

Example configuration:

Include: Selected agent identities or agents with a specific data-sensitivity attribute.
Target resources: Sensitive applications or data repositories.
Conditions: Applicable agent context and risk.
Access control: Allow only when the required conditions are satisfied.

Policy 4: Separate autonomous-agent access

Purpose: Apply policies specifically to agents that operate without user context.

Example configuration:

Include: Autonomous agent identities.
Target resources: Approved APIs and applications.
Access control: Permit only the intended access pattern.

How to Configure Conditional Access for Agent Identities

The exact portal experience may change as Microsoft Entra Agent ID and Microsoft Agent 365 evolve. The following process describes the core configuration approach.

Step 1: Identify the agents that require protection

Before creating policies, determine:

Which agents exist.
Which agents use Microsoft Entra Agent ID.
Whether each agent is autonomous or acts on behalf of a user.
Which resources each agent needs.
Who owns and sponsors each agent.
Which agents access sensitive or production resources.

Do not begin by applying a broad blocking policy without understanding the agent inventory and access requirements.

Step 2: Assign appropriate permissions

Conditional Access does not grant permissions by itself.

First, assign the agent only the permissions required for its tasks. Use:

Least-privilege permissions.
Narrow API scopes.
Specific resource assignments.
Access packages where appropriate.
Separate identities for separate agents or workloads.

Access packages can assign agent identities access to resources such as security groups, application permissions, and Microsoft Entra roles.

Step 3: Open the Conditional Access policy experience

In the Microsoft Entra admin center:

Open Microsoft Entra ID.
Navigate to Protection.
Open Conditional Access.
Create a new policy.

The exact navigation labels may vary as the portal changes.

Step 4: Select the agent identities

In the policy’s identity assignment area, select the applicable agent scope.

Possible scopes include:

All agent identities.
Specific agent identities.
Agents selected by attributes.
Agents acting as users.

Avoid accidentally including human users or unrelated workload identities when the policy is intended only for agents.

Step 5: Select target resources

Choose the applications, services, or resources that the agent policy should protect.

A policy targeting sensitive production resources is often safer and easier to test than a policy initially targeting every resource in the tenant.

Step 6: Configure conditions

Configure conditions appropriate to the scenario, such as:

High agent risk.
Agent identity attributes.
Network conditions.
Other supported context signals.

For example, a high-risk policy should use the agent risk condition rather than a human-user sign-in-risk condition.

Step 7: Configure the access control

Select the appropriate enforcement action:

Block access for high-risk or unauthorized scenarios.
An applicable grant control when the agent scenario supports it.
Appropriate session or network controls where available.

Do not require interactive MFA as a default solution for autonomous agents. Agents cannot generally respond to an interactive MFA challenge as a human user would.

Step 8: Start in report-only mode

Use report-only mode to evaluate the policy before enforcing it.

This helps identify:

Agents that would be blocked.
Unexpected policy matches.
Conflicts with existing policies.
Agents that require different permissions or attributes.
Potential business impact.

Microsoft recommends testing agent policies in report-only mode before enabling enforcement.

Step 9: Review the results

Review the Conditional Access results and determine whether:

The intended agents are being targeted.
Unintended identities are included.
The policy blocks legitimate operations.
The policy fails to protect the intended resources.
Existing broad policies interfere with agent access.

Step 10: Enable the policy

After testing, enable the policy and monitor its effect.

Use a staged rollout where possible:

Test with a small group of agents.
Review logs and operational behavior.
Expand the scope.
Continue monitoring for false positives and unexpected access attempts.

Conditional Access and Existing User Policies

A common mistake is assuming that a policy such as “All users must use MFA” automatically provides appropriate protection for agents.

Agent identities are not human users, and interactive user controls may not apply to them in the same way.

Organizations should:

Review broad policies for their impact on agents.
Create dedicated policies for agent identities.
Avoid unintentionally blocking legitimate agent flows.
Avoid excluding agents from security controls merely because a user-focused policy does not work.
Replace unsuitable controls with agent-appropriate conditions and restrictions.

The goal is not to weaken security for agents. The goal is to apply controls that are appropriate for how agents authenticate and operate.

Relationship to Other Security Controls

Conditional Access is only one layer of defense.

Microsoft Entra authorization

Authorization determines what the agent is allowed to access. Conditional Access determines whether the access is permitted under current conditions.

Both are required.

Microsoft Entra ID Protection

ID Protection supplies risk signals that can be used by Conditional Access policies, including policies that block high-risk agents.

Access packages and identity governance

Access packages help control which resources an agent can receive access to and can include approval and expiration requirements.

Microsoft Agent 365

Microsoft Agent 365 provides broader agent discovery, management, and governance capabilities. Microsoft Entra Agent ID provides the identity foundation used to manage and protect agent identities.

Microsoft Purview

Purview can help identify and govern data risks, including classification, sensitivity labels, and data protection controls. These capabilities complement Conditional Access but do not replace it.

Runtime protection

Runtime protection can inspect agent behavior or tool invocations while the agent is operating. Conditional Access is primarily an identity and access decision made before access to a resource is granted.

Best Practices

Use a unique identity for each agent

Avoid sharing one broad identity across many unrelated agents. Separate identities improve accountability and make it easier to revoke or restrict access.

Apply least privilege

Grant only the permissions required for the agent’s specific tasks. Do not use broad permissions simply because they are easier to configure.

Block high-risk agents

Create a baseline policy that blocks agent identities identified as high risk by Microsoft Entra ID Protection.

Use attributes for scale

Use attributes such as environment, department, and data sensitivity to apply consistent policies across many agents.

Separate development and production

Development agents should not automatically have access to production resources.

Test policies in report-only mode

Validate policy behavior before enforcement to reduce accidental outages.

Review existing policies

Broad policies designed for users may unintentionally block agents or fail to protect them appropriately.

Combine Conditional Access with authorization

Conditional Access cannot compensate for excessive permissions. The agent must still be granted only the access it needs.

Maintain ownership and sponsorship

Every agent should have an accountable owner or sponsor who can review its permissions, lifecycle, and continued business need.

Monitor and review continuously

Agent behavior, permissions, and risk can change over time. Periodically review:

Agent identities.
Access assignments.
Conditional Access results.
Risk detections.
Resource permissions.
Ownership and sponsorship.
Policy exceptions.

Common Exam Traps

Conditional Access is not the same as authorization

Conditional Access does not determine the complete set of permissions an agent has. It evaluates whether access should be allowed under specified conditions.

Agent identities are not ordinary human users

Do not assume an agent can satisfy interactive controls such as MFA prompts.

High-risk agents should generally be blocked

A common security scenario is creating a policy that blocks agent identities identified as high risk.

User policies should not be copied blindly

Policies designed for human users may not be appropriate for autonomous agents.

Report-only mode does not enforce the policy

Report-only mode evaluates and reports policy results without applying the policy’s enforcement action.

Conditional Access does not replace least privilege

An agent with excessive permissions remains dangerous even if Conditional Access is enabled.

Autonomous and delegated agents are different

An autonomous agent and an agent acting on behalf of a user may require different policy designs.

Practice Exam Questions

Question 1

What is the primary purpose of applying Conditional Access to Microsoft Entra agent identities?

A. To automatically create agent identities
B. To evaluate agent context and risk before allowing access to resources
C. To replace all agent authorization permissions
D. To train the agent to recognize malicious prompts

Correct answer: B

Explanation: Conditional Access evaluates identity, context, and risk to determine whether an agent should be allowed to access a resource. It does not create identities, replace authorization, or train the agent.

Question 2

An organization wants to prevent agents identified as high risk from accessing company resources. Which solution is most appropriate?

A. Require all agents to complete interactive MFA
B. Assign every agent the Global Administrator role
C. Disable all agent identities permanently
D. Create a Conditional Access policy that blocks high-risk agent identities

Correct answer: D

Explanation: Microsoft Entra ID Protection risk signals can be used with Conditional Access to block high-risk agent identities.

Question 3

Which targeting option is appropriate when an organization wants a Conditional Access policy to apply to every Microsoft Entra agent identity?

A. All Microsoft 365 users
B. All guest users
C. All managed identities
D. All agent identities

Correct answer: D

Explanation: Conditional Access supports targeting all agent identities. The other options target different identity categories.

Question 4

Why should organizations avoid applying human-user Conditional Access policies to autonomous agents without review?

A. Agents cannot be assigned permissions
B. Agents are not recorded in Microsoft Entra ID
C. Agents may not be able to satisfy interactive controls such as MFA
D. Conditional Access cannot block agents

Correct answer: C

Explanation: Autonomous agents generally cannot respond to interactive controls in the same way as human users. Dedicated agent policies should use appropriate identity, risk, attribute, and resource controls.

Question 5

An organization wants to prevent development agents from accessing production applications. Which approach is most scalable?

A. Require every developer to manually approve each request
B. Delete all development agents
C. Give development agents unrestricted access and monitor them
D. Use an agent attribute such as Environment and create a policy targeting development agents

Correct answer: D

Explanation: Attribute-based targeting allows organizations to apply consistent policies to groups of agents, such as blocking development agents from production resources.

Question 6

What is the recommended first enforcement stage when testing a new Conditional Access policy for agents?

A. Report-only mode
B. Permanent blocking mode
C. Global Administrator approval for every request
D. Disabling all existing policies

Correct answer: A

Explanation: Report-only mode allows administrators to evaluate the policy’s impact before enforcing it.

Question 7

Which statement best describes the relationship between Conditional Access and authorization?

A. Conditional Access grants all permissions required by the agent
B. Authorization is unnecessary when Conditional Access is enabled
C. Conditional Access evaluates whether access is allowed, while authorization determines what the agent can access
D. Conditional Access only applies after the agent has completed its task

Correct answer: C

Explanation: Conditional Access and authorization serve different purposes. Both are necessary for secure agent access.

Question 8

An autonomous agent normally accesses inventory APIs but suddenly attempts to access unfamiliar resources. Which Microsoft Entra capability can provide a risk signal for a Conditional Access policy?

A. Microsoft Entra ID Protection
B. Azure Resource Locks
C. Azure Backup
D. Microsoft Purview retention labels

Correct answer: A

Explanation: Microsoft Entra ID Protection can detect risky identity behavior and provide risk signals that Conditional Access can use to block or restrict access.

Question 9

Which statement about autonomous agents and agents acting on behalf of users is correct?

A. They always require identical Conditional Access policies
B. Autonomous agents always use delegated user permissions
C. Agents acting on behalf of users cannot access applications
D. They may require different policies because their identity and user-context models differ

Correct answer: D

Explanation: Autonomous agents operate without a user context, while delegated agents act on behalf of users. Their access and policy requirements can therefore differ.

Question 10

Which action is most consistent with a least-privilege strategy for Microsoft Entra agent identities?

A. Give every agent broad Microsoft Graph application permissions
B. Assign only the API scopes, applications, and resources required by each agent
C. Use one shared administrator identity for all agents
D. Exclude agents from all Conditional Access policies

Correct answer: B

Explanation: Least privilege means granting each agent only the permissions necessary for its intended tasks. Broad shared identities and excessive permissions increase risk.

Go to the SC-500 Exam Prep Hub main page

AI Security, azure, Azure AI, Microsoft Certification, SC-500, security October 10, 2026

Manage Entra Agent ID access (SC-500 Exam Prep)

This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Secure compute (20–25%)
   --> Implement security for AI
      --> Manage Entra Agent ID 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

Artificial intelligence agents increasingly perform tasks that traditionally required human users or application identities. An agent may read documents, query databases, call APIs, send messages, update business systems, or perform actions autonomously.

Because an agent can access organizational resources and act on behalf of users or applications, it must be managed as an identity—not merely as a software component. Microsoft Entra Agent ID extends Microsoft Entra identity, access, governance, and security capabilities to AI agents.

For the SC-500 exam, managing Entra Agent ID access involves understanding how to:

Create and manage agent identities.
Understand agent identity blueprints.
Assign permissions to agents.
Apply Conditional Access policies.
Use access packages to govern agent access.
Monitor agent sign-ins and activity.
Manage owners and sponsors.
Detect, restrict, or disable risky agents.
Apply least-privilege and lifecycle controls.

Microsoft Entra Agent ID provides specialized identity constructs for AI agents and supports authentication, authorization, governance, and security controls throughout the agent lifecycle.

Why AI Agents Require Identity and Access Management

A traditional application may perform a limited set of predefined operations. An AI agent, however, may interpret instructions, select tools, retrieve information, and take actions dynamically.

For example, a customer-service agent might be able to:

Read customer records.
Search internal knowledge bases.
Access Microsoft Graph.
Update a CRM system.
Create support tickets.
Send email.
Access files stored in SharePoint or Azure Storage.

If that agent is compromised, manipulated, or incorrectly configured, its permissions could be abused. The security impact depends not only on whether the agent is compromised, but also on what the agent can access and what actions it can perform.

Therefore, security teams must answer questions such as:

What identity does the agent use?
Who owns and sponsors the agent?
Which resources can the agent access?
Which permissions were granted to it?
Are those permissions inherited from a blueprint?
Can the agent access resources on behalf of a user?
Can it act autonomously?
Can Conditional Access restrict its access?
How can the agent be disabled if it becomes risky?

The objective is to provide agents with only the access they require, for only as long as they require it.

Core Entra Agent ID Concepts

Agent identity

An agent identity is a specialized identity in Microsoft Entra ID that represents an individual AI agent.

Microsoft documentation describes an agent identity as a special service principal created from an agent identity blueprint. The agent identity represents the agent that is authorized to use the blueprint. It does not independently maintain its own credentials; the blueprint can acquire tokens on behalf of the agent identity after the appropriate consent and permissions have been granted.

An agent identity allows an organization to:

Give an agent a distinct identity.
Assign permissions to the agent.
Apply access policies.
Track sign-in activity.
Associate the agent with owners and sponsors.
Disable the agent when necessary.
Govern the agent independently from human users.

Example

A company deploys three instances of a sales assistant:

North America Sales Assistant.
Europe Sales Assistant.
Enterprise Sales Assistant.

Each instance can have its own agent identity while being created from the same blueprint. This allows the organization to manage the agents individually while also applying consistent controls to all agents created from that blueprint.

Agent identity blueprint

An agent identity blueprint is the parent definition from which agent identities are created.

A blueprint can establish common characteristics and permissions for agents of a particular type or purpose. It provides a way to apply consistent security controls across multiple agent identities.

For example, a company might create a blueprint named Customer Support Assistant. Multiple agents can be created from that blueprint for different departments or regions.

Blueprints help administrators:

Identify related agents.
View linked agent identities.
Manage common permissions.
Configure inheritable permissions.
Manage blueprint owners and sponsors.
Review audit and sign-in activity.
Disable the blueprint.
Prevent new agents from being created from a blueprint.

When a blueprint is disabled, existing agent identities created from that blueprint can also be prevented from authenticating.

Blueprint versus agent identity

Concept	Description
Agent identity blueprint	Parent definition used to create and authorize agent identities
Agent identity	Individual identity representing a deployed AI agent
Blueprint permissions	Permissions that can be inherited by agents created from the blueprint
Agent-specific access	Access assigned directly to an individual agent, such as through an access package
Blueprint owner	Person responsible for technical administration
Agent sponsor	Person accountable for the agent’s business purpose and lifecycle

A blueprint is useful when many agents require a consistent baseline. However, organizations should still evaluate whether each individual agent needs additional permissions.

Agent user account

Some agent scenarios require an identity that can interact with services expecting a user identity. Microsoft Entra Agent ID supports an agent user account for these scenarios.

An agent user account can bridge the gap between an AI agent and services that require user-like capabilities. It is different from the agent identity itself and should be governed with appropriate security boundaries.

The key exam distinction is that an organization may encounter several related identity concepts:

Agent identity.
Agent identity blueprint.
Agent user account.
Agent service principal.
Human user identity.

Do not assume that every agent uses the same identity model. The appropriate identity depends on how the agent authenticates, whether it acts autonomously, and whether it acts on behalf of a user.

Viewing and Managing Agent Identities

Administrators can view agent identities in the Microsoft Entra admin center.

The general navigation is:

Microsoft Entra admin center → Entra ID → Agents → Agent identities

The agent identity list can be searched, filtered, sorted, and customized. Administrators can search by:

Agent name.
Object ID.
Blueprint App ID.

The details for an agent identity can include:

Name and description.
Status.
Parent blueprint.
Owners and sponsors.
Granted permissions.
Microsoft Entra roles.
Audit logs.
Sign-in logs.
Whether the agent uses an agent identity object or a service principal.

Viewing agent identities does not necessarily require an administrative role. Managing them generally requires the Agent ID Administrator or Cloud Application Administrator role. An agent identity owner may also manage their own agent without holding one of those administrative roles.

Important administrative roles

Task	Typical role or responsibility
View agent identities	Microsoft Entra user account
Manage agent identities	Agent ID Administrator or Cloud Application Administrator
Create agent blueprints	Agent ID Developer
Configure Conditional Access	Conditional Access Administrator
View Identity Protection risk reports	Security Administrator, Security Operator, or Security Reader
Manage lifecycle workflows	Lifecycle Workflows Administrator
Manage an owned or sponsored agent	Agent owner or sponsor

The exact capabilities available depend on the operation, licensing, and whether the feature is in preview.

Understanding Agent Access

Agent access should be evaluated from several perspectives.

1. Authentication

Authentication establishes the identity of the agent or the user on whose behalf the agent is acting.

Questions to consider include:

How does the agent obtain tokens?
Is the agent autonomous?
Does it act on behalf of a signed-in user?
Which authentication protocol is used?
Is the identity associated with the correct blueprint?
Are sign-in events being logged?

Authentication alone does not determine what the agent is allowed to do. Authorization and policy controls are also required.

2. Authorization

Authorization determines which resources and operations the agent can access.

Examples include:

Microsoft Graph permissions.
Application API permissions.
Delegated permissions.
Microsoft Entra roles.
Security group membership.
Access to business applications.
Access to storage, databases, or repositories.

An agent should not receive broad permissions simply because it might need them in the future. Permissions should be limited to the agent’s documented business purpose.

3. Resource access

An agent may have access through:

Permissions inherited from its blueprint.
Direct permissions assigned to the agent.
Access packages.
Group memberships.
Application roles.
Microsoft Entra roles.
User-delegated access.
Access to connected tools or APIs.

A complete access review must consider all of these paths. Reviewing only the agent’s direct permissions may miss access inherited from a group, blueprint, or delegated user context.

Inheritable Permissions

Agent identity blueprints can be configured with inheritable permissions.

Inheritable permissions provide a consistent permission baseline for agents created from a particular blueprint. This is useful when all agents of a specific type need access to the same application or API.

For example, all agents created from a finance-assistant blueprint might need read access to a financial reporting API.

However, inheritable permissions must be designed carefully. If excessive permissions are assigned to a blueprint, every agent created from it may inherit unnecessary access.

Recommended approach

Define the agent’s business purpose.
Identify the minimum required resources.
Assign the narrowest available permissions.
Avoid inheriting high-privilege permissions unless required.
Review the permissions assigned to the blueprint.
Review the permissions of each linked agent.
Remove permissions that are no longer needed.

Microsoft documentation identifies limits for blueprint access configuration, including a maximum number of resource applications and enumerated scopes per resource application. Some high-privilege scopes may be blocked by platform policy and cannot be inherited.

Access Packages for Agent Identities

Microsoft Entra entitlement management can be used to govern agent access through access packages.

Access packages provide a policy-based way to assign access to resources. For agent identities, an access package can include:

Security group memberships.
Application OAuth API permissions.
Microsoft Graph application permissions.
Microsoft Entra roles.

Access packages can help organizations control:

Who can request access for an agent.
Which resources can be assigned.
Whether approval is required.
How long access remains active.
Whether access must be reviewed.
When access should expire.

An access package assignment policy can be configured for users, service principals, and agent identities in the directory. The policy can target all agents or a more specific set of identities.

Why access packages are useful

Access packages are especially valuable when an agent requires temporary or controlled access to sensitive resources.

For example, an analytics agent may need access to a restricted data source for a limited project. Instead of granting permanent broad access, the organization can:

Create an access package.
Define the required resource permissions.
Require approval from the agent owner or sponsor.
Set an expiration date.
Review the assignment periodically.
Remove access when the project ends.

This supports the principle of just enough access for just enough time.

Owners and Sponsors

Agent owners and sponsors provide accountability.

Owners

Owners are generally responsible for technical administration. They may manage:

Agent configuration.
Operational status.
Technical access.
Agent-related administration.
Enabling or disabling the agent.

Conditional Access for Agent Identities

Conditional Access controls the conditions under which an agent identity can access resources.

Conditional Access policies can be used to:

Block all agent identities.
Allow only selected agents.
Target specific agent identities.
Target agent identities associated with a blueprint.
Block agents based on risk.
Apply policies to all resources.
Use report-only mode before enforcement.

For example, an organization could create a policy that blocks agent identities with a high agent risk level.

Conditional Access enforcement applies when an agent identity or an agent user account requests a token for a resource. It does not apply when an agent identity blueprint acquires a token to create agent identities or agent user accounts.

Report-only mode

Report-only mode allows administrators to evaluate the potential effect of a policy before enforcing it.

This is useful because a broad policy blocking all agents could disrupt:

Business workflows.
Copilot experiences.
Automated processes.
Applications that depend on agent access.
Agents that have not yet been migrated to the correct identity model.

A recommended deployment process is:

Create the Conditional Access policy.
Configure it in report-only mode.
Review sign-in and policy impact.
Identify agents that would be blocked.
Correct unintended dependencies.
Enable enforcement.
Monitor the results.

Identity Protection for Agents

Microsoft Entra ID Protection can detect anomalous behavior involving agent identities.

Examples of risk signals include:

Unfamiliar resource access.
Unusual sign-in spikes.
Failed access attempts.
Other abnormal authentication or access patterns.

Administrators can review the Risky Agents report and take actions such as:

Confirm compromise.
Confirm safe.
Dismiss the risk.
Disable the agent.

When an agent is confirmed as compromised, its risk level is set to High. If a Conditional Access policy is configured to block agents with high agent risk, the agent can be blocked from accessing resources.

Important distinction

Identity Protection detects risk. Conditional Access enforces access decisions.

Capability	Primary purpose
Identity Protection for agents	Detect anomalous or risky agent behavior
Conditional Access	Enforce access conditions based on identity, context, and risk
Agent administration	Enable, disable, and manage agent identities
Access packages	Govern assignment and duration of resource access
Defender XDR	Discover, investigate, and assess security risks and attack paths

Do not confuse an agent being marked as risky with the agent automatically being disabled. Automatic blocking depends on the policies configured by the organization.

Disabling Agent Identities

An organization can disable access at several levels.

Individual agent

Disabling an individual agent:

Prevents it from accessing resources.
Prevents it from being issued tokens.
Stops the specific agent without necessarily affecting other agents.

Blueprint level

Disabling a blueprint can:

Prevent new agent identities from being created from that blueprint.
Block existing agents associated with the blueprint from authenticating.

Tenant-wide

Conditional Access can be used to block all agent identity authentication. Organizations may also use product-specific controls to prevent the creation of new agent identities.

Tenant-wide blocking should be used carefully because it can:

Break existing agent workflows.
Degrade Microsoft product experiences.
Cause applications to fail.
Encourage teams to use less visible service-principal or application identities.

A more targeted approach is generally preferable when only a subset of agents is risky.

Monitoring Agent Activity

Agent activity should be monitored throughout the identity lifecycle.

Useful sources of information include:

Sign-in logs.
Audit logs.
Permission assignments.
Blueprint configuration.
Owners and sponsors.
Access package assignments.
Conditional Access results.
Identity Protection risk reports.
Security alerts.
Agent runtime activity.

Monitoring can help answer:

Is the agent authenticating as expected?
Is it accessing resources outside its normal purpose?
Are permissions being changed?
Has the agent been disabled or re-enabled?
Is the agent experiencing unusual sign-in behavior?
Is the agent using a deprecated or unnecessary permission?
Is the agent still owned and sponsored?

All agent authentication and activity should be logged and reviewed according to the organization’s security, privacy, and compliance requirements.

Managing Access for Autonomous and On-Behalf-of Agents

Not all agents operate in the same way.

Autonomous agents

An autonomous agent acts independently using its own agent identity and permissions.

Examples include:

A monitoring agent that investigates alerts.
A scheduled reporting agent.
An automation agent that updates records.
A data-processing agent that runs without a user being present.

For autonomous agents, the organization must carefully control the permissions assigned directly to the agent identity.

On-behalf-of-user agents

An on-behalf-of-user agent acts using the context or permissions of a signed-in user.

Examples include:

An assistant that searches a user’s files.
An agent that creates calendar events for a user.
An agent that retrieves information the user is already authorized to access.

On-behalf-of scenarios require careful consideration of delegated permissions and user context. The agent should not become a way to bypass the user’s permissions.

Exam consideration

When evaluating an agent’s access, determine whether it:

Uses its own application permissions.
Uses delegated permissions.
Acts autonomously.
Acts on behalf of a user.
Uses an agent user account.
Inherits permissions from a blueprint.

The identity model affects how access should be assigned and controlled.

Recommended Least-Privilege Strategy

A secure Entra Agent ID implementation should follow these practices.

Use separate identities for separate purposes

Do not use one highly privileged agent identity for unrelated workloads.

For example, separate:

Customer support.
Financial reporting.
Human resources.
Production operations.
Security investigation.

This limits the impact if one agent is compromised.

Minimize permissions

Grant only the permissions required for the agent’s documented tasks.

Prefer:

Read-only access where possible.
Narrow API scopes.
Specific application roles.
Restricted resource groups.
Limited group memberships.
Time-bound access packages.

Avoid:

Broad directory roles.
Unnecessary Microsoft Graph permissions.
Permanent access to production systems.
Shared identities across unrelated agents.
Excessive delegated permissions.

Separate read and write capabilities

If an agent only needs to retrieve information, do not grant it write, delete, or administrative permissions.

For example:

A reporting agent should read data but not modify it.
A knowledge agent should retrieve documents but not change permissions.
A support agent may create tickets but should not delete customer accounts.

Require approval for sensitive operations

High-impact operations should require additional controls, such as:

Human approval.
Restricted API endpoints.
Separate privileged workflows.
Explicit access packages.
Just-in-time access.
Transaction limits.

Review inherited permissions

Review both:

Permissions inherited from the blueprint.
Permissions assigned directly to the agent.

A blueprint change can affect many linked agents, so blueprint permissions should be treated as a high-impact administrative control.

Maintain ownership and sponsorship

Every production agent should have:

A technical owner.
A business sponsor.
A documented purpose.
A defined data classification.
A review schedule.
A retirement process.

Use report-only policies before enforcement

Conditional Access and other broad controls should be tested in report-only mode where supported.

Disable unused agents

An agent that is no longer needed should be disabled or retired. Unused identities can retain access and become attractive targets.

Example Scenario

A company deploys a customer-service agent that can:

Read customer records.
Search SharePoint knowledge bases.
Read Microsoft Graph mail.
Update the CRM.
Access an Azure DevOps repository.
Call a production API.

The agent was initially configured with broad permissions to simplify development.

A security review identifies several concerns:

The agent has access to data unrelated to customer support.
It can modify production records.
It can read confidential email.
It has access to source code.
Its blueprint grants permissions inherited by multiple agents.
No formal sponsor has been assigned.

A secure remediation plan would include:

Create a clearly defined business purpose.
Assign a technical owner and business sponsor.
Remove access to email and source code unless explicitly required.
Replace broad CRM permissions with narrowly scoped roles.
Separate read-only operations from write operations.
Restrict production API access.
Use an access package for temporary elevated access.
Apply Conditional Access policies.
Monitor sign-ins and risk signals.
Disable the agent if compromise is suspected.
Review all agents created from the same blueprint.
Reassess permissions after remediation.

The goal is not merely to secure the agent’s authentication. It is to reduce the consequences of compromise by limiting the agent’s reachable resources and available actions.

Common Exam Distinctions

Entra Agent ID versus Microsoft Agent 365

Microsoft Entra Agent ID provides the identity and access foundation for agents.

Microsoft Agent 365 provides an enterprise control plane for managing and governing agents at scale, using Entra Agent ID as its identity foundation.

Agent identity versus blueprint

An agent identity represents an individual agent.

A blueprint is the parent definition from which agent identities are created and may inherit common permissions.

Access packages versus Conditional Access

Access packages govern which resources an agent can be assigned.

Conditional Access governs under what conditions the agent can access those resources.

Identity Protection versus Conditional Access

Identity Protection detects risk.

Conditional Access can use risk signals to enforce access decisions.

Disabling an agent versus removing a permission

Disabling an agent blocks its operation and token issuance.

Removing a permission reduces what the agent can access but does not necessarily stop the agent from operating.

Autonomous versus delegated access

An autonomous agent uses its own identity and permissions.

A delegated or on-behalf-of agent operates in the context of a user and must not exceed the user’s authorized access.

Exam Tips

Remember the following points:

Treat AI agents as identities that require lifecycle management.
Use agent identity blueprints for consistent management and permissions.
Review both inherited and direct permissions.
Use access packages to govern resource assignments.
Use Conditional Access to control access conditions.
Use Identity Protection to detect risky agent behavior.
A risky agent is not necessarily automatically disabled.
Owners provide technical accountability.
Sponsors provide business and lifecycle accountability.
Report-only mode helps test Conditional Access policies.
Disabling a blueprint can affect existing agents created from it.
Tenant-wide blocking can disrupt legitimate agent workflows.
Least privilege is especially important because agents may invoke tools and act autonomously.
Always determine whether the agent acts autonomously or on behalf of a user.

Practice Exam Questions

Question 1

A security administrator wants to give each deployed AI agent a distinct identity that can be managed, monitored, and disabled independently. Which capability should the administrator use?

A. Azure resource locks
B. Azure Policy initiatives
C. Microsoft Defender for Storage
D. Microsoft Entra agent identities

Answer: D

Explanation: Microsoft Entra agent identities provide specialized identities for individual AI agents. They can be assigned permissions, monitored, associated with owners and sponsors, and disabled independently.

Question 2

An organization has 50 agents created for the same business function. The security team wants to apply common permissions and manage the agents consistently. What should the team use?

A. A separate Conditional Access policy for every user
B. A shared human administrator account
C. A single Azure subscription
D. An agent identity blueprint

Answer: D

Explanation: An agent identity blueprint is the parent definition from which agent identities are created. It supports consistent configuration, permission management, and administration across linked agents.

Question 3

An agent needs temporary access to a sensitive application for a specific project. The organization wants approval, expiration, and periodic review of that access. Which capability is most appropriate?

A. Microsoft Entra access packages
B. Azure resource locks
C. Microsoft Defender Antivirus
D. Azure DDoS Protection

Answer: A

Explanation: Access packages can govern resource access for agent identities and can include approval policies, expiration, and access reviews.

Question 4

A company wants to block agent identities that Microsoft Entra ID Protection identifies as having high risk. Which control should enforce this requirement?

A. Azure Policy
B. Microsoft Defender for Storage
C. Conditional Access
D. Azure Bastion

Answer: C

Explanation: Identity Protection detects agent risk, while Conditional Access can enforce a policy that blocks agents with a high agent risk level.

Question 5

Which responsibility is most closely associated with an agent sponsor?

A. Writing the agent’s application code
B. Managing the Azure virtual network
C. Creating all Microsoft Graph permissions
D. Providing business accountability and lifecycle oversight

Answer: D

Explanation: Sponsors are accountable for the agent’s business purpose and lifecycle. They help determine whether the agent is still needed and whether its access remains appropriate.

Question 6

An administrator wants to evaluate the effect of a Conditional Access policy before blocking agent identities. What should the administrator do?

A. Disable all agent blueprints
B. Configure the policy in report-only mode
C. Delete the agent identities
D. Remove all delegated permissions

Answer: B

Explanation: Report-only mode allows administrators to evaluate policy impact and identify unintended effects before enforcing the policy.

Question 7

An agent has permissions inherited from its blueprint and additional permissions assigned directly to the agent. During an access review, what should the administrator evaluate?

A. Only the direct permissions
B. Only the blueprint permissions
C. Both inherited and direct permissions
D. Only the agent’s display name

Answer: C

Explanation: An agent’s effective access can come from multiple sources. Reviewing both blueprint-inherited permissions and direct assignments is necessary to determine the agent’s complete access.

Question 8

A security team confirms that an agent identity has been compromised. Which action immediately prevents that specific agent from being issued tokens?

A. Disable the agent identity
B. Rename the agent
C. Change the agent’s description
D. Add another owner

Answer: A

Explanation: Disabling an individual agent identity blocks access and prevents the identity from being issued tokens. Adding owners or changing descriptive information does not stop the agent.

Question 9

Which statement best describes the difference between an autonomous agent and an on-behalf-of-user agent?

A. An autonomous agent cannot access any resources
B. An autonomous agent uses its own identity and permissions, while an on-behalf-of-user agent operates in a user context
C. An on-behalf-of-user agent must always have a Microsoft Entra administrator role
D. An autonomous agent does not require authentication

Answer: B

Explanation: Autonomous agents operate using their own identity and permissions. On-behalf-of-user agents operate using the context or permissions of a signed-in user.

Question 10

An organization disables an agent identity blueprint. What is the most likely security effect?

A. Only the blueprint’s display name changes
B. All human users are disabled
C. All Azure subscriptions are locked
D. Existing agents associated with the blueprint can be prevented from authenticating, and new agents cannot be created from it

Answer: D

Explanation: Disabling a blueprint can prevent new agent identities from being created from it and can block existing agents associated with the blueprint from authenticating.

Go to the SC-500 Exam Prep Hub main page

AI Governance, AI Security, Cybersecurity, Microsoft Certification, SC-500, security October 10, 2026

Configure and deploy AI Gateway in Azure API Management for Microsoft Foundry (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 AI
      --> Configure and deploy AI Gateway in Azure API Management for Microsoft Foundry

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 Foundry provides services for developing, deploying, and operating generative AI applications, models, and agents. As organizations adopt AI at scale, they need a controlled way to manage access to models and AI tools.

An AI Gateway uses Azure API Management to provide a governed entry point between applications or agents and AI backends. It can centralize authentication, authorization, traffic control, token usage, monitoring, routing, and security policies.

For SC-500, the important concept is that the AI Gateway is not simply another model endpoint. It is a security and governance layer placed between AI consumers and the services they access.

Exam focus: Understand how to connect Microsoft Foundry to Azure API Management, configure the gateway, import models or tools, apply policies, and verify that traffic is actually being mediated by the gateway.

What Is an AI Gateway?

An AI Gateway is a set of capabilities in Azure API Management that helps organizations manage AI-related backends.

These backends may include:

Models deployed in Microsoft Foundry.
Azure OpenAI deployments.
Other supported model providers.
OpenAI-compatible model endpoints.
Remote Model Context Protocol (MCP) servers.
Agent-to-agent APIs.
Custom AI services.
Self-hosted models and endpoints.

The AI Gateway extends the existing API Management gateway. It is not a completely separate gateway product. Existing API Management capabilities, including policies, authentication, routing, monitoring, and networking, are used to govern AI traffic.

Why use an AI Gateway?

Without a gateway, each application or agent may connect directly to an AI model or tool. This can lead to:

Duplicated authentication logic.
Inconsistent security policies.
Uncontrolled model consumption.
Difficulty enforcing quotas.
Limited visibility into usage.
Excessive exposure of backend endpoints.
Different teams implementing different controls.
Difficulty changing model providers.

An AI Gateway provides a centralized control point for these concerns.

For example, several applications might use different model deployments, but all requests can pass through API Management where the organization applies:

Authentication.
Authorization.
Rate limits.
Token quotas.
IP restrictions.
Content safety policies.
Request and response transformations.
Logging and metrics.
Backend routing.
Load balancing.
Caching, where appropriate.

AI Gateway Architecture

A typical architecture contains the following components:

AI consumer
- Application.
- Copilot.
- Agent.
- Development tool.
- Automated workload.
Microsoft Foundry resource or project
- Hosts or manages model deployments, agents, and tools.
Azure API Management instance
- Acts as the AI Gateway.
- Receives requests from consumers.
- Applies policies.
- Routes requests to the appropriate backend.
AI backend
- Microsoft Foundry model.
- Azure OpenAI deployment.
- External model provider.
- MCP server.
- Other supported AI endpoint.
Monitoring and governance services
- API Management logs and metrics.
- Application Insights, where configured.
- Microsoft Foundry telemetry.
- Security monitoring and auditing.

The gateway sits between the client and the AI backend. This allows the organization to enforce common controls without requiring every client application to implement those controls independently.

AI Gateway in Microsoft Foundry

Microsoft Foundry can be integrated with an Azure API Management instance as an AI Gateway.

This integration allows organizations to govern AI resources from within the Foundry environment while retaining access to the more advanced configuration capabilities of Azure API Management.

Depending on the supported feature and configuration, the gateway can help govern:

Models

The gateway can provide:

Token quotas.
Rate limits.
Authentication.
Routing.
Usage monitoring.
Model access control.
Centralized governance across model deployments.

When AI Gateway is used with Foundry, model requests can be routed through the associated API Management instance. Model limits can be configured at the project level, helping prevent one project or team from consuming all available capacity.

Agents

Agents can be registered and governed through Microsoft Foundry. Governance can include:

Centralized inventory.
Traffic policies.
Throttling.
Content safety controls.
Monitoring.
Access management.

The exact capabilities depend on the agent type and the integration being used.

Tools

MCP tools can be routed through an AI Gateway so that requests pass through a controlled endpoint.

Policies can be applied to MCP traffic, including:

Authentication.
Rate limiting.
IP filtering.
Correlation IDs.
Logging and metrics.
Routing controls.

However, the Foundry MCP gateway integration has limitations. For example, only eligible MCP tools created after the gateway is connected may be routed through the gateway. Existing tools are not automatically changed to use the gateway.

Prerequisites

Before configuring an AI Gateway for Microsoft Foundry, verify the following.

Azure API Management instance

You need an Azure API Management instance that meets the requirements for the selected integration.

Supported service tiers and networking requirements can vary depending on:

Whether the gateway is public or private.
Whether the Foundry resource has public network access disabled.
Whether private endpoints are required.
Whether advanced networking is needed.
Whether the organization is using the dedicated AI Gateway tier preview.

The dedicated AI Gateway tier is a public preview feature. Preview capabilities, supported regions, limits, and service behavior may change. Organizations should validate preview features carefully before using them for critical production workloads.

Required permissions

The administrator configuring the integration generally needs permission to manage the API Management instance.

For some Foundry gateway scenarios, the required role is:

API Management Service Contributor, or
Owner

The exact permissions depend on whether the administrator is connecting an existing gateway, creating an instance, importing models, or managing policies.

Networking

If the Foundry resource has public network access disabled, the API Management instance must also be able to access the private Foundry resource.

Depending on the architecture, this may require:

A private endpoint.
A supported API Management tier.
Virtual network integration or injection.
Appropriate private DNS configuration.
Network rules that permit the required traffic.

A gateway cannot securely mediate traffic to a private backend if the gateway itself cannot reach that backend.

Backend access

The administrator must have access to the model, deployment, or tool backend being added.

For managed identity authentication, the managed identity must also have the required permissions on the backend resource.

Creating or Associating an AI Gateway

The exact portal experience can change, but the general process is:

Sign in to Microsoft Foundry.
Open the appropriate Foundry administration or resource configuration area.
Open the AI Gateway configuration.
Select Add AI Gateway.
Select the Foundry resource to associate with the gateway.
Select an existing API Management instance or create one if supported.
Confirm the required permissions and networking configuration.
Save the association.
Add or import models, agents, or eligible tools.
Configure API Management policies.
Test requests through the gateway.
Verify telemetry and policy enforcement.

The Microsoft Foundry portal provides an integrated configuration experience, while advanced policies and networking settings are managed in Azure API Management.

Importing Models into the AI Gateway

Azure API Management can import models from supported providers, including Microsoft Foundry and Azure OpenAI.

When importing a model, the administrator typically configures:

The model provider.
The backend endpoint.
The model or deployment name.
The API format.
Authentication.
Required headers.
Backend routing.
Policies.
Monitoring settings.

For Microsoft Foundry deployments, the import wizard can discover deployments automatically in supported scenarios.

OpenAI-compatible APIs

Many applications are designed to use the OpenAI API format. API Management can expose supported backends through OpenAI-compatible routes.

For example, an OpenAI-compatible model endpoint may use a route similar to:

/default/models/openai/v1/chat/completions

The exact gateway URL and route depend on the API Management configuration and the provider API format.

The important exam concept is that the client can use a consistent gateway endpoint while API Management handles the connection to the underlying model backend.

Authentication Options

Authentication must be configured separately for:

The client calling the gateway.
The gateway calling the backend.

These are not necessarily the same authentication mechanism.

Client-to-gateway authentication

The client may authenticate to API Management using:

An API Management subscription key.
Microsoft Entra authentication.
OAuth.
Another supported API authentication method.

For example, a client may send an API Management subscription key in a header expected by the API definition or policy.

Gateway-to-backend authentication

The gateway can authenticate to AI backends using:

Managed identity.
API keys.
Provider-specific credentials.
Other supported authentication mechanisms.

Managed identity is often preferable because it avoids embedding long-lived API keys in applications or configuration files. The managed identity must have the appropriate role or permissions on the backend.

Managed identity benefits

Using managed identity can:

Avoid storing API keys in application code.
Reduce credential rotation requirements.
Integrate with Microsoft Entra access control.
Support centralized identity governance.
Reduce the risk of accidental credential exposure.

However, managed identity does not automatically grant access. The identity must still be authorized on the target resource.

API Management Policies

API Management policies are XML-based rules that execute in the gateway.

Policies can operate on:

Inbound requests.
Backend requests.
Backend responses.
Outbound responses.
Errors.

They can validate, transform, secure, route, or limit API traffic. API Management policies are different from Azure Policy. API Management policies run at API request time, while Azure Policy evaluates and governs Azure resources.

Important AI Gateway policies

Rate limiting

Rate limiting restricts the number of requests a client can make during a defined period.

Example uses include:

Limiting requests per application.
Limiting requests per user.
Preventing excessive tool calls.
Protecting backend capacity.
Reducing abuse.

A rate-limit-by-key policy can use a key such as:

Client IP address.
Subscription key.
Application identifier.
User identifier.
Custom request value.

The key should be selected carefully. IP-based limiting may be inappropriate when many users share the same outbound address.

Token quotas

AI model consumption is often measured in tokens rather than only requests.

Token quotas can help control:

Cost.
Capacity.
Fair usage.
Project-level consumption.
Large prompt abuse.
Excessive response generation.

A request-per-minute limit alone may not prevent a client from sending extremely large prompts. Token-based controls are therefore important for AI workloads.

IP filtering

IP filtering can restrict requests to trusted networks or addresses.

For example, an organization may allow gateway access only from:

Corporate networks.
Private application subnets.
Approved build environments.
Trusted automation services.

IP filtering should not be treated as a replacement for identity-based authentication. Network location alone is not sufficient to establish who is authorized to use an AI service.

Authentication and authorization

Policies can validate tokens, inspect claims, and enforce access rules.

For example, a policy may:

Validate a Microsoft Entra token.
Check the token audience.
Restrict access to specific application IDs.
Require a subscription key.
Reject unauthenticated requests.
Route different consumers to different backends.

Content safety

API Management can apply policies that integrate with Azure AI Content Safety to moderate prompts or responses.

Content safety controls may help detect or block content such as:

Hate.
Violence.
Sexual content.
Self-harm content.
Other unsafe material, depending on the configured policy and service capabilities.

Content safety is not a complete AI security solution. It should be combined with identity, authorization, data protection, logging, and runtime controls.

Correlation IDs

A correlation ID allows related requests to be traced across systems.

A gateway can add a unique identifier to a request so that administrators can correlate:

Client requests.
Gateway logs.
Backend requests.
Application logs.
Security investigations.

Correlation IDs are particularly useful when an application invokes multiple models or tools during one user interaction.

Request and response transformation

Policies can modify requests or responses, including:

Headers.
URLs.
Query parameters.
Payloads.
Backend routing.
Response formatting.

Transformations should be used carefully with AI APIs because changing required headers or payload structures can cause model or tool calls to fail.

Governing MCP Tools

The Model Context Protocol allows agents to interact with external tools and data sources.

Examples of MCP tools include:

Search tools.
File access tools.
Database tools.
Business application tools.
Automation tools.
Custom enterprise tools.

Routing MCP traffic through an AI Gateway provides a centralized point for:

Authentication.
Rate limiting.
IP restrictions.
Audit logging.
Routing.
Policy enforcement.

The gateway can apply controls without requiring changes to the MCP server or agent code.

Important MCP limitations

For the Foundry-integrated MCP gateway experience:

The feature is in preview.
Only eligible MCP tools are routed through the gateway.
Existing tools may not be automatically migrated.
Tools using managed OAuth may not be eligible for the same routing flow.
API Management policies are configured in Azure API Management.
Gateway logs may not contain complete tool-level traces.
MCP server logs may still be required for detailed tool investigation.

If a tool was created before the gateway was connected, it may continue to call the MCP server directly. In that situation, recreate the tool after the gateway is connected if the tool is eligible for gateway routing.

Monitoring and Observability

An AI Gateway provides a central location for monitoring AI traffic.

Useful telemetry may include:

Request counts.
Response codes.
Latency.
Backend failures.
Token usage.
Rate-limit events.
Authentication failures.
Policy violations.
Correlation IDs.
Model or backend usage.
Gateway errors.

Telemetry can be viewed through API Management monitoring capabilities and, where configured, Microsoft Foundry or Application Insights.

Monitoring helps answer questions such as:

Which applications are using a model?
Which projects consume the most tokens?
Are requests being rejected?
Is a backend unavailable?
Are clients exceeding quotas?
Are unusual traffic patterns occurring?
Are policies blocking legitimate workloads?
Are sensitive tools being called unexpectedly?

Gateway telemetry should be combined with application, model, agent, and backend logs because the gateway may not capture every detail of an AI interaction.

Security Design Considerations

Use a single governed entry point

Where practical, route approved AI traffic through the gateway rather than allowing every application to call model endpoints directly.

This improves consistency and visibility.

Avoid exposing backend credentials

Prefer managed identity or centrally managed credentials rather than embedding API keys in application code.

Apply least privilege

The gateway’s identity should have only the permissions required to access the configured backend.

The client should also receive only the permissions required to call the gateway APIs.

Separate environments

Use separate configurations or gateways for:

Development.
Testing.
Staging.
Production.

This helps prevent development applications from accessing production models or sensitive tools.

Apply quotas by project or consumer

Quotas should reflect business requirements. A shared global quota may allow one application to consume capacity needed by other teams.

Restrict sensitive tools

Tools that can:

Modify databases.
Send email.
Change permissions.
Deploy resources.
Access confidential data.
Execute commands.

should receive stronger controls than read-only tools.

Protect private backends

If a Foundry resource is private, ensure the gateway has appropriate private connectivity. Do not assume that associating the resources automatically solves networking requirements.

Test policies before enforcement

Use testing and staged rollout to ensure that policies do not:

Remove required authentication headers.
Break model payloads.
Block legitimate clients.
Prevent required tool calls.
Cause unexpected latency.
Interfere with streaming responses.

Example Scenario

A company has three AI applications:

A customer-service assistant.
A financial reporting application.
An internal research assistant.

Each application currently calls a model endpoint directly.

The security team deploys Azure API Management as an AI Gateway and configures:

Microsoft Entra authentication for approved applications.
Managed identity authentication from the gateway to the model backend.
Separate API products or subscriptions for each application.
Token quotas for each project.
Rate limits to prevent excessive requests.
IP restrictions for internal applications.
Content safety checks.
Correlation IDs for tracing.
Monitoring and alerts for failures and abnormal usage.

The financial reporting application receives a lower quota but stronger access restrictions because it processes sensitive information. The research assistant is allowed to use several approved models but cannot access production business tools.

This design provides centralized security while allowing different applications to have different access and usage policies.

Common Exam Comparisons

Capability	Primary purpose
Azure API Management AI Gateway	Govern and secure traffic to AI models, agents, and tools
Microsoft Foundry	Develop, deploy, and operate AI resources
Microsoft Entra ID	Authenticate identities and authorize access
Managed identity	Provide Azure-managed authentication without embedded credentials
API Management policy	Apply runtime request and response controls
Azure Policy	Govern Azure resource configuration and compliance
Azure AI Content Safety	Detect or moderate unsafe content
Application Insights	Monitor application and gateway-related telemetry
Microsoft Sentinel	Centralize security events and investigation workflows
Agent identity	Represent an AI agent as an identity
MCP server	Expose tools or context to compatible AI clients

Exam Tips

Remember these key points:

An AI Gateway is implemented using Azure API Management capabilities.
The gateway is a control point between AI consumers and AI backends.
It can govern models, agents, and eligible MCP tools.
The gateway is not a replacement for Microsoft Entra authentication.
Client-to-gateway authentication and gateway-to-backend authentication are separate concerns.
Managed identity can reduce the need to store backend API keys.
API Management policies are runtime rules, not Azure Policy definitions.
Rate limits control request volume; token quotas control AI consumption.
Content safety policies address unsafe content but do not replace identity security.
Existing MCP tools may not automatically begin using a newly connected gateway.
API Management policies are configured in API Management, not necessarily in the Foundry portal.
Private Foundry resources require compatible private connectivity from the gateway.
Preview features may have changing capabilities, limits, and supported regions.
Monitoring should include gateway telemetry and backend or application logs.
Always verify that traffic actually passes through the gateway after configuration.

Practice Exam Questions

Question 1

What is the primary purpose of using Azure API Management as an AI Gateway for Microsoft Foundry?

A. To replace Microsoft Entra ID
B. To train foundation models
C. To provide a centralized point for securing, governing, and monitoring AI traffic
D. To permanently store model training data

Answer: C

Explanation: An AI Gateway provides a centralized control point between AI consumers and backends. It can enforce authentication, quotas, rate limits, routing, monitoring, and other policies. It does not replace Microsoft Entra ID or train models.

Question 2

An organization wants the AI Gateway to authenticate to a Microsoft Foundry backend without storing an API key in application code. Which option should it consider?

A. Managed identity
B. Azure resource lock
C. Public IP address filtering only
D. A storage account access key

Answer: A

Explanation: Managed identity allows the gateway to authenticate to supported Azure services without embedding long-lived credentials in application code. The identity must still be granted the required permissions on the backend.

Question 3

Which statement correctly describes Azure API Management policies?

A. They are Azure resource-compliance definitions evaluated by Azure Policy
B. They are runtime rules that can validate, transform, secure, limit, or route API requests and responses
C. They are Microsoft Entra role assignments
D. They are model-training instructions

Answer: B

Explanation: API Management policies execute in the gateway and can control inbound requests, backend requests, responses, and errors. They are different from Azure Policy, which governs Azure resource configuration.

Question 4

A company wants to prevent one Foundry project from consuming all available model capacity. Which control is most directly relevant?

A. Azure Bastion
B. Microsoft Entra access reviews
C. Token quotas
D. Azure resource locks

Answer: C

Explanation: Token quotas limit AI consumption based on token usage. They are useful for cost control, capacity management, and preventing one project from monopolizing model capacity.

Question 5

An administrator connects an AI Gateway to a Foundry resource. An MCP tool created several weeks earlier continues to call the MCP server directly. What is the most likely explanation?

A. API Management cannot govern MCP tools
B. The tool must be recreated after the gateway is connected if it is eligible for gateway routing
C. The Foundry resource must be deleted
D. The MCP server must be converted into a virtual machine

Answer: B

Explanation: In the preview Foundry MCP gateway integration, gateway routing is applied when eligible tools are created after the gateway is connected. Existing tools are not automatically migrated.

Question 6

Which control is most appropriate for restricting AI Gateway requests to approved corporate networks?

A. IP filtering
B. Token quota
C. Model fine-tuning
D. Agent blueprint inheritance

Answer: A

Explanation: IP filtering can allow or deny requests based on source IP addresses or ranges. It should supplement, not replace, identity-based authentication and authorization.

Question 7

An organization wants to trace a request from an application through API Management to the model backend. Which feature is most useful?

A. Azure resource locks
B. Correlation IDs
C. Disk encryption
D. Azure Policy remediation

Answer: B

Explanation: Correlation IDs provide a common identifier that can be recorded in gateway, application, and backend logs, making it easier to trace a request across multiple components.

Question 8

A Foundry resource has public network access disabled. What must be verified before associating it with an AI Gateway?

A. The gateway has an appropriate private network path to the Foundry resource
B. The model has been fine-tuned
C. All clients use anonymous access
D. The gateway is deployed outside Azure

Answer: A

Explanation: A private Foundry resource requires compatible private connectivity from the API Management instance. The gateway must be able to reach the backend through the required private networking configuration.

Question 9

Which statement best describes the difference between rate limiting and token quotas?

A. Rate limiting controls request volume, while token quotas control AI token consumption
B. Rate limiting authenticates users, while token quotas encrypt traffic
C. Rate limiting governs Azure resources, while token quotas manage virtual machines
D. Rate limiting disables models, while token quotas create agents

Answer: A

Explanation: Rate limiting restricts the number of requests over a period. Token quotas restrict the amount of model consumption, which is important because requests can vary greatly in prompt and response size.

Question 10

An administrator applies an API Management policy that removes a required authentication header before forwarding the request to an MCP server. What is the likely result?

A. The MCP server automatically repairs the header
B. The request is converted into a model-training job
C. The request may fail because required authentication information was removed
D. The gateway automatically grants anonymous access

Answer: C

Explanation: API Management policies can modify headers, but removing a required authentication header can cause the backend or MCP server to reject the request. Policies must be tested carefully to avoid breaking required authentication and protocol behavior.

Final Exam Point

A very important exam theme is that Azure API Management provides the enforcement and governance layer, while Microsoft Foundry provides the AI resource and application environment. Together, they allow organizations to centralize access control, usage management, monitoring, and security for AI workloads.

Go to the SC-500 Exam Prep Hub main page

AI Governance, AI Security, Microsoft Certification, SC-500, security October 10, 2026

Enable Defender for AI Service in Cloud Workload Protection in Defender for Cloud (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 AI
      --> Enable Defender for AI Service in Cloud Workload Protection in Defender for Cloud

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

Artificial intelligence workloads can introduce security risks that are different from those associated with traditional applications. Examples include unauthorized access to AI services, suspicious model usage, abuse of AI endpoints, anomalous activity, and attacks against applications that consume Azure AI services.

Microsoft Defender for AI Services is a workload protection capability in Microsoft Defender for Cloud designed to detect threats targeting Azure AI services workloads. It complements identity controls, network security, data protection, AI guardrails, and security posture management.

This topic is part of the Secure compute → Implement security for AI area of the SC-500 exam.

What Is Defender for AI Services?

Defender for AI Services provides security monitoring and threat protection for supported Azure AI services workloads. It is part of the broader Cloud Workload Protection Platform capabilities in Microsoft Defender for Cloud.

Its purpose is to help security teams:

Detect suspicious activity involving Azure AI services.
Identify potential threats targeting AI service resources.
Investigate security alerts in the Microsoft Defender portal.
Review AI security posture and coverage.
Combine AI workload protection with broader Defender for Cloud capabilities.
Correlate AI-related security information with other incidents and alerts.

Defender for AI Services is not a replacement for Microsoft Foundry guardrails, Azure AI Content Safety, Microsoft Entra ID, Azure Policy, or network controls. Instead, it adds a security monitoring and threat-detection layer to the AI workload.

AI Workload Security: Posture Versus Runtime Protection

A key exam concept is the difference between security posture management and runtime threat protection.

Cloud Security Posture Management

Cloud Security Posture Management, or CSPM, focuses on identifying and reducing configuration risks before they result in an incident.

Examples include:

An AI service that permits unnecessary public network access.
Local authentication being enabled when Microsoft Entra authentication should be used.
Excessive permissions assigned to an application or identity.
Missing security configuration or governance controls.
Resources that do not comply with organizational policies.

Cloud Workload Protection

Cloud Workload Protection, or CWP, focuses on detecting threats and suspicious behavior while workloads are operating.

Examples include:

Suspicious activity targeting an AI service.
Abnormal usage patterns.
Potential attempts to exploit an AI workload.
Threat indicators associated with an AI service resource.
Runtime activity that requires investigation.

Microsoft Defender for Cloud combines discovery, posture management, and runtime protection to provide broader visibility into AI environments.

Exam distinction

If a question asks which capability identifies a misconfiguration, think primarily of CSPM.

If it asks which capability detects a threat or suspicious activity during operation, think primarily of CWP, including Defender for AI Services.

Supported AI Workload Context

The learning material specifically associates this capability with Azure AI services workloads, including services such as:

Azure OpenAI-related workloads.
Microsoft Foundry and AI service resources.
AI model deployments and related service endpoints.
Applications that consume Azure AI services.

The exact supported resource types and detections can change as Microsoft expands the service. Therefore, organizations should verify current service coverage and supported regions before designing a production deployment.

Defender for AI Services should be considered part of a layered security architecture rather than a single control that secures every component of an AI solution.

Prerequisites

Before enabling Defender for AI Services, administrators should have:

An Azure subscription containing the AI workloads to protect.
Microsoft Defender for Cloud enabled for the subscription.
Appropriate permissions to configure Defender for Cloud plans.
Familiarity with Azure AI services and model deployments.
Familiarity with the Azure portal and Microsoft Defender portal.

The associated Microsoft Learn module identifies an Owner or Contributor role on the target subscription as a prerequisite for the configuration exercise. In production environments, organizations should use the least-privileged role that provides the required administrative capability.

Enable Defender for AI Services

The plan is enabled from the Defender for Cloud environment settings.

Step 1: Open Microsoft Defender for Cloud

Sign in to the Azure portal.
Search for and open Microsoft Defender for Cloud.
Select Environment settings.

Step 2: Select the subscription

Select the Azure subscription that contains the AI workloads.
Review the available Defender for Cloud plans.

Defender for Cloud plans can be enabled at the subscription level. Enabling a plan at subscription scope generally applies the protection to applicable resources within that subscription.

Step 3: Enable the AI Services plan

Locate the plan for Defender for AI Services.
Turn the plan on.
Review any available plan-specific configuration options.
Select Save.

The exact portal labels and available configuration options may change as the service evolves. The important exam concept is that Defender for AI Services is enabled as a Defender for Cloud workload protection plan, rather than by installing a traditional agent on each AI service resource.

Configure Plan Components

After enabling the plan, review its available components and configuration settings.

Depending on the current service capabilities, configuration may include:

Selecting which AI workloads are covered.
Reviewing supported AI service resource types.
Enabling or disabling available protection components.
Configuring notification and monitoring integrations.
Reviewing the subscription’s protection status.
Confirming that the required security data is available.

Microsoft continuously adds capabilities to Defender for Cloud plans. Azure Policy includes a built-in initiative named Configure Microsoft Defender threat protection for AI Services to be enabled, which can help ensure that newly created or existing subscriptions remain configured according to organizational requirements.

Important distinction

The Defender for AI Services plan provides the protection capability. Azure Policy can help enforce or audit the desired configuration.

These are different functions:

Capability	Primary purpose
Defender for AI Services	Detect threats targeting AI services workloads
Azure Policy	Audit or enforce resource configuration
Microsoft Defender for Cloud CSPM	Identify security posture weaknesses
Microsoft Foundry guardrails	Apply controls to AI inputs, outputs, and model behavior
Microsoft Entra ID	Authenticate and authorize users, applications, and identities
Private Link and network controls	Reduce network exposure

Monitor AI Security with the Data and AI Security Dashboard

After the plan is enabled, use the Data and AI security dashboard in Microsoft Defender for Cloud to review AI security information.

The dashboard is intended to provide visibility into areas such as:

AI resources discovered in the environment.
Security posture information.
Protection coverage.
Security recommendations.
AI-related alerts and findings.
Potential risks affecting AI workloads.

The dashboard helps security teams understand whether AI resources are being protected and where additional action may be required.

Recommended monitoring process

Review the AI resource inventory.
Confirm that expected subscriptions and resources are represented.
Review recommendations and unresolved security issues.
Investigate active alerts.
Determine whether the issue is a configuration problem, an identity problem, a network problem, or a runtime threat.
Remediate the issue.
Confirm that the resource returns to the expected protection state.

Investigate AI Threat Protection Alerts

Defender for AI Services can generate security alerts when suspicious activity associated with supported AI workloads is detected.

When investigating an alert, review:

The affected subscription.
The affected AI service or resource.
The alert severity.
The detection time.
The activity associated with the alert.
The identity or application involved, when available.
Related resources and incidents.
Recommended remediation actions.

AI-related alerts can be investigated through the Microsoft Defender portal. Defender for Cloud alerts can also integrate with Microsoft Defender XDR, allowing security operations teams to correlate cloud alerts with identity, endpoint, email, and other security signals.

Example investigation workflow

A security analyst notices suspicious activity associated with an AI service.

Open the alert in the Defender portal.
Review the affected AI resource.
Examine the evidence and activity timeline.
Identify the application, identity, or network source involved.
Determine whether the activity is expected.
Disable or restrict a compromised identity if necessary.
Rotate exposed credentials.
Review network access and authentication configuration.
Investigate related resources and incidents.
Document the remediation and verify that the threat is no longer present.

Relationship to Other AI Security Controls

Defender for AI Services should be deployed as part of defense in depth.

Microsoft Entra ID

Use Microsoft Entra ID to control who or what can access AI services.

Recommended controls include:

Microsoft Entra authentication.
Managed identities.
Role-based access control.
Conditional Access where applicable.
Least-privilege permissions.
Removal of unnecessary credentials.

Defender for AI Services may detect suspicious activity, but it does not replace proper identity configuration.

Azure AI Content Safety and Foundry Guardrails

Guardrails help control unsafe or undesirable AI inputs and outputs. They address risks such as:

Harmful content.
Prompt-based abuse.
Inappropriate model responses.
Content filtering requirements.
Certain application-level AI risks.

Runtime threat protection and AI guardrails address different security concerns. A workload can have guardrails configured and still require threat monitoring.

Azure Policy

Azure Policy can audit or enforce requirements such as:

AI services should have local authentication disabled.
AI services should restrict network access.
Defender for AI Services should be enabled.

For example, Microsoft provides policy definitions related to disabling key-based access and restricting network access for Azure AI Services resources.

Network security

Network controls can reduce exposure by using:

Private endpoints.
Virtual network integration where supported.
Network access restrictions.
Firewall rules.
Private DNS configuration.
Restricted administrative access.

Network restrictions reduce the attack surface, while Defender for AI Services helps detect threats against the workload.

Microsoft Defender XDR

Defender XDR can provide a broader incident investigation experience by correlating AI workload alerts with other security signals.

Subscription-Level Enablement and Scale

Defender for Cloud plans are commonly configured at subscription scope. Organizations with many subscriptions should consider centralized governance.

Possible approaches include:

Enabling the plan on individual subscriptions.
Using management groups to organize subscriptions.
Applying Azure Policy initiatives.
Auditing plan coverage.
Reviewing coverage workbooks.
Establishing a standard for newly created subscriptions.

The Defender for Cloud coverage workbook helps administrators understand which plans are enabled across subscriptions and resources.

Why centralized governance matters

Without centralized governance, an organization may have:

AI resources deployed in subscriptions without protection.
Inconsistent security configurations.
Newly created resources that are not covered.
Different teams using different security standards.
Gaps between development, test, and production environments.

Azure Policy can help maintain consistency, but policy compliance should be verified rather than assumed.

Common Troubleshooting Issues

The plan is not visible

Possible causes include:

The wrong subscription or environment was selected.
The user lacks sufficient permissions.
The capability is not available in the selected region.
The service or plan name has changed.
The feature is subject to preview or availability limitations.

AI resources are not appearing in the dashboard

Check:

Whether the correct subscription is selected.
Whether the plan is enabled.
Whether the resource type is supported.
Whether the resource is in a supported region.
Whether sufficient time has passed for discovery and data collection.
Whether the resource is excluded by configuration or policy.

Alerts are not appearing

Check:

Whether the plan is enabled for the correct subscription.
Whether the activity matches a supported detection.
Whether the resource is covered.
Whether the alert is being viewed in the correct portal.
Whether filters are hiding the alert.
Whether the issue is a posture recommendation rather than a runtime alert.

A resource is secure but still has recommendations

This may occur because:

The recommendation has not refreshed.
The resource has another unresolved configuration issue.
A policy assignment requires a different setting.
The resource is evaluated against a broader security standard.
The recommendation applies to a different component of the workload.

Best Practices

Enable protection before production deployment

Do not wait until an AI service is compromised before enabling monitoring and threat protection.

Use least privilege

Assign only the permissions required to configure Defender for Cloud and manage AI resources.

Combine CSPM and CWP

Use CSPM to reduce misconfigurations and CWP to detect suspicious runtime activity.

Restrict network exposure

Use private endpoints and network restrictions where supported and appropriate.

Prefer Microsoft Entra authentication

Avoid unnecessary use of static keys. Use managed identities or Microsoft Entra authentication when supported.

Enforce configuration with Azure Policy

Use policy to audit or enforce requirements such as:

Defender for AI Services being enabled.
Local authentication being disabled.
Network access being restricted.

Monitor the Data and AI dashboard

Review coverage, recommendations, and alerts regularly.

Integrate with incident response

Ensure that AI security alerts are routed to the appropriate security operations team and correlated with other incidents.

Do not assume that one control solves every AI risk

AI security requires multiple layers, including:

Identity.
Network security.
Data protection.
Application security.
Guardrails.
Runtime threat detection.
Logging and monitoring.
Governance and compliance.

Exam-Focused Comparisons

Exam concept	Correct interpretation
Defender for AI Services	Runtime threat protection for supported Azure AI services workloads
AI workloads plan	Defender for Cloud plan used to protect AI workloads
Data and AI security dashboard	View AI security posture, resources, and protection information
CSPM	Identifies configuration and posture weaknesses
CWP	Detects threats and suspicious runtime activity
Azure Policy	Audits or enforces Azure resource configuration
Foundry guardrails	Controls AI behavior, inputs, and outputs
Microsoft Entra ID	Provides authentication and authorization
Defender XDR	Correlates and investigates security signals across workloads
Coverage workbook	Helps verify Defender for Cloud plan coverage

Practice Exam Questions

Question 1

An organization uses Azure AI services for a customer-support application. The security team wants to detect suspicious activity targeting the AI service while the application is running. Which capability should the team enable?

A. Azure Policy
B. Microsoft Defender for AI Services
C. Microsoft Entra Privileged Identity Management
D. Azure Resource Manager locks

Answer: B

Explanation: Microsoft Defender for AI Services is designed to detect threats targeting supported Azure AI services workloads. Azure Policy governs configuration, PIM manages privileged access, and resource locks help prevent accidental deletion or modification.

Question 2

Where should an administrator go to enable Defender for AI Services for an Azure subscription?

A. Microsoft Foundry project settings
B. Azure Monitor Workbooks
C. Microsoft Defender portal Incidents page
D. Microsoft Defender for Cloud Environment settings

Answer: D

Explanation: Defender for Cloud workload protection plans are enabled through Microsoft Defender for Cloud → Environment settings, where the administrator selects the appropriate subscription and enables the required plan.

Question 3

A security engineer wants to identify an AI service that has an insecure configuration, such as unnecessary public network access. Which Defender for Cloud capability is most directly relevant?

A. Cloud Security Posture Management
B. Cloud Workload Protection
C. Microsoft Defender XDR incident correlation
D. Azure Bastion

Answer: A

Explanation: CSPM identifies configuration weaknesses and security posture risks. CWP focuses on runtime threats, Defender XDR supports investigation and correlation, and Azure Bastion provides secure administrative access to virtual machines.

Question 4

After enabling Defender for AI Services, which feature should an administrator use to review AI resource insights, security posture, and protection information?

A. Azure Service Health
B. Azure Advisor only
C. Data and AI security dashboard
D. Azure Cost Management

Answer: C

Explanation: The Data and AI security dashboard in Defender for Cloud provides visibility into AI resources, security posture, and related protection information.

Question 5

An organization wants to ensure that Defender for AI Services remains enabled across newly created subscriptions. Which approach is most appropriate?

A. Configure a resource lock on every AI service
B. Create a custom Microsoft Entra authentication method
C. Enable Azure Bastion
D. Use Azure Policy to audit or deploy the required Defender for AI Services configuration

Answer: D

Explanation: Azure Policy can help audit or enforce the desired Defender for Cloud plan configuration across a defined scope. Resource locks, authentication methods, and Bastion do not ensure that the Defender for AI Services plan is enabled.

Question 6

Which statement best describes the relationship between Defender for AI Services and Microsoft Foundry guardrails?

A. Defender for AI Services replaces all Foundry guardrails
B. Defender for AI Services detects workload threats, while guardrails help control AI inputs, outputs, and behavior
C. Foundry guardrails are used only to enable Azure subscriptions
D. Defender for AI Services is required only for virtual machines

Answer: B

Explanation: These controls address different risks. Defender for AI Services provides workload threat protection, while Foundry guardrails help manage AI behavior and content-related risks.

Question 7

A security analyst receives an alert involving suspicious activity against an Azure AI service. Where should the analyst investigate the alert?

A. Microsoft Defender portal
B. Azure Storage Explorer
C. Azure Resource Graph only
D. Microsoft Entra Domain Services

Answer: A

Explanation: Defender for AI Services alerts can be investigated in the Microsoft Defender portal. Defender for Cloud alerts can also integrate with Microsoft Defender XDR for broader correlation and investigation.

Question 8

Which statement about Defender for AI Services is correct?

A. It eliminates the need for identity and network controls
B. It encrypts every prompt and model response automatically
C. It provides runtime threat protection for supported Azure AI services workloads
D. It is an Azure resource lock mechanism

Answer: C

Explanation: Defender for AI Services is a workload protection capability. It does not replace authentication, authorization, encryption, network restrictions, or other defense-in-depth controls.

Question 9

An administrator enables Defender for AI Services but does not see a particular AI resource in the dashboard. What should the administrator check first?

A. Whether the resource is supported, in the correct subscription, and in a supported region
B. Whether the resource has an Azure Bastion host
C. Whether the resource has a resource lock
D. Whether the application uses a virtual machine scale set

Answer: A

Explanation: Missing resource visibility can result from unsupported resource types, incorrect subscription selection, regional availability, or discovery delays. Bastion, resource locks, and VM scale sets are not prerequisites for discovering an AI service resource.

Question 10

Which combination provides the most complete defense-in-depth approach for an Azure AI workload?

A. Resource locks and Azure Cost Management
B. Azure Bastion and storage replication
C. Azure Policy only
D. Microsoft Entra authentication, network restrictions, AI guardrails, Defender for Cloud posture management, and Defender for AI Services runtime protection

Answer: D

Explanation: AI workloads require multiple complementary controls. Identity protects access, network restrictions reduce exposure, guardrails address AI behavior, CSPM identifies configuration weaknesses, and Defender for AI Services detects runtime threats.

Key Takeaways

For the SC-500 exam, remember the following:

Defender for AI Services is a Defender for Cloud workload protection capability.
It focuses on detecting threats targeting supported Azure AI services workloads.
Enable it through Microsoft Defender for Cloud → Environment settings.
Use the Data and AI security dashboard to monitor AI security information.
Investigate alerts in the Microsoft Defender portal.
Use CSPM for configuration and posture risks.
Use CWP for runtime threat detection.
Use Azure Policy to audit or enforce plan configuration.
Defender for AI Services complements—not replaces—identity, network, guardrail, and data security controls.
Treat AI security as a defense-in-depth responsibility rather than a single-product task.