Tag: Azure Network Services

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, 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, Cybersecurity, Microsoft Certification, SC-500, security October 10, 2026October 10, 2026

Implement and configure Azure Firewall (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 Azure Firewall

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

Azure Firewall is used to centrally inspect and control network traffic entering, leaving, and moving between Azure networks. The exam focus includes deploying Azure Firewall, configuring firewall policies and rules, routing traffic through the firewall, enabling threat protection, and selecting the appropriate firewall SKU.

What is Azure Firewall?

Azure Firewall is a fully stateful, managed network security service for Azure. It provides centralized traffic filtering and inspection without requiring the organization to deploy and maintain firewall virtual machines.

Azure Firewall can inspect:

North-south traffic, such as traffic entering or leaving Azure.
East-west traffic, such as traffic moving between Azure virtual networks or subnets.
Layer 3 and Layer 4 traffic using network rules.
Layer 7 application traffic using application rules.
Inbound traffic using destination network address translation (DNAT).
Traffic associated with known malicious IP addresses and domains through threat intelligence filtering.

Azure Firewall includes built-in high availability and automatically scales within the limits of the selected SKU and deployment architecture.

Azure Firewall deployment models

Azure Firewall can be deployed in two primary architectures.

Hub virtual network deployment

In a hub-and-spoke architecture:

Azure Firewall is deployed in a central hub virtual network.
Spoke virtual networks contain application workloads.
User-defined routes direct traffic from the spokes to the firewall.
The firewall inspects the traffic before forwarding it to the destination.

A common design is:

			
Spoke VNet A
    |
    | User-defined route
    v
Hub VNet
Azure Firewall
    |
    v
Internet, on-premises, or another VNet

		

This model is useful when an organization wants centralized security controls for multiple virtual networks.

Secured virtual hub deployment

Azure Firewall can also be deployed in an Azure Virtual WAN secured virtual hub.

In this model:

Virtual WAN provides the hub networking architecture.
Azure Firewall provides centralized inspection.
Virtual WAN routing capabilities simplify traffic forwarding.
Azure Firewall Manager can centrally manage policies across secured virtual hubs.

A secured virtual hub is useful for larger environments that require centralized connectivity and security across branches, virtual networks, and hybrid locations.

Azure Firewall subnet requirements

For a traditional virtual network deployment, Azure Firewall must be placed in a dedicated subnet named:

AzureFirewallSubnet

The subnet must be at least /26. The subnet should not contain other resources.

The firewall subnet should be treated as an infrastructure subnet rather than an application subnet. Workload route tables should normally be associated with workload subnets, not with the firewall subnet, unless a documented forced-tunneling design requires otherwise.

Example hub virtual network

			
Hub VNet: 10.0.0.0/16
AzureFirewallSubnet: 10.0.0.0/26
GatewaySubnet:        10.0.1.0/27
Management subnet:    10.0.2.0/24

The actual address ranges depend on the organization’s network plan. The important exam concepts are that the firewall requires a dedicated subnet and that the subnet must provide sufficient address space.

Azure Firewall SKUs

Azure Firewall is available in three SKUs:

Basic
Standard
Premium

Azure Firewall Basic

Basic is intended for smaller environments with simpler requirements.

Important characteristics include:

Designed for small and medium-sized businesses.
Recommended for environments with estimated throughput up to approximately 250 Mbps.
Fixed scale capacity.
Threat intelligence alert mode only.
Does not provide the complete feature set available in Standard and Premium.

Azure Firewall Standard

Standard provides:

Stateful Layer 3–Layer 7 filtering.
Network and application rules.
Threat intelligence filtering.
Threat intelligence alert and deny mode.
Web categories.
FQDN filtering.
Centralized firewall policy management.

Azure Firewall Premium

Premium provides the advanced capabilities of Standard plus features such as:

Intrusion detection and prevention system (IDPS).
TLS inspection.
URL filtering.
Additional advanced threat protection capabilities.

Premium should be selected when the organization needs deeper inspection of encrypted traffic or advanced signature-based threat detection.

SKU selection summary

Requirement	Appropriate choice
Small environment with basic firewall requirements	Basic
Standard centralized network and application filtering	Standard
Threat intelligence alert and deny mode	Standard or Premium
IDPS	Premium
TLS inspection	Premium
Advanced URL filtering	Premium
Web categories	Standard or Premium

The exact available features and limitations should always be checked against the current SKU comparison because Azure Firewall capabilities can change.

Azure Firewall versus network security groups

Azure Firewall and network security groups (NSGs) provide different types of protection.

Feature	Azure Firewall	Network security group
Scope	Centralized network security service	Subnet or network interface
Inspection	Layer 3–Layer 7, depending on rule type	Primarily Layer 3–Layer 4
FQDN filtering	Supported	Not a general equivalent
Centralized policy	Supported	Distributed across subnets and interfaces
Threat intelligence	Supported	Not built in as a comparable firewall feature
Application rules	Supported	Not supported
DNAT	Supported	Not supported
Typical purpose	Centralized inspection and egress/inbound control	Basic segmentation and traffic filtering

NSGs should still be used for subnet and network-interface-level segmentation. Azure Firewall should be used when centralized inspection, application filtering, threat intelligence, or DNAT is required.

These services are complementary rather than mutually exclusive.

Azure Firewall rule types

Azure Firewall policies organize rules into three main categories:

DNAT rules
Network rules
Application rules

DNAT rules

DNAT rules control inbound traffic arriving through a firewall public IP address.

A DNAT rule translates a public destination IP address and port into a private destination IP address and port.

For example:

			
Internet client
    |
    | Firewall public IP: 203.0.113.10:443
    v
Azure Firewall DNAT
    |
    | Translated destination: 10.2.1.10:443
    v
Internal web server

		

DNAT rules are useful when publishing an internal application through a firewall public IP address.

A DNAT rule normally specifies:

Source address.
Destination firewall public IP.
Destination port.
Protocol.
Translated destination address.
Translated destination port.

DNAT should be used carefully because it creates an inbound access path into the network. The organization should restrict source addresses whenever possible and ensure that the destination application has its own authentication and authorization controls.

Network rules

Network rules operate at the network and transport layers.

They can filter traffic based on:

Source IP address.
Destination IP address.
Source IP group.
Destination IP group.
Protocol.
Destination port.
Fully qualified domain name, where supported with the appropriate DNS configuration.

Typical examples include:

Allowing TCP traffic from an application subnet to a database server on port 1433.
Allowing UDP DNS traffic to an approved DNS server.
Allowing HTTPS traffic to a specific destination IP.
Blocking traffic between two application segments.

Network rules are appropriate when the requirement is based on IP addresses, ports, or protocols rather than the content or URL of an application request.

Application rules

Application rules operate at Layer 7 and can filter outbound or east-west traffic based on application-level information.

They can use:

HTTP.
HTTPS.
Fully qualified domain names.
URLs.
Web categories, depending on the SKU and configuration.

For example, an application rule can allow a workload to access:

https://api.contoso.com

while denying access to other internet destinations.

Application rules are useful for controlling web traffic based on the destination hostname rather than only on destination IP addresses.

Firewall policy structure

An Azure Firewall Policy is a top-level resource containing firewall security and operational settings.

The policy hierarchy is:

			
Firewall Policy
    |
    +-- Rule collection group
            |
            +-- Rule collection
                    |
                    +-- Individual rules

		

Rule collection groups

Rule collection groups are the first level processed by the firewall. They have priorities that determine their processing order.

The default rule collection groups are:

Rule collection group	Default priority
Default DNAT	100
Default Network	200
Default Application	300

Custom rule collection groups can be created with custom priorities. When custom groups are used to define processing logic, the organization should plan the priority order carefully and avoid creating confusing overlaps between default and custom groups.

Rule collections

A rule collection belongs to a rule collection group and contains rules of the same type.

Each rule collection has:

A collection type.
A priority.
An action, such as allow or deny.

The action applies to the rules in the collection.

Individual rules

Individual rules define the actual traffic conditions, such as:

Source.
Destination.
Protocol.
Port.
FQDN.
URL.
Web category.

Rules within a collection are evaluated in a top-down manner. If no rule allows the traffic, the traffic is denied by default.

Rule processing order

Azure Firewall processes traffic according to the firewall policy hierarchy.

At a high level:

Threat intelligence filtering is evaluated.
DNAT rules are processed for applicable inbound traffic.
Network rules are evaluated.
Application rules are evaluated.
Traffic that is not allowed is denied by default.

Threat intelligence rules are processed before NAT, network, and application rules.

The exact processing behavior can vary based on traffic type and rule configuration, so administrators should avoid relying only on the apparent order of rules in the portal. They should understand the rule collection group priorities and test the resulting behavior.

Default deny behavior

Azure Firewall uses a default-deny approach.

If traffic does not match an applicable allow rule, it is denied.

This supports a least-privilege network design:

Identify the required traffic.
Create narrowly scoped allow rules.
Avoid broad source and destination ranges.
Deny unnecessary traffic.
Monitor denied traffic.
Add exceptions only when justified.

A common mistake is to create a broad allow rule such as:

			
Source: Any
Destination: Any
Protocol: Any
Port: Any
Action: Allow

		

Such a rule defeats much of the value of centralized firewall filtering and should be avoided unless there is a carefully documented reason.

Threat intelligence filtering

Azure Firewall can use Microsoft threat intelligence feeds to identify traffic associated with known malicious:

IP addresses.
Fully qualified domain names.
URLs.

Threat intelligence can operate in different modes:

Off.
Alert only.
Alert and deny.

In alert-only mode, the firewall generates alerts but does not block the matching traffic.

In alert and deny mode, the firewall blocks matching traffic and generates alerts.

Basic supports alert mode only, while Standard and Premium support alert and deny mode. Threat intelligence rules are evaluated before NAT, network, and application rules.

Threat intelligence allowlist

False positives can occur. Azure Firewall supports an allowlist for approved IP addresses or ranges.

The allowlist should be managed carefully. Adding an address to the allowlist bypasses threat intelligence filtering for that address, so entries should be:

Justified.
Documented.
Reviewed periodically.
Removed when no longer required.

DNS proxy and FQDN filtering

FQDN-based filtering depends on reliable DNS resolution.

Azure Firewall can provide DNS proxy functionality so that clients use the firewall for DNS resolution. This helps ensure that the firewall and the client use consistent DNS answers when evaluating FQDN-based rules.

DNS proxy is especially important when:

Network rules use FQDNs.
Application rules depend on hostname resolution.
Private DNS zones are used.
DNS responses differ between clients and the firewall.
The organization uses custom DNS servers.

Without a consistent DNS design, a rule may appear correct but fail because the client or firewall resolves the destination differently.

Azure Firewall can also use:

FQDN tags for commonly required Azure and Microsoft services.
Service tags in network rules.
FQDN filtering in network rules when the required DNS proxy configuration is enabled.

Managed tags reduce the need to manually maintain changing Microsoft service IP ranges.

Routing traffic through Azure Firewall

Creating a firewall does not automatically cause all workload traffic to pass through it.

The organization must configure routing.

User-defined routes

In a hub-and-spoke architecture, a route table can direct traffic from a spoke subnet to the firewall’s private IP address.

For example:

			
Address prefix: 0.0.0.0/0
Next hop type: Virtual appliance
Next hop IP: Azure Firewall private IP

This route directs internet-bound traffic through the firewall.

Additional routes may be required for:

Traffic between spoke virtual networks.
Traffic to on-premises networks.
Traffic to other regions.
Traffic to private endpoints.
Forced-tunneling scenarios.

Important routing considerations

When configuring routes:

Avoid routing loops.
Ensure return traffic has a valid path.
Verify that peering settings support the intended architecture.
Confirm that the firewall can reach the destination.
Avoid associating workload routes with the firewall subnet unless required by the design.
Test both directions of communication.

A firewall rule cannot permit traffic that never reaches the firewall. Conversely, routing traffic through the firewall does not guarantee that the firewall will allow it.

Both routing and firewall policy must be correct.

Inbound traffic and DNAT

To publish an internal service through Azure Firewall:

Assign a public IP address to the firewall.
Create a DNAT rule.
Specify the public destination port.
Specify the private translated destination address.
Specify the translated destination port.
Ensure the backend application is reachable.
Restrict source addresses where possible.
Monitor the resulting traffic.

Example:

			
Public firewall IP: 203.0.113.20
Public port:        443
Private server IP:  10.2.1.20
Private port:       443
Protocol:           TCP

		

The firewall translates traffic destined for 203.0.113.20:443 to 10.2.1.20:443.

The backend server should not be considered secure merely because it is behind DNAT. It should still use:

Host-based firewall rules.
NSGs.
Secure configuration.
Application authentication.
TLS.
Patching.
Monitoring.

Outbound traffic and SNAT

Azure Firewall can perform source network address translation (SNAT) for outbound traffic.

This allows internal workloads to access external destinations through the firewall’s public IP address.

High-volume outbound workloads can exhaust available SNAT ports. To address this, organizations can consider:

Additional firewall public IP addresses.
Azure NAT Gateway integration, where supported by the deployment architecture.
NAT Gateway V2 for appropriate zone-redundant designs.

NAT Gateway should not be combined with secured virtual hub firewalls in architectures where that combination is unsupported. SNAT capacity should be planned based on the number of concurrent outbound connections and the behavior of the workloads.

Forced tunneling

Forced tunneling routes internet-bound traffic through an on-premises security appliance or another centralized inspection path instead of allowing the firewall to send it directly to the internet.

Forced tunneling may be required when:

Corporate security appliances must inspect internet traffic.
Internet access must originate from on-premises.
Regulatory requirements require centralized egress.
The organization uses a hybrid security architecture.

Azure Firewall forced tunneling uses a management network interface and a dedicated:

AzureFirewallManagementSubnet

This separates firewall management traffic from customer traffic.

Forced tunneling must be designed carefully because incorrect routes can interrupt firewall management or create routing loops.

TLS inspection

Azure Firewall Premium supports TLS inspection.

TLS inspection allows the firewall to decrypt, inspect, and re-encrypt supported encrypted traffic so that security controls can evaluate traffic that would otherwise remain encrypted.

TLS inspection requires:

Azure Firewall Premium.
Appropriate certificate configuration.
Certificate storage and management, commonly using Azure Key Vault.
Correct client trust configuration.
Careful handling of applications that use certificate pinning or do not support interception.

TLS inspection should be used only where justified because it introduces additional complexity and can affect privacy, compatibility, and performance.

Private connectivity alone does not make encrypted inspection unnecessary. If the security requirement is to inspect HTTPS content, TLS inspection or an equivalent application-layer control may be required.

IDPS in Azure Firewall Premium

Azure Firewall Premium includes a signature-based intrusion detection and prevention system.

IDPS can identify suspicious or malicious network activity using Microsoft-managed signatures.

Organizations can:

Detect known attack patterns.
Block high-confidence threats.
Tune signature behavior.
Investigate alerts.
Reduce false positives.
Monitor attack attempts against workloads.

IDPS is particularly useful when the organization needs more than basic IP, port, protocol, and hostname filtering.

Web categories and URL filtering

Azure Firewall Standard and Premium support web category filtering.

Web categories allow administrators to control access to groups of websites, such as:

Gambling.
Social networking.
Malware.
Adult content.
Streaming media.
Newly registered domains.

Premium provides additional URL filtering capabilities.

Web categories can reduce administrative effort compared with maintaining large lists of individual domains. However, category-based filtering should be combined with threat intelligence, application rules, and an acceptable-use policy.

Azure Firewall Manager

Azure Firewall Manager provides centralized management for Azure Firewall policies.

It can be used to:

Create and manage firewall policies.
Apply common rules to multiple firewalls.
Manage firewalls across subscriptions.
Manage firewalls in virtual networks.
Manage firewalls in secured virtual hubs.
Establish policy inheritance.

A parent policy can contain common organizational rules, while child policies can add environment-specific rules.

For example:

			
Parent policy
    |
    +-- Block known malicious destinations
    +-- Require threat intelligence
    +-- Allow approved DNS
    |
    +-- Child policy: Production
    |       +-- Production-specific rules
    |
    +-- Child policy: Development
            +-- Development-specific rules

		

Policy inheritance can improve consistency, but administrators must understand how parent and child settings interact before deploying changes to production.

Monitoring Azure Firewall

Azure Firewall should be monitored continuously.

Useful monitoring sources include:

Azure Monitor metrics.
Diagnostic settings.
Log Analytics.
Resource logs.
Azure Activity Log.
Firewall Policy Analytics.
Microsoft Defender for Cloud.
Microsoft Sentinel.

Important events to monitor include:

Allowed traffic.
Denied traffic.
DNAT traffic.
Threat intelligence detections.
IDPS alerts.
Policy changes.
Firewall configuration changes.
Backend connectivity failures.
Unexpected outbound destinations.
SNAT port exhaustion.
Firewall health and capacity.

Diagnostic logs should be sent to an appropriate Log Analytics workspace when centralized investigation and correlation are required.

Azure Policy and governance

Azure Policy can help enforce organizational requirements for Azure Firewall.

Examples include policies that:

Require threat intelligence to be enabled.
Require multi-Availability Zone deployment.
Require Firewall Policy Analytics.
Restrict firewall configurations.
Require encrypted traffic.
Identify virtual networks that should have Azure Firewall deployed.
Encourage migration from classic rules to Firewall Policy.

Azure Policy can use effects such as:

Audit.
Deny.
DeployIfNotExists.
Modify.

A policy should be tested in audit mode before using deny in production, especially when existing deployments may not comply with the new requirement.

Security best practices

Use a centralized policy

Use Firewall Policy rather than maintaining inconsistent classic rules across individual firewalls.

Apply least privilege

Allow only the required:

Sources.
Destinations.
Ports.
Protocols.
FQDNs.
URLs.

Enable threat intelligence

Use alert and deny mode when supported and appropriate.

Use Premium when advanced inspection is required

Choose Premium when the organization needs:

IDPS.
TLS inspection.
Advanced URL filtering.

Enable DNS proxy for relevant FQDN filtering

Ensure that the firewall and clients use a consistent DNS resolution path.

Use NSGs in addition to Azure Firewall

NSGs provide local segmentation and defense in depth.

Secure management access

Limit who can:

Create firewalls.
Modify policies.
Add public IP addresses.
Change DNAT rules.
Approve network changes.
Configure threat intelligence exceptions.

Use Microsoft Entra ID, Azure RBAC, privileged identity management, and just-in-time administrative access where appropriate.

Protect firewall configuration

Use:

Azure Policy.
Resource locks.
Infrastructure as code.
Change control.
Activity logs.
Policy versioning.
Backup and recovery procedures.

Avoid unnecessary public exposure

Do not publish internal services through DNAT unless there is a documented business requirement. When inbound publication is necessary, restrict source addresses and secure the backend service.

Common troubleshooting scenarios

Traffic is not reaching the firewall

Check:

The workload subnet’s route table.
The next-hop IP address.
Virtual network peering.
Effective routes.
Return routing.
Network security groups.
Whether the traffic type is supported by the intended route.

Traffic reaches the firewall but is denied

Check:

Rule collection group priority.
Rule collection priority.
Source and destination values.
Protocol and port.
FQDN resolution.
Threat intelligence mode.
Whether the rule is in the correct rule collection type.
Whether a deny rule is evaluated first.

FQDN rules do not work

Check:

DNS proxy configuration.
DNS server settings.
DNS forwarding.
Firewall DNS resolution.
Whether the application uses the expected hostname.
Whether the destination is resolved to changing IP addresses.

DNAT does not work

Check:

Firewall public IP address.
DNAT rule.
Translated destination address.
Translated port.
Backend service availability.
NSG rules.
Operating system firewall.
Load balancer configuration.
Return routing.

Clients cannot access the internet

Check:

Default route.
Firewall application or network rules.
DNS resolution.
SNAT configuration.
Firewall public IP availability.
Threat intelligence detections.
NAT port exhaustion.
Forced-tunneling routes.

Firewall management becomes unavailable

Check:

Forced-tunneling configuration.
Management subnet.
Management route.
Network security rules.
Firewall subnet changes.
User-defined routes applied to infrastructure subnets.

Common exam traps

Azure Firewall is stateful; NSGs are not a replacement for centralized firewall inspection.
Creating Azure Firewall does not automatically route traffic through it.
A route to the firewall does not automatically allow traffic.
A firewall rule does not help if routing bypasses the firewall.
DNAT is used for inbound destination translation.
SNAT is used for outbound source translation.
Application rules are Layer 7 rules.
Network rules are primarily Layer 3 and Layer 4 rules.
Threat intelligence is processed before NAT, network, and application rules.
Basic supports threat intelligence alert mode only.
Premium is required for IDPS and TLS inspection.
FQDN filtering depends on correct DNS behavior.
The firewall subnet must be dedicated and named AzureFirewallSubnet.
A private connection does not eliminate the need for TLS or application authentication.
Azure Firewall and NSGs are complementary controls.
Firewall Policy provides centralized organization of rule collection groups, rule collections, and rules.
Azure Firewall Manager can manage policies across multiple firewalls and secured virtual hubs.
Public DNAT exposure must be secured separately from the firewall configuration.

Practice Exam Questions

Question 1

An organization has three spoke virtual networks and wants all internet-bound traffic from the spokes to be centrally inspected.

What should the organization configure?

A. A service endpoint on each spoke subnet
B. A user-defined route from each spoke subnet to the Azure Firewall private IP address
C. A public IP address on each virtual machine
D. A network security group allowing outbound internet traffic

Answer: B

Explanation: Azure Firewall does not automatically receive all workload traffic. User-defined routes can direct traffic from spoke subnets to the firewall’s private IP address for inspection.

Question 2

A company needs to inspect encrypted HTTPS traffic and detect malicious network patterns using signature-based detection.

Which Azure Firewall SKU should it select?

A. Basic
B. Standard
C. Basic with threat intelligence enabled
D. Premium

Answer: D

Explanation: Azure Firewall Premium provides advanced capabilities including TLS inspection and IDPS. Basic and Standard do not provide the complete set of Premium inspection features.

Question 3

A security administrator wants to allow an application subnet to access only api.contoso.com over HTTPS.

Which rule type is most appropriate?

A. Application rule
B. DNAT rule
C. Network security group rule only
D. Resource lock

Answer: A

Explanation: Application rules operate at Layer 7 and can filter HTTP and HTTPS traffic using fully qualified domain names.

Question 4

An administrator creates an allow rule for outbound traffic, but the traffic never reaches Azure Firewall.

What is the most likely cause?

A. Routing does not direct the traffic through the firewall
B. The firewall policy contains an application rule
C. Threat intelligence is enabled
D. The firewall is stateful

Answer: A

Explanation: Firewall rules apply only to traffic that reaches the firewall. A route table or other routing configuration must direct the workload traffic to the firewall.

Question 5

A company wants to publish an internal web server through an Azure Firewall public IP address.

Which configuration should be used?

A. DNAT rule
B. Application rule
C. Service endpoint
D. Private DNS zone only

Answer: A

Explanation: DNAT rules translate traffic arriving at a firewall public IP address to a private destination address and port.

Question 6

An organization wants Azure Firewall to block traffic to known malicious IP addresses and domains rather than only generate alerts.

Which configuration is required?

A. Threat intelligence disabled
B. Threat intelligence alert-only mode
C. A network security group on the firewall subnet
D. Threat intelligence alert and deny mode on Standard or Premium

Answer: D

Explanation: Alert and deny mode blocks traffic associated with known malicious destinations. Basic supports alert mode only, while Standard and Premium support alert and deny mode.

Question 7

A firewall application rule uses an FQDN, but traffic is not consistently filtered because the firewall and clients receive different DNS responses.

What should the administrator investigate?

A. DNS proxy and DNS forwarding configuration
B. DNAT port translation
C. Resource locks
D. The firewall’s public IP prefix

Answer: A

Explanation: FQDN filtering depends on consistent DNS resolution. DNS proxy can help ensure that the firewall and clients use consistent DNS answers.

Question 8

Which rule type should be used to allow TCP traffic from an application subnet to a database server on port 1433?

A. Application rule
B. DNAT rule
C. Network rule
D. Threat intelligence rule

Answer: C

Explanation: Network rules filter traffic using network and transport information such as source, destination, protocol, and port.

Question 9

An organization needs to manage firewall policies across multiple subscriptions and secured virtual hubs.

Which service should it use?

A. Azure Bastion
B. Azure Private DNS
C. Azure Network Watcher
D. Azure Firewall Manager

Answer: D

Explanation: Azure Firewall Manager provides centralized management of Azure Firewall policies across supported firewall deployments, including virtual network firewalls and secured virtual hubs.

Question 10

A company wants to require that all Azure Firewall policies have threat intelligence enabled.

Which service is best suited to enforce this requirement consistently?

A. Azure Policy
B. Azure Load Balancer
C. Azure VPN Gateway
D. Azure Private Link

Answer: A

Explanation: Azure Policy can audit or deny noncompliant Azure Firewall configurations and can be used to enforce organizational security standards such as enabling threat intelligence.

Go to the SC-500 Exam Prep Hub main page

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

Implement and manage network security groups (NSGs) and application security groups (ASGs) (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 manage network security groups (NSGs) and application security groups (ASGs)

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

Network security groups (NSGs) and application security groups (ASGs) are foundational Azure networking features used to control traffic within and between Azure virtual networks.

Network security groups provide traffic filtering through inbound and outbound security rules.
Application security groups allow administrators to organize virtual machines and network interfaces according to application roles rather than relying on individual IP addresses.

Together, NSGs and ASGs support defense in depth, network segmentation, least-privilege access, and easier security-rule management.

An NSG can be associated with:

A subnet
A network interface card (NIC)
Both a subnet and a NIC

When an NSG is associated with a subnet, its rules apply to the resources in that subnet. When it is associated with a NIC, its rules apply to the traffic for that network interface.

1. Understand Network Security Groups

A network security group is an Azure resource containing security rules that allow or deny network traffic.

Each rule can evaluate traffic based on:

Source
Source port
Destination
Destination port
Protocol
Direction
Priority
Action

Supported protocols include:

The action is either:

Allow
Deny

For example, an NSG rule could allow HTTPS traffic from the Internet to a web server while denying direct inbound access to the database tier.

Example security rule

Property	Example
Name	Allow-HTTPS
Direction	Inbound
Priority	100
Source	Internet
Source port	*
Destination	Web server subnet
Destination port	443
Protocol	TCP
Action	Allow

A lower priority number has higher precedence. For example, priority 100 is evaluated before priority 200.

2. NSG Default Rules

Every NSG contains default security rules. These rules cannot be deleted, but custom rules can override them by using a higher priority.

Common default inbound rules include:

Allow traffic from the VirtualNetwork service tag
Allow traffic from the AzureLoadBalancer service tag
Deny all other inbound traffic

Common default outbound rules include:

Allow traffic to the VirtualNetwork service tag
Allow traffic to the Internet
Deny all other outbound traffic

The default rules are evaluated after custom rules. Therefore, a custom rule with a priority lower than the default deny rule can allow traffic that would otherwise be denied.

Important exam point

NSGs are not automatically “deny all” in every direction. They include default rules that permit certain virtual-network and outbound Internet traffic. Security administrators should explicitly review and override these defaults when stricter controls are required.

3. Inbound and Outbound Rule Evaluation

NSGs filter both inbound and outbound traffic.

Inbound traffic

For a virtual machine with NSGs at both the subnet and NIC levels:

Azure evaluates the subnet-level NSG.
Azure evaluates the NIC-level NSG.
Traffic must be allowed by both NSGs.

Outbound traffic

For outbound traffic:

Azure evaluates the NIC-level NSG.
Azure evaluates the subnet-level NSG.
Traffic must be allowed by both NSGs.

The effective result is the combined set of applicable rules. A deny rule in either NSG can prevent traffic from flowing.

Example

Suppose:

The subnet NSG allows inbound TCP 443.
The NIC NSG denies inbound TCP 443.

The traffic is denied because both NSGs must permit the traffic.

Similarly:

The subnet NSG allows outbound TCP 1433.
The NIC NSG denies outbound TCP 1433.

The connection is denied.

4. NSG Rule Priority

Each custom NSG rule must have a unique priority number.

Lower numbers have higher priority.
Rules are evaluated in priority order.
Evaluation stops when a matching rule is found.
A later rule cannot override an earlier matching rule.

Example

Priority	Rule	Action
100	Allow TCP 443 from Internet	Allow
110	Deny all inbound traffic	Deny

HTTPS traffic is allowed because the priority 100 rule is evaluated first.

If the rules were reversed:

Priority	Rule	Action
100	Deny all inbound traffic	Deny
110	Allow TCP 443 from Internet	Allow

The HTTPS allow rule would never be reached for matching traffic.

Best practices

Reserve priority ranges for different application tiers.
Use descriptive rule names.
Avoid overlapping rules.
Place specific rules before broad rules.
Avoid using unnecessarily permissive rules such as Any for both source and destination.
Document why each rule exists.

5. Source and Destination Options

NSG rules can use several types of source and destination values.

Any

Matches all addresses.

Use this only when broad access is intentionally required.

IP addresses or CIDR ranges

You can specify:

A single IP address
Multiple IP addresses
A subnet range
Multiple CIDR ranges

Example:

10.10.1.0/24

Service tags

A service tag represents a group of IP address prefixes associated with an Azure service or category of traffic.

Examples include:

VirtualNetwork
Internet
AzureLoadBalancer
AzureCloud
Storage
AzureKeyVault

Microsoft maintains the IP prefixes represented by service tags and updates them as Azure addresses change. This avoids manually maintaining large lists of IP addresses.

Application security groups

An ASG can be used as the source or destination of an NSG rule. This allows rules to be based on application roles instead of IP addresses.

For example:

			
Source ASG: Asg-Web
Destination ASG: Asg-Database
Destination port: 1433
Protocol: TCP
Action: Allow

		

This rule allows members of the web application group to communicate with members of the database group over TCP port 1433.

6. Network Security Group Association

An NSG can be associated with a subnet, a NIC, or both.

Subnet-level association

A subnet-level NSG is useful when a common policy should apply to all resources in the subnet.

Examples:

Deny inbound Internet traffic to a private application subnet.
Allow communication from a shared management subnet.
Restrict outbound traffic from a database subnet.

NIC-level association

A NIC-level NSG is useful when a particular virtual machine requires additional controls beyond the subnet policy.

Examples:

A management server requires SSH access.
A specific application server needs an additional inbound port.
A sensitive VM requires stricter outbound restrictions.

Recommended design

Use subnet-level NSGs for broad segmentation and NIC-level NSGs for workload-specific restrictions. Avoid creating unnecessarily complicated combinations that are difficult to troubleshoot.

7. Understand Application Security Groups

An application security group is a logical grouping of network interfaces.

ASGs allow administrators to define security rules according to application architecture, such as:

Web servers
Application servers
Database servers
Management servers
Monitoring servers

Instead of creating rules based on individual IP addresses, you can create rules based on group membership.

Example application groups

			
Asg-Web
Asg-App
Asg-Database
Asg-Management

A rule could allow:

			
Asg-Web → Asg-App → TCP 8080
Asg-App → Asg-Database → TCP 1433
Asg-Management → Asg-Web → TCP 22

This design is easier to maintain when virtual machines are added, removed, or assigned new IP addresses.

ASGs are logical groupings; they do not themselves filter traffic. The filtering is performed by NSG rules that reference the ASGs.

8. ASG Constraints

Important ASG constraints include:

An ASG contains network interfaces, not entire virtual machines directly.
All NICs in an ASG must be in the same virtual network.
An ASG cannot contain NICs from different virtual networks.
If an NSG rule uses an ASG as both source and destination, the referenced ASGs must contain NICs in the same virtual network.
A NIC can belong to multiple ASGs.
An ASG does not automatically grant access; a matching NSG rule is still required.

The location and virtual-network requirements should be considered when designing application groups.

9. ASGs and Dynamic Application Membership

ASGs are especially useful when application membership changes frequently.

For example, an organization may have:

Three web servers today
Six web servers next month
Different private IP addresses after redeployment

If the web server NICs are members of Asg-Web, the NSG rule can remain unchanged as servers are added or removed.

The administrator only needs to update ASG membership.

Benefits

Reduces dependence on hard-coded IP addresses
Simplifies rule maintenance
Supports application-centric segmentation
Makes security intent easier to understand
Reduces the number of rules required
Helps maintain consistent policies during scaling

Microsoft recommends using ASGs and service tags where appropriate to reduce rule complexity.

10. Example Three-Tier Application Design

Consider a three-tier application:

			
Internet
   |
   v
Web tier
   |
   v
Application tier
   |
   v
Database tier

		

Create the following ASGs:

Asg-Web
Asg-App
Asg-Database

Then configure NSG rules such as:

Priority	Source	Destination	Port	Action
100	Internet	Asg-Web	443	Allow
110	Asg-Web	Asg-App	8080	Allow
120	Asg-App	Asg-Database	1433	Allow
130	Asg-Management	Asg-Web	22	Allow
4000	Any	Any	Any	Deny

This approach prevents direct Internet access to the application and database tiers.

The database tier does not need to allow traffic from the entire virtual network. It only needs to allow traffic from the application tier on the required port.

11. Service Tags Versus ASGs

Service tags and ASGs solve different problems.

Feature	Service tags	Application security groups
Represents	Azure service IP ranges or traffic categories	Application network interfaces
Example	`Storage`, `Internet`, `AzureLoadBalancer`	`Asg-Web`, `Asg-Database`
Main purpose	Simplify access to Azure services	Simplify application segmentation
Managed by	Microsoft-managed IP prefix updates	Customer-managed membership
Common use	Allow traffic from Azure Storage	Allow web servers to access database servers

Use service tags when the source or destination is an Azure service or well-defined traffic category. Use ASGs when the source or destination is a group of application workloads.

12. Augmented Security Rules

Augmented security rules allow multiple values to be specified in a single rule.

For example, one rule can contain:

Multiple source IP addresses
Multiple destination IP addresses
Multiple ports
Port ranges

This can reduce the number of individual rules required.

Example:

			
Source ports: *
Destination ports: 80, 443, 8080
Protocol: TCP
Action: Allow

Augmented rules should be used carefully. Combining unrelated access requirements into one rule can make the security policy harder to understand. Where possible, use service tags and ASGs to express the security intent more clearly.

13. Managing NSGs and ASGs

NSGs and ASGs can be managed through:

Azure portal
Azure PowerShell
Azure CLI
Azure Resource Manager templates
Bicep
Terraform

Typical management tasks include:

Create an NSG.
Create an ASG.
Associate the NSG with a subnet or NIC.
Add NICs to the ASG.
Create inbound and outbound rules.
Test connectivity.
Review effective security rules.
Update or remove obsolete rules.

Azure CLI examples

Create an NSG:

			
az network nsg create \
  --resource-group NetworkRG \
  --name nsg-web

Create an ASG:

			
az network asg create \
  --resource-group NetworkRG \
  --name asg-web \
  --location eastus

Create an inbound rule allowing HTTPS to the web ASG:

			
az network nsg rule create \
  --resource-group NetworkRG \
  --nsg-name nsg-web \
  --name Allow-HTTPS \
  --access Allow \
  --protocol Tcp \
  --direction Inbound \
  --priority 100 \
  --source-address-prefix Internet \
  --source-port-range "*" \
  --destination-asgs asg-web \
  --destination-port-range 443

		

The exact command syntax can vary depending on whether the rule references IP addresses, service tags, or ASGs.

14. Troubleshooting NSG Connectivity

When traffic is unexpectedly blocked, review the following:

1. Confirm the destination port

Ensure the application is actually listening on the expected port.

2. Confirm the source address

The source may be:

A private IP address
A public IP address
A load balancer
A service tag
Another application group

A rule that allows the wrong source range will not match.

3. Check both NSGs

Review:

The subnet-level NSG
The NIC-level NSG

A deny rule in either NSG can block traffic.

4. Review effective security rules

Effective security rules show the aggregated rules applied to a NIC, including rules from both the subnet and NIC NSGs.

In the Azure portal, effective rules can be viewed from the VM’s networking settings. They can also be retrieved with Azure CLI:

			
az network nic list-effective-nsg \
  --name vm-nic \
  --resource-group NetworkRG

This is one of the most important troubleshooting tools for NSG-related connectivity problems.

5. Check rule priority

A broad deny rule with a higher priority can prevent a later allow rule from being evaluated.

6. Check ASG membership

If an NSG rule references an ASG, verify that the destination or source NIC is actually a member of that ASG.

7. Check other networking controls

NSGs are not the only possible cause of blocked traffic. Also consider:

Azure Firewall
Network virtual appliances
Route tables
Private endpoints
Application Gateway
Operating-system firewalls
Application configuration
Network Watcher connection troubleshooting

15. NSGs Are Not a Replacement for Azure Firewall

NSGs provide basic network traffic filtering at the subnet and NIC levels. They are not a full network firewall solution.

NSGs generally do not provide the same capabilities as Azure Firewall, such as:

Centralized stateful inspection
Advanced threat intelligence filtering
Intrusion detection and prevention
Centralized application and network rule processing
Advanced logging and security operations integration

A common defense-in-depth architecture uses:

NSGs for subnet and workload segmentation
Azure Firewall for centralized traffic inspection
Application Gateway WAF for web application protection
Private Link for private access to PaaS services
Microsoft Defender for Cloud for security posture management

16. Best Practices

Use least privilege

Allow only the required:

Sources
Destinations
Ports
Protocols
Directions

Prefer application-based rules

Use ASGs instead of individual IP addresses when controlling communication between application tiers.

Use service tags appropriately

Use service tags to avoid maintaining changing Azure service IP ranges manually.

Avoid unrestricted access

Avoid rules that allow:

			
Source: Any
Destination: Any
Port: Any
Protocol: Any
Action: Allow

		

unless there is a documented and justified requirement.

Separate application tiers

Use different subnets and ASGs for:

Web
Application
Database
Management

Review effective rules

Regularly inspect effective security rules to verify that the actual applied policy matches the intended design.

Use infrastructure as code

Define NSGs, ASGs, and rules in Bicep, ARM templates, or another approved infrastructure-as-code solution to improve consistency and auditability.

Remove obsolete rules

Unused rules increase complexity and may create unintended access paths.

Document security intent

Use descriptive names and descriptions such as:

Allow-App-to-Database-SQL

rather than:

Rule1

Practice Exam Questions

Question 1

A company hosts a three-tier application in Azure. Web servers must communicate with application servers over TCP port 8080. Application servers must communicate with database servers over TCP port 1433. The company wants security rules to remain valid when virtual machines are added or their private IP addresses change.

What should you implement?

A. Create ASGs for each application tier and reference them in NSG rules.
B. Create a separate NSG for every virtual machine using static IP addresses.
C. Allow all traffic between the application subnets.
D. Use public IP addresses for all application servers.

Correct answer: A

Explanation: ASGs allow NSG rules to reference application roles instead of individual IP addresses. Membership can change without requiring the security rules to be rewritten.

Question 2

An NSG associated with a subnet allows inbound TCP port 443. An NSG associated with a VM’s NIC denies inbound TCP port 443 from the same source.

What is the result?

A. The subnet NSG takes precedence, so traffic is allowed.
B. The NIC NSG takes precedence, so traffic is denied.
C. Azure randomly selects one of the rules.
D. The traffic is allowed only if the VM has a public IP address.

Correct answer: B

Explanation: Both the subnet-level and NIC-level NSGs apply. Traffic must be allowed by both. The deny rule in the NIC-level NSG blocks the connection.

Question 3

An administrator creates an NSG rule with priority 100 that denies all inbound traffic. Another rule with priority 200 allows inbound HTTPS traffic.

What happens to inbound HTTPS traffic?

A. HTTPS is allowed because it uses a secure protocol.
B. HTTPS is allowed because the allow rule is more specific.
C. HTTPS is denied because the priority 100 rule is evaluated first.
D. Azure combines the actions and allows the traffic.

Correct answer: C

Explanation: Lower priority numbers are evaluated first. The broad deny rule at priority 100 matches the traffic, so the later allow rule is not evaluated.

Question 4

A VM cannot receive traffic from another VM in the same virtual network. The NSG associated with the destination NIC allows the traffic, but the subnet-level NSG contains a deny rule.

What should the administrator do first?

A. Assign a public IP address to the destination VM.
B. Review and modify the subnet-level NSG rule.
C. Disable the destination VM’s operating-system firewall.
D. Create an Azure Firewall policy.

Correct answer: B

Explanation: Both the subnet-level and NIC-level NSGs apply. A deny rule at the subnet level can block traffic even when the NIC-level NSG allows it.

Question 5

An organization wants to allow traffic from Azure Storage without manually maintaining a list of changing Azure IP addresses.

Which feature should be used?

A. Application security group
B. User-defined route
C. Service tag
D. Public IP prefix

Correct answer: C

Explanation: Service tags represent Microsoft-managed groups of IP address prefixes for Azure services. Microsoft updates the prefixes as service addresses change.

Question 6

A security administrator creates an ASG named Asg-Database. The administrator then creates an NSG rule allowing traffic to Asg-Database on TCP port 1433.

A database VM is not receiving the traffic.

Which issue could explain the problem?

A. The VM’s NIC is not a member of Asg-Database.
B. ASGs automatically deny all traffic.
C. ASGs can contain only public IP addresses.
D. ASGs work only with Azure Firewall.

Correct answer: A

Explanation: An NSG rule referencing an ASG applies only to network interfaces that are members of that ASG. The ASG itself does not automatically include every VM in a subnet.

Question 7

Which statement about application security groups is correct?

A. An ASG directly filters traffic without an NSG.
B. An ASG can contain NICs from multiple virtual networks.
C. An ASG is a logical grouping of network interfaces used by NSG rules.
D. An ASG replaces the need for subnet-level NSGs.

Correct answer: C

Explanation: ASGs provide logical grouping. NSG rules perform the actual allow or deny operation. NICs in an ASG must be in the same virtual network.

Question 8

A VM cannot connect to a database server. The administrator wants to see the combined inbound and outbound rules applied from the subnet and NIC NSGs.

Which feature should be used?

A. Azure Advisor
B. Effective security rules
C. Microsoft Defender Vulnerability Management
D. Azure Service Health

Correct answer: B

Explanation: Effective security rules show the aggregated rules applied to a network interface and are designed to help troubleshoot NSG-related connectivity issues.

Question 9

A company wants to allow management traffic only from a management subnet to selected application servers. The application servers are distributed across several subnets in the same virtual network.

What is the most maintainable approach?

A. Add every application server’s private IP address to a separate rule.
B. Allow management traffic from the entire virtual network to every server.
C. Create an ASG for the management servers and an ASG for the target application servers, then reference them in an NSG rule.
D. Assign public IP addresses to the management servers.

Correct answer: C

Explanation: ASGs allow security policies to be expressed according to application roles. The rule can remain stable as servers are added or their IP addresses change.

Question 10

An administrator wants to create a rule that allows TCP ports 80, 443, and 8080 from a specified source range using one NSG rule.

Which NSG capability supports this configuration?

A. Augmented security rules
B. Azure Bastion
C. Application Gateway WAF
D. Private Link

Correct answer: A

Explanation: Augmented security rules allow multiple ports, addresses, and ranges to be specified in a single rule, reducing the number of individual rules required.

Final Exam Point

NSGs and ASGs are most effective when used together: NSGs enforce traffic rules, while ASGs make those rules easier to express and maintain according to application architecture.

Go to the SC-500 Exam Prep Hub main page

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

Configure security for an Azure Virtual WAN (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 security for an Azure Virtual WAN

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

Overview

Azure Virtual WAN is a Microsoft-managed networking service that provides centralized connectivity between Azure virtual networks, branch offices, remote users, and other connected environments. It combines networking, routing, VPN, ExpressRoute, and security capabilities through a unified operational model.

For the SC-500 exam, the important security concept is that Azure Virtual WAN should not be viewed only as a connectivity service. It can also provide a centralized inspection and enforcement point for traffic flowing between:

Azure virtual networks
On-premises branch offices
Remote users
Other Virtual WAN hubs
The internet
Azure platform services and private resources

A common secure design is to use a secured virtual hub, Azure Firewall, Firewall Manager, and Virtual WAN routing capabilities to ensure that traffic is inspected before reaching protected destinations.

What Is Azure Virtual WAN?

Azure Virtual WAN consists of several major components:

Virtual WAN resource

The Virtual WAN resource is the top-level container for one or more virtual hubs. It provides a centralized management and configuration boundary.

Virtual hub

A virtual hub is a Microsoft-managed network infrastructure component deployed in an Azure region. It provides connectivity and routing services for connected networks and gateways.

A virtual hub can contain or provide access to:

Site-to-site VPN gateways
Point-to-site user VPN gateways
ExpressRoute gateways
The Virtual WAN hub router
Azure Firewall
Supported network virtual appliances
Connections to Azure virtual networks
Connections to branch sites

Unlike a customer-managed hub VNet, a Virtual WAN hub is operated by Microsoft. You do not directly deploy or manage the underlying hub virtual network in the same way that you manage a normal Azure VNet.

Virtual network connections

Azure VNets connect to a Virtual WAN hub through virtual network connections. These connections allow workloads in the VNets to communicate with other connected networks according to the hub’s routing configuration.

VPN and ExpressRoute connections

Branch offices and on-premises networks can connect to Virtual WAN through:

Site-to-site VPN
ExpressRoute
Point-to-site user VPN

The connection type depends on the organization’s requirements for connectivity, performance, availability, and authentication.

Basic and Standard Virtual WAN

Azure Virtual WAN is available in two primary types:

Capability	Basic Virtual WAN	Standard Virtual WAN
Site-to-site VPN	Supported	Supported
ExpressRoute	Not supported	Supported
Point-to-site user VPN	Not supported	Supported
Inter-hub transit	Not supported	Supported
VNet-to-VNet transit	Not supported	Supported
Azure Firewall	Not supported	Supported
Network virtual appliances in Virtual WAN	Not supported	Supported

For most enterprise security scenarios, Standard Virtual WAN is required because secured hubs, Azure Firewall, advanced transit, and additional gateway capabilities depend on Standard functionality.

A Basic Virtual WAN can be upgraded to Standard, but it cannot be downgraded from Standard back to Basic.

What Is a Secured Virtual Hub?

A secured virtual hub is an Azure Virtual WAN hub with an integrated Azure Firewall.

Azure Firewall provides centralized traffic inspection and policy enforcement for traffic moving through the Virtual WAN environment. A secured hub can inspect traffic destined for:

Private IP addresses
Azure virtual networks
Other connected networks
The internet
Azure platform services, depending on the routing and security design

Azure Firewall can inspect traffic between different network locations, including:

North-south traffic: traffic between on-premises networks and Azure
East-west traffic: traffic between Azure networks or workloads
Internet-bound traffic: traffic from Azure workloads to the internet

This approach centralizes security enforcement rather than requiring every workload or spoke network to independently deploy a firewall.

Why use a secured virtual hub?

A secured virtual hub can provide:

Centralized traffic inspection
Consistent firewall policies
Reduced need for manually configured routes
Centralized security management across multiple hubs
Protection for Azure and branch connectivity
A more consistent Zero Trust architecture
Easier enforcement of organization-wide security requirements

For example, an organization might connect several regional VNets and branch offices to Virtual WAN. Instead of deploying and maintaining separate firewalls in every location, the organization can use Azure Firewall in secured hubs and apply consistent policies.

Azure Firewall Manager

Azure Firewall Manager provides centralized management for firewall policies and secured virtual hubs.

It can be used to:

Create secured virtual hubs
Manage Azure Firewall policies
Apply consistent security rules across multiple hubs
Configure routing-related security settings
Manage security for multiple regions
Separate centralized security administration from individual workload administration

Firewall Manager is particularly useful when an organization has multiple Virtual WAN hubs in different Azure regions.

For example:

A global company has hubs in North America, Europe, and Asia.
Each hub connects regional VNets and branch offices.
Security administrators manage common firewall policies centrally.
Regional teams manage their workloads without independently designing the entire network security architecture.

Firewall Manager supports centralized rule management across secured hubs.

Routing Intent

One of the most important security features in Azure Virtual WAN is routing intent.

Routing intent allows you to define how traffic should be routed through a security solution, such as Azure Firewall or a supported network virtual appliance.

Common routing intent patterns include:

Internet traffic inspection

Internet-bound traffic from connected VNets or branches is routed through the security solution before reaching the internet.

This helps enforce policies such as:

Blocking malicious destinations
Restricting outbound access
Inspecting internet-bound traffic
Applying centralized filtering
Logging traffic for investigation

Private traffic inspection

Private traffic between connected networks is routed through the security solution.

For example:

VNet A communicates with VNet B.
A branch office communicates with an Azure workload.
One regional hub communicates with another regional hub.

Routing intent can be used to steer this private traffic through the firewall for inspection.

Why routing intent matters

Without centralized routing, administrators may need to create and maintain multiple user-defined routes. Incorrect or incomplete routes can allow traffic to bypass inspection.

Routing intent helps simplify this process by automatically steering specified traffic categories through the security solution. The Virtual WAN architecture is designed to reduce the need for manually maintained routing configurations.

Traffic Flow Through a Secured Virtual Hub

A simplified secure traffic flow might look like this:

			
Branch Office
     |
     | Site-to-site VPN or ExpressRoute
     |
Virtual WAN Hub
     |
Azure Firewall
     |
     +--------------------+
     |                    |
Private Azure VNet     Internet

		

For traffic between two Azure VNets:

			
VNet A
  |
  | Virtual WAN connection
  |
Virtual WAN Hub
  |
Azure Firewall
  |
Virtual WAN Hub
  |
  | Virtual WAN connection
  |
VNet B

		

The exact traffic path depends on the hub configuration, routing intent, firewall policy, connection settings, and whether the traffic is classified as private or internet-bound.

The important exam concept is:

A connection to Virtual WAN does not automatically mean that all traffic is inspected by Azure Firewall. The routing and security configuration must direct the traffic through the security solution.

Azure Firewall Policy in a Secured Virtual Hub

Azure Firewall policies define the traffic that is allowed, denied, or inspected.

Depending on the Azure Firewall tier and configuration, policies can include:

Network rules
Application rules
NAT rules
Threat intelligence filtering
DNS-related security controls
TLS inspection capabilities, where supported and configured
IDPS capabilities with Azure Firewall Premium

Network rules

Network rules control traffic based on characteristics such as:

Source address
Destination address
Protocol
Destination port

Examples include:

Allow TCP 443 from a corporate network to an application subnet
Deny TCP 22 from untrusted networks
Allow DNS traffic to an approved DNS service
Block traffic to a known prohibited network range

Application rules

Application rules can control supported application-layer traffic, such as HTTP and HTTPS, based on:

Fully qualified domain names
Web categories
Application characteristics

For example, an organization might allow servers to access only approved software repositories.

NAT rules

NAT rules can publish selected internal services through a public IP address. NAT should be configured carefully because it can expose internal resources to external traffic.

Security considerations include:

Restricting source addresses
Limiting exposed ports
Avoiding unnecessary public exposure
Applying least privilege
Monitoring inbound connections
Using private connectivity whenever possible

Virtual WAN Network Virtual Appliances

Azure Virtual WAN can also support supported network virtual appliances, depending on the Virtual WAN type and deployment architecture.

A network virtual appliance might provide specialized capabilities such as:

Third-party firewall functionality
Intrusion prevention
Secure web gateway features
Specialized network inspection
Vendor-specific security controls

However, an NVA is not automatically equivalent to Azure Firewall. Before selecting an NVA, verify:

Supported Virtual WAN integration
Routing behavior
High availability
Scaling model
Inspection capabilities
Logging and monitoring
TLS inspection support
Compatibility with required traffic patterns
Whether the appliance supports the organization’s security requirements

Microsoft documentation specifically notes that NVAs deployed in a Virtual WAN hub can have different capabilities from Azure Firewall.

Virtual WAN Hub Address Space

When creating a Virtual WAN hub, you must specify a hub address space.

Important considerations include:

The minimum hub address space is /24.
Microsoft recommends using /23 or larger when future growth is expected.
If Azure Firewall is used in the Virtual WAN hub, a minimum /22 address space is required to provide sufficient IP address capacity for firewall scaling.
The hub address space cannot be changed after the hub is created.
The hub address space must not overlap with connected VNets, on-premises networks, or other Virtual WAN hub address spaces.

The address space is used internally by the hub and its services, including the hub router, VPN gateways, ExpressRoute, Azure Firewall, and supported NVAs.

Exam warning

Do not select a hub address range that overlaps with:

An on-premises network
A connected VNet
Another Virtual WAN hub
A future planned network

Address-space overlap can cause routing conflicts and connectivity failures.

Virtual WAN Connectivity Security

Site-to-site VPN

Site-to-site VPN provides encrypted connectivity between an on-premises VPN device and a Virtual WAN hub.

The on-premises device generally requires:

An externally reachable public IP address
IPsec/IKE compatibility
Correct VPN configuration
Matching authentication and encryption settings
Appropriate routing configuration

Virtual WAN supports IPsec/IKE VPN connectivity, including IKEv1 and IKEv2 scenarios.

Security best practices include:

Use strong pre-shared keys or supported authentication methods.
Store sensitive VPN secrets securely.
Rotate credentials according to organizational policy.
Avoid exposing management interfaces on the public internet.
Monitor VPN connection status and gateway logs.
Use redundant connections for critical sites.
Validate learned and advertised routes.

Point-to-site user VPN

Point-to-site VPN allows individual users to connect to a Virtual WAN hub.

Authentication can be integrated with Microsoft Entra ID. This enables centralized identity-based access and can support organizational authentication requirements.

Security controls may include:

Microsoft Entra authentication
Multifactor authentication
Conditional Access
Group-based authorization
Device compliance requirements
Restricted user access
Short-lived or controlled access
Monitoring of user VPN activity

The key distinction is that site-to-site VPN connects networks, while point-to-site VPN connects individual users or devices.

ExpressRoute

ExpressRoute provides private connectivity between on-premises infrastructure and Azure.

ExpressRoute traffic does not traverse the public internet in the same way as ordinary internet-based connectivity. Virtual WAN can provide transit connectivity and routing between connected networks.

Security considerations include:

Controlling which routes are advertised
Avoiding unintended transit
Applying private traffic inspection where required
Monitoring route propagation
Using encryption requirements appropriate to the organization
Understanding that private connectivity does not automatically eliminate the need for authorization and inspection

Route Tables and Route Propagation

Virtual WAN uses hub routing and route tables to determine how traffic is forwarded between connected networks.

A route table can define:

Which routes a connection learns
Which routes are propagated to a connection
Which networks can communicate
Whether a connection receives default routes
Whether traffic is directed toward a firewall or NVA

Route association

A connection is associated with a Virtual WAN route table. The association determines which route table is used for forwarding decisions.

Route propagation

Route propagation determines which routes are advertised to a connection.

For example, a connection might receive routes for:

Other VNets
Branch networks
Other Virtual WAN hubs
The internet default route
Specific private address ranges

Security importance

Route propagation can affect whether traffic:

Reaches a protected network
Can communicate with another spoke
Is routed through a firewall
Can access the internet
Can bypass an inspection point

A secure configuration should advertise only the routes that are necessary.

Internet Security and the Default Route

The default route is:

0.0.0.0/0

When internet security is enabled and routing is configured to send internet traffic through a firewall or NVA, the default route can be advertised to connected VNets.

This causes internet-bound traffic from those VNets to use the centralized security solution.

However, administrators must understand the operational impact:

Internet access may be blocked unless firewall rules allow it.
DNS resolution may be affected by routing and firewall policies.
Application dependencies may fail if required endpoints are not allowed.
The firewall must be configured to permit legitimate outbound traffic.
Route propagation must be validated after changes.

The security objective is to prevent workloads from bypassing the organization’s inspection and filtering controls.

Private Traffic Inspection

Private traffic inspection is used when traffic between private networks must pass through a security solution.

Examples include:

VNet-to-VNet communication
Branch-to-VNet communication
Hub-to-hub communication
Traffic between application tiers
Traffic between production and shared services

Private traffic inspection is especially important in Zero Trust architectures because private IP addressing alone does not prove that traffic is trustworthy.

A workload in one VNet should not automatically be trusted merely because it is connected to the same Virtual WAN environment.

Security policies should consider:

Source network
Destination network
Application role
Protocol
Port
Identity and workload context
Required business relationship
Logging and monitoring requirements

Branch-to-Branch and Hub-to-Hub Connectivity

Virtual WAN can provide transit connectivity between connected branch sites and hubs.

This can simplify global network architecture, but it also creates security considerations.

For example, if branch-to-branch traffic is enabled, one branch may be able to communicate with another branch through Virtual WAN. This may be useful, but it could also create an unintended trust relationship.

Before enabling branch-to-branch connectivity, determine:

Which branches should communicate
Whether branch traffic must be inspected
Whether segmentation is required
Whether the firewall can inspect the traffic
Whether route propagation exposes unnecessary networks
Whether the connectivity requirement is temporary or permanent

The principle is:

Enable only the transit connectivity that is required by the business and security architecture.

Azure Virtual WAN and Zero Trust

A Zero Trust design assumes that no network location is inherently trusted.

For Virtual WAN, this means:

Do not trust traffic solely because it originates from a connected VNet.
Do not assume private traffic is safe.
Inspect traffic where required.
Use least-privilege routing.
Restrict internet access.
Authenticate remote users.
Apply consistent firewall policies.
Monitor traffic and configuration changes.
Segment workloads and branches.
Avoid unnecessary route propagation.

A secured Virtual WAN hub can support Zero Trust by centralizing inspection and reducing opportunities for traffic to bypass security controls.

Logging and Monitoring

Virtual WAN and related resources can produce resource logs that can be sent to:

Log Analytics workspaces
Event Hubs
Storage accounts

Logging can support:

Security investigations
VPN troubleshooting
Route analysis
Firewall monitoring
Compliance evidence
Detection of configuration changes
Investigation of unexpected connectivity

Resource logs are not necessarily enabled automatically. The organization must configure diagnostic settings and select the appropriate destination.

A recommended design is to send security-relevant logs to a centralized Log Analytics workspace and integrate them with Microsoft Sentinel when broader security analytics and incident response are required.

Monitor these areas

Monitor:

Virtual hub health
Hub router status
VPN connection state
ExpressRoute connectivity
Learned routes
Advertised routes
Firewall health
Firewall rule hits
Denied connections
Unexpected internet access
Configuration changes
Resource deployment failures

Hub Router Status

A Virtual WAN hub router can have statuses such as:

Provisioned
Provisioning
Failed
None

A Failed status may indicate a problem during router instantiation.

A None status may occur when the router was not provisioned, including scenarios involving Basic Virtual WAN or older hub deployments.

The hub router is important because it provides the routing infrastructure for transit connectivity. If the router is not functioning correctly, connected networks may experience routing or connectivity problems.

Security Best Practices

1. Use Standard Virtual WAN for enterprise security scenarios

Standard Virtual WAN supports the capabilities generally required for secured hubs, advanced transit, ExpressRoute, point-to-site VPN, Azure Firewall, and supported NVAs.

2. Use secured virtual hubs for centralized inspection

Deploy Azure Firewall in the Virtual WAN hub when traffic from multiple networks must be inspected consistently.

3. Use Firewall Manager for centralized policy management

Use centralized firewall policies to reduce inconsistent regional configurations.

4. Configure routing intent deliberately

Ensure private and internet-bound traffic is routed through the appropriate security solution.

5. Avoid overlapping address spaces

Plan hub, VNet, branch, and on-premises address spaces before deployment.

6. Use least-privilege route propagation

Advertise only the routes that each connection needs.

7. Do not assume connected networks are trusted

Apply inspection and access controls based on the required communication paths.

8. Protect VPN credentials

Store VPN secrets securely and rotate them according to policy.

9. Monitor logs centrally

Enable diagnostic settings and send relevant logs to a centralized monitoring destination.

10. Validate changes before production deployment

Test:

Route propagation
Firewall inspection
VPN connectivity
Internet access
Private network access
DNS resolution
Failover behavior
Logging and alerting

Common Exam Traps

Trap 1: “A VNet connected to Virtual WAN automatically uses Azure Firewall.”

Not necessarily. Traffic must be routed through the firewall using the appropriate security and routing configuration.

Trap 2: “Basic Virtual WAN supports Azure Firewall.”

Basic Virtual WAN does not support Azure Firewall. Standard Virtual WAN is required.

Trap 3: “A private connection is automatically secure.”

Private connectivity reduces exposure to the public internet, but it does not replace authorization, segmentation, inspection, or monitoring.

Trap 4: “Routing intent is only for internet traffic.”

Routing intent can be used for internet-bound traffic and private traffic inspection.

Trap 5: “The Virtual WAN hub address space can be changed later.”

The hub address space cannot be modified after the hub is created.

Trap 6: “An NVA and Azure Firewall always have identical capabilities.”

They do not. Validate the NVA’s supported features and Virtual WAN integration.

Trap 7: “Enabling branch-to-branch connectivity is always desirable.”

It can create additional trust paths and should be enabled only when required.

Practice Exam Questions

Question 1

An organization has several Azure VNets and branch offices connected through Azure Virtual WAN. The security team requires all internet-bound traffic from the VNets to pass through a centralized Azure Firewall.

What should the organization configure?

A. A network security group on every subnet
B. Routing intent that directs internet traffic through Azure Firewall
C. A point-to-site VPN connection for every workload
D. A separate public IP address for every VNet

Correct answer: B

Explanation: Routing intent can direct internet-bound traffic through Azure Firewall in a secured virtual hub. NSGs do not provide centralized internet traffic inspection across Virtual WAN.

Question 2

Which Virtual WAN type is required for an architecture that uses Azure Firewall, ExpressRoute, and inter-hub transit?

A. Basic Virtual WAN
B. Standard Virtual WAN
C. Basic virtual hub with a route table
D. Any Virtual WAN type

Correct answer: B

Explanation: Standard Virtual WAN supports Azure Firewall, ExpressRoute, inter-hub transit, point-to-site VPN, and other advanced capabilities. Basic Virtual WAN is limited primarily to site-to-site VPN connectivity.

Question 3

A company wants to centrally manage Azure Firewall policies across secured Virtual WAN hubs deployed in multiple regions.

Which service should it use?

A. Azure Network Watcher
B. Azure Bastion
C. Azure Firewall Manager
D. Azure DNS Private Resolver

Correct answer: C

Explanation: Azure Firewall Manager provides centralized management of firewall policies and secured virtual hubs across regions.

Question 4

An administrator is creating a Virtual WAN hub that will use Azure Firewall. Which address-space decision is appropriate?

A. Use an address space that overlaps with the largest connected VNet
B. Use a minimum /30 address space
C. Use a minimum /22 address space for a hub with Azure Firewall
D. Use the same address space as the on-premises network

Correct answer: C

Explanation: A Virtual WAN hub using Azure Firewall requires a minimum /22 address space to provide sufficient capacity for firewall scaling. The address space must also avoid overlap with connected networks.

Question 5

An organization wants to inspect traffic between two Azure VNets connected to the same Virtual WAN environment.

Which capability is most relevant?

A. Private traffic inspection through routing intent
B. Azure Storage firewall rules
C. Point-to-site VPN authentication
D. Azure Resource Locks

Correct answer: A

Explanation: Private traffic inspection allows traffic between connected private networks to be directed through a firewall or supported NVA.

Question 6

A security engineer enables branch-to-branch connectivity in Virtual WAN. What is the primary security concern?

A. Branches will no longer be able to use VPN
B. Branch-to-branch connectivity may create unintended trust paths
C. Azure Firewall will be automatically deleted
D. ExpressRoute will be converted to a public connection

Correct answer: B

Explanation: Branch-to-branch connectivity can allow one branch to communicate with another. It should be enabled only when required and should be evaluated against segmentation and inspection requirements.

Question 7

Which statement about the Virtual WAN hub address space is correct?

A. It can be changed at any time after hub deployment
B. It must overlap with the connected VNets
C. It cannot overlap with connected or on-premises address spaces
D. It is used only for point-to-site VPN clients

Correct answer: C

Explanation: The hub address space cannot be changed after creation and must not overlap with other Virtual WAN hubs, connected VNets, or on-premises networks.

Question 8

A company wants to connect individual employees to a Virtual WAN hub and authenticate them using Microsoft Entra ID.

Which connectivity option should it use?

A. Site-to-site VPN
B. Point-to-site user VPN
C. ExpressRoute Direct
D. VNet peering

Correct answer: B

Explanation: Point-to-site user VPN connects individual users or devices and can be configured with Microsoft Entra ID authentication.

Question 9

An administrator configures routing intent but users report that internet access is failing from a connected VNet. What should the administrator check first?

A. Whether the firewall policy allows the required outbound traffic
B. Whether every VM has a public IP address
C. Whether the VNet has a storage account
D. Whether Azure Bastion is deployed

Correct answer: A

Explanation: Routing internet traffic through Azure Firewall does not automatically allow it. The firewall policy must permit the required destinations, protocols, and ports.

Question 10

A security team needs to investigate unexpected VPN disconnects and routing changes in Virtual WAN.

What should it configure?

A. Azure Resource Locks only
B. Diagnostic settings that send Virtual WAN resource logs to a monitoring destination
C. A public IP address on every connected subnet
D. A separate Virtual WAN for every VPN connection

Correct answer: B

Explanation: Virtual WAN and related resources can produce resource logs that can be sent to Log Analytics, Event Hubs, or a storage account. These logs support troubleshooting, auditing, and security investigations.

Key Takeaways

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

Standard Virtual WAN is required for advanced enterprise capabilities.
A secured virtual hub integrates Azure Firewall with a Virtual WAN hub.
Azure Firewall Manager centralizes firewall policy management.
Routing intent directs private or internet-bound traffic through a security solution.
Connected networks are not automatically trusted.
Plan Virtual WAN hub address spaces carefully because they cannot be changed after creation.
Avoid address-space overlap.
Use least-privilege route propagation.
Secure site-to-site and point-to-site connectivity.
Monitor Virtual WAN resource logs, routes, gateways, and firewall activity.
Validate that traffic actually passes through the intended inspection point.