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 network access policies by using Azure Virtual Network Manager

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 Network Manager is a network-management service that provides centralized control over Azure virtual networks. It can organize virtual networks into groups and apply network configurations consistently across subscriptions and management groups.

For security, Azure Virtual Network Manager provides security admin rules. These rules allow a central networking or security team to enforce organization-wide network access policies across managed virtual networks.

Security admin rules complement, rather than replace, network security groups (NSGs):

• Security admin rules provide centrally managed security guardrails.
• NSGs provide workload- and subnet-level traffic filtering.
• Azure Firewall provides centralized, stateful traffic inspection and advanced firewall capabilities.

AVNM can also manage connectivity and routing configurations, but security admin rules are the primary feature for centrally enforcing network access policies.

1. Why Use Azure Virtual Network Manager?

Managing NSGs independently across many subscriptions can lead to:

• Inconsistent security policies
• Duplicate rules
• Accidental exposure of high-risk ports
• Difficulty enforcing organization-wide requirements
• Security gaps when new virtual networks or resources are created
• Conflicts between central security requirements and application-team configurations

AVNM addresses these challenges by allowing administrators to define security policies once and apply them to groups of virtual networks.

For example, an organization could centrally enforce the following policy:

Deny inbound SSH and RDP traffic from the Internet to all managed virtual networks unless an explicitly approved exception exists.

The central security team manages the security admin configuration, while application teams can continue managing their own NSGs for more specific workload requirements.

2. Understand the Main Azure Virtual Network Manager Components

Network manager instance

The network manager instance is the primary AVNM resource. It defines:

• The management scope
• The regions in which configurations can be deployed
• The features enabled for the instance

The management scope can include:

• Selected subscriptions
• Management groups

The network manager only manages resources within its defined scope. A virtual network outside that scope is not affected by the manager’s configurations.

Network groups

A network group is a logical collection of virtual networks to which configurations can be applied.

Membership can be:

• Static — administrators manually select virtual networks.
• Dynamic — Azure Policy conditions determine which virtual networks belong to the group.

Examples of network groups include:

• Production
• Development
• Corporate
• Internet-facing
• Regulated workloads
• High-security workloads
• Regional network groups

Dynamic membership is useful when new virtual networks should automatically receive the appropriate security policy based on tags, subscriptions, resource groups, or other policy conditions.

Configurations

AVNM supports several configuration types, including:

• Connectivity configurations
• Security admin configurations
• Routing configurations

A security admin configuration contains rule collections, and each rule collection contains security admin rules.

Deployment

Creating or modifying a configuration does not immediately apply it to the target virtual networks. The configuration must be deployed to the relevant regions.

This commit-and-deploy model allows administrators to prepare, review, and then deploy a configuration.

3. Understand Security Admin Rules

A security admin rule is a centrally defined network security rule that applies to virtual networks in targeted network groups.

A rule can specify:

• Priority
• Action
• Direction
• Protocol
• Source
• Destination
• Source ports
• Destination ports

Security admin rules support three actions:

1. Allow
2. Always allow
3. Deny

The rules are applied at the virtual-network level and are evaluated before NSG rules.

4. Security Admin Rule Actions

Allow

An Allow rule permits the specified traffic to continue to NSG evaluation.

This means that an NSG can still deny the traffic.

For example:

• A security admin rule allows inbound TCP 443.
• The subnet NSG denies inbound TCP 443.

The traffic is ultimately denied by the NSG.

Use Allow when central governance wants to permit a category of traffic but still wants workload owners to apply additional restrictions.

Always allow

An Always allow rule allows the traffic and prevents subsequent NSG rules from denying it.

Use this action only when central governance must guarantee that a particular flow is permitted.

For example, an organization might use an Always allow rule for a required management or monitoring flow.

Because Always allow bypasses subsequent NSG evaluation for the matching traffic, it should be used carefully.

Deny

A Deny rule blocks the traffic immediately.

NSG rules are not evaluated for traffic that matches the security admin deny rule.

This is useful for centrally blocking:

• Internet-based SSH
• Internet-based RDP
• Known high-risk ports
• Unauthorized network segments
• Traffic to sensitive workloads

The difference between the three actions is important for the exam:

5. Security Admin Rule Priority

Security admin rules use priorities from 1 through 4,096.

• Lower numbers have higher priority.
• A rule with priority 10 is evaluated before a rule with priority 100.
• A matching higher-priority rule can prevent a lower-priority rule from being evaluated.

Example

Suppose an organization has these rules:

The approved administration networks receive the higher-priority allow rule. Other managed networks are subject to the deny rule.

However, if the priority 10 rule uses Allow, the traffic still proceeds to NSG evaluation. If the rule must bypass a conflicting NSG deny rule, the administrator would need to use Always allow, assuming that action is appropriate for the requirement.

6. Security Admin Rules Versus NSGs

Security admin rules and NSGs have different scopes and purposes.

A security admin rule does not eliminate the need for NSGs. A common design is:

1. AVNM enforces organization-wide security requirements.
2. NSGs enforce application-specific access.
3. Azure Firewall provides centralized inspection where required.

7. Example: Centrally Blocking High-Risk Ports

An organization wants to prevent Internet-based access to:

• TCP 22 — SSH
• TCP 3389 — RDP

The security team creates a network group containing all managed virtual networks.

A security admin configuration contains rules such as:

After deployment, the rules apply to resources in the targeted virtual networks.

This approach is more reliable than asking every application team to create and maintain equivalent NSG deny rules independently.

8. Example: Allowing Approved Exceptions

Suppose an organization blocks inbound SSH from the Internet but has a small set of approved administration networks.

Create two network groups:

• All-Networks
• Approved-Admin-Networks

Then create security admin rules:

The more specific exception is evaluated first because it has the lower priority.

If the approved traffic must not be blocked by a workload NSG, use Always allow instead of Allow, subject to the organization’s security design.

The important principle is that exceptions should be narrowly scoped and have a higher priority than the broad deny rule.

9. Create a Network Manager Instance

The general implementation process is:

1. Create an Azure Virtual Network Manager instance.
2. Define its management scope.
3. Enable the Security admin feature.
4. Create network groups.
5. Add virtual networks to the groups.
6. Create a security admin configuration.
7. Add rule collections and rules.
8. Associate rule collections with network groups.
9. Deploy the configuration to the required regions.
10. Verify the resulting policy and connectivity.

The manager’s scope should be designed carefully. A manager scoped to a management group can govern virtual networks across multiple subscriptions within that scope.

10. Configure Network Group Membership

Static membership

With static membership, an administrator manually adds virtual networks to a network group.

This provides precise control but requires ongoing maintenance.

Use static membership when:

• The number of virtual networks is small.
• Membership changes are infrequent.
• The organization needs explicit approval for every member.

Dynamic membership

With dynamic membership, Azure Policy determines which virtual networks belong to the group.

For example, a policy could include virtual networks that:

• Have a specific tag
• Belong to a particular subscription
• Exist in a particular resource group
• Match a defined naming convention

Dynamic membership is useful in large environments because new qualifying virtual networks can be added automatically.

However, membership updates and configuration application are not necessarily instantaneous. Administrators should account for deployment and policy-evaluation delays.

11. Create a Security Admin Configuration

A security admin configuration contains one or more rule collections.

A rule collection generally defines:

• A collection name
• A set of security admin rules
• The network groups to which the collection applies

A rule should be designed around a clearly stated security requirement.

For example:

Block inbound RDP from the Internet to all production virtual networks.

The corresponding rule could specify:

• Direction: Inbound
• Protocol: TCP
• Source: Internet
• Destination: Any
• Destination port: 3389
• Action: Deny
• Priority: 100

The configuration is then associated with the appropriate production network group and deployed to the required regions.

12. Deployment and Eventual Consistency

AVNM configurations do not take effect merely because they have been created.

Administrators must deploy the configuration to the regions containing the target virtual networks.

There may also be a delay when:

• A configuration is first deployed
• A network group’s membership changes
• New resources are added to a managed virtual network
• A security admin rule is modified

Microsoft describes this as an eventual consistency model. A newly created resource may not receive the security admin rules immediately.

Exam consideration

If a rule appears not to be working immediately:

1. Confirm that the configuration was deployed.
2. Confirm that the deployment targeted the correct region.
3. Confirm that the virtual network belongs to the expected network group.
4. Allow time for membership and configuration propagation.
5. Verify whether the resource or subnet is exempt from security admin rules.

13. Important Exceptions and Limitations

Security admin rules do not apply universally.

Private endpoints in managed virtual networks

Security admin rules do not apply to private endpoints that fall under the scope of a managed virtual network.

Service-specific subnets

Certain service subnets are exempt because the services require specific network behavior.

Examples include subnets used by:

• Azure Application Gateway
• Azure Bastion
• Azure Firewall
• Azure Route Server
• Azure VPN Gateway
• Azure Virtual WAN
• Azure ExpressRoute Gateway

Azure SQL Managed Instance and Azure Databricks

By default, security admin rules are not applied to virtual networks containing certain services, including:

• Azure SQL Managed Instance
• Azure Databricks

These services can have network intent policies that conflict with security admin rules.

For supported scenarios, administrators can configure the security configuration to apply Allow rules only to such virtual networks. This does not mean that Deny rules are applied; the setting is specifically intended to avoid conflicts with service-required network policies.

14. Network Groups as Sources and Destinations

AVNM can use network groups to define the source and destination of security admin rules.

For example:

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

This expresses the intended relationship between groups of virtual networks rather than relying only on individual IP addresses.

However, the use of network groups as source and destination in security admin rules is identified in Microsoft documentation as a public-preview capability. Preview features may have limitations and should not automatically be assumed to be suitable for production workloads.

15. AVNM and Connectivity Configurations

Although this topic focuses on network access policies, AVNM also supports connectivity configurations.

Connectivity configurations can establish:

• Hub-and-spoke connectivity
• Mesh connectivity
• Regional mesh connectivity
• Global mesh connectivity

Security admin rules and connectivity configurations solve different problems:

• Connectivity configurations determine how virtual networks connect.
• Security admin configurations determine which traffic is permitted or denied.

A network can be connected but still have traffic blocked by security admin rules or NSGs.

AVNM’s configurations are additive in some scenarios, and multiple connectivity configurations can exist in a region. However, only one security admin configuration can be deployed to a region for a given network manager instance; multiple security rule collections can be placed within that configuration.

16. AVNM and Azure Firewall

Azure Virtual Network Manager security admin rules are not a replacement for Azure Firewall.

Use security admin rules for:

• Organization-wide allow or deny policies
• Blocking high-risk ports
• Enforcing network segmentation
• Applying consistent guardrails across many virtual networks
• Preventing workload NSGs from bypassing central deny rules

Use Azure Firewall for:

• Stateful traffic inspection
• Centralized network and application rules
• Threat intelligence filtering
• Centralized logging
• Advanced firewall policy management
• Traffic inspection between network segments

A defense-in-depth design may use AVNM security admin rules, NSGs, Azure Firewall, private endpoints, and application-layer controls together.

17. Best Practices

Define a clear management scope

Use a management group or carefully selected subscriptions that contain the virtual networks requiring centralized governance.

Separate central and workload responsibilities

Central security teams should manage organization-wide guardrails. Application teams should manage workload-specific NSGs.

Use deny-by-default principles

Block unnecessary traffic and permit only the flows required by the business or application.

Use specific priorities

Reserve priority ranges for:

• Emergency blocks
• Approved exceptions
• Standard organization-wide denies
• General allow rules

Use network groups strategically

Group virtual networks by meaningful characteristics such as:

• Environment
• Business unit
• Data sensitivity
• Regulatory requirements
• Internet exposure
• Application role

Use dynamic membership where appropriate

Dynamic membership reduces manual administration but requires careful Azure Policy design and awareness of propagation delays.

Test exceptions

Verify that approved exceptions work without unintentionally allowing broader access.

Avoid unnecessary Always allow rules

Always allow bypasses NSG denial for matching traffic. Use it only when central governance must guarantee the flow.

Document exclusions

Record why certain service subnets or virtual networks are exempt from security admin rules.

Verify after deployment

Confirm:

• The configuration is deployed
• The deployment succeeded
• The expected network groups contain the correct virtual networks
• The rules have the intended priorities
• Connectivity behaves as designed

Practice Exam Questions

Question 1

A company wants to centrally block inbound RDP traffic from the Internet across all production virtual networks. Individual application teams currently manage their own NSGs.

Which solution best meets the requirement?

A. Create a security admin Deny rule in Azure Virtual Network Manager and apply it to a production network group.
B. Create a separate NSG on every VM and configure an RDP deny rule.
C. Configure Azure DNS to block RDP traffic.
D. Add a route for TCP port 3389 to each subnet.

Correct answer: A

Explanation: Security admin rules provide centralized enforcement across managed virtual networks. A Deny rule blocks matching traffic before NSG evaluation.

Question 2

A security administrator creates an AVNM security admin rule with the action Allow for inbound TCP port 443. A subnet-level NSG denies the same traffic.

What happens?

A. The security admin Allow rule always overrides the NSG.
B. The traffic is allowed because security admin rules bypass NSGs.
C. The traffic is denied by the NSG.
D. The traffic is routed through Azure Firewall automatically.

Correct answer: C

Explanation: An Allow security admin rule permits traffic to continue to NSG evaluation. The NSG can still deny the traffic.

Question 3

An organization needs to guarantee that approved monitoring traffic is not blocked by workload-level NSGs.

Which security admin action should be considered?

A. Allow
B. Deny
C. Audit
D. Always allow

Correct answer: D

Explanation: Always allow permits the matching traffic and prevents subsequent NSG rules from denying it. It should be used carefully because it bypasses NSG denial for that flow.

Question 4

Which priority has the highest precedence in an Azure Virtual Network Manager security admin configuration?

A. 4,096
B. 2,000
C. 100
D. 10

Correct answer: D

Explanation: Lower priority numbers are evaluated first. Priority 10 has higher precedence than priorities 100, 2,000, and 4,096.

Question 5

An organization wants new virtual networks with the tag Environment=Production to automatically receive a centralized security policy.

What should the administrator use?

A. Static network group membership
B. Dynamic network group membership based on Azure Policy
C. A public IP prefix
D. An NSG attached to one production VM

Correct answer: B

Explanation: Dynamic network group membership uses policy-based conditions to determine which virtual networks belong to a group.

Question 6

An administrator creates a security admin configuration but traffic is still permitted through a virtual network that should be protected.

What should be checked first?

A. Whether the configuration was deployed to the correct region
B. Whether the VM has a larger SKU
C. Whether the virtual network has a DNS server
D. Whether the VM has an availability set

Correct answer: A

Explanation: AVNM configurations do not take effect until they are deployed to the relevant regions. Incorrect or missing deployment is a common cause of unexpected behavior.

Question 7

Which statement correctly describes the relationship between security admin rules and NSGs?

A. NSGs are evaluated before security admin rules.
B. Security admin rules and NSGs cannot be used together.
C. Security admin rules are evaluated before NSGs.
D. Security admin rules apply only to public IP addresses.

Correct answer: C

Explanation: Security admin rules provide centralized network-level enforcement and are evaluated before NSG rules.

Question 8

A virtual network contains Azure SQL Managed Instance. The administrator notices that the expected security admin Deny rules are not being applied.

What is the most likely explanation?

A. SQL Managed Instance supports only public IP addresses.
B. Security admin rules are never applied to production networks.
C. NSGs automatically disable AVNM.
D. Certain service network intent requirements can cause security admin rules to be skipped by default.

Correct answer: D

Explanation: Azure SQL Managed Instance and certain other services have network intent policies that can conflict with security admin rules. Such virtual networks may be exempt by default, with supported Allow-rules-only behavior available for applicable scenarios.

Question 9

A company wants to centrally deny Internet-based SSH traffic but permit SSH from an approved administration network. Which design is most appropriate?

A. Create a lower-priority allow exception for the approved network and a broader higher-numbered deny rule for all managed networks.
B. Create only an allow rule for the Internet.
C. Create a deny rule for the approved administration network.
D. Remove all NSGs from the virtual networks.

Correct answer: A

Explanation: The approved exception should have a lower priority number than the broad deny rule. If the exception must bypass NSG denial, the administrator should evaluate whether Always allow is appropriate.

Question 10

Which statement about Azure Virtual Network Manager security admin rules is correct?

A. They replace Azure Firewall for stateful traffic inspection.
B. They directly modify the operating-system firewall on each VM.
C. They can enforce centralized network policies across virtual networks in targeted network groups.
D. They apply automatically to every virtual network in every Azure tenant.

Correct answer: C

Explanation: AVNM applies centralized security admin rules to virtual networks in network groups within the manager’s defined scope. It does not replace Azure Firewall, modify guest operating-system firewalls, or automatically govern resources outside its scope.

Go to the SC-500 Exam Prep Hub main page