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:

1. Azure virtual network.
2. Private endpoint.
3. Private IP address.
4. Private DNS configuration.
5. Target PaaS resource.
6. 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:

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

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:

1. A route to the private endpoint IP address.
2. 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:

1. Create and validate the private endpoint.
2. Confirm that private DNS and routing work.
3. Restrict or disable public network access.
4. 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:

1. Open the target PaaS resource.
2. Navigate to its networking or private endpoint configuration.
3. Select Private endpoint connections or Private endpoints.
4. Select Create.
5. Choose the subscription and resource group.
6. Provide a private endpoint name.
7. Select the target region.
8. Select the target resource.
9. Select the appropriate target subresource.
10. Choose the virtual network and subnet.
11. Configure private DNS integration.
12. Review the configuration.
13. Create the private endpoint.
14. Approve the connection if approval is required.
15. 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

The exact zone depends on the service and subresource.

Recommended Azure DNS Integration

For many Azure-only deployments:

1. Create the private endpoint.
2. Select integration with an Azure Private DNS zone.
3. Create or select the appropriate private DNS zone.
4. Link the zone to the virtual network.
5. 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:

1. Create the private endpoint.
2. Configure private DNS.
3. Validate access from the intended virtual network.
4. Validate access from on-premises if applicable.
5. Disable public network access or restrict it with service firewall rules.
6. Confirm that public access is denied.
7. 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:

1. The application can resolve the Key Vault FQDN to the private endpoint IP.
2. The application can route to the private endpoint.
3. Public access to the Key Vault is restricted or disabled.
4. The application’s managed identity has the required Key Vault data-plane permissions.
5. 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