7.2 Azure Virtual Network Manager Security Admin Rules

Why Virtual Network Manager Appears on SC-500

The blueprint calls out implement and configure network access policies by using Azure Virtual Network Manager. In large landing zones, thousands of VNets and application teams cannot each invent Internet RDP exposure or skip baseline denies. Azure Virtual Network Manager (AVNM) is the control plane for:

1. Network groups — dynamic or static collections of virtual networks (often with Azure Policy-driven membership).
2. Connectivity configurations — mesh and hub-and-spoke topologies at scale.
3. Security admin configurations — global Layer-3/4 rules enforced on member VNets.

NSGs remain the application-team tool. Security admin rules are the central governance tool. Exam stems often test whether you pick the control that cannot be undone by a careless NSG allow.

---

Network Groups: The Scope Unit

A network group is the set of virtual networks a configuration targets. Membership can be:

Security admin rules apply to virtual networks in the group, not to unmanaged VNets outside the AVNM scope. When a VNet joins a group with a deployed security configuration, resources in that VNet receive the admin rules (eventual consistency—brief delay after create/join).

Design tip: Align groups to governance boundaries—Production, Sandbox, PCI, Hub-Shared—not to every application name. Application micro-segmentation still uses ASGs/NSGs inside those VNets.

---

Connectivity Configurations (Overview for Security Engineers)

Connectivity configuration is not the same as security admin configuration, but SC-500 expects conceptual literacy because topology and security travel together in enterprise designs.

Optional settings you will see in documentation and exams:

• Direct connectivity among spokes in a group (adds a connected group on top of hub-spoke).
• Global mesh for cross-region spoke-to-spoke within a group.
• Use hub as a gateway so spokes use hub VPN/ExpressRoute gateways.
• Peering enforcement so critical peerings cannot be deleted outside AVNM.

Address overlap: Mesh can include overlapping address spaces, but traffic to overlapping prefixes is dropped (nondeterministic routing). Some configurations can disallow overlap. Do not assume mesh magically fixes IP planning mistakes.

Connectivity configs can coexist regionally in multiple forms; security admin has a stricter deployment rule (next section).

---

Security Admin Rules vs NSGs

This comparison is core exam material:

Action types and evaluation termination

1. Allow (admin): Traffic is permitted at the admin layer, then continues to NSG evaluation. Teams can still deny with NSGs.
2. Always Allow: Traffic is forced allowed; NSGs cannot deny it. Evaluation stops. Use sparingly for mandatory management or monitoring paths that app teams must not block.
3. Deny: Traffic is blocked; NSGs never see it. Evaluation stops. Ideal for “no Internet RDP/SSH anywhere in prod.”

Exam trap: “Always Allow” is not the same as “Allow.” If the goal is a non-negotiable open path, Always Allow. If the goal is “central allow but local teams may tighten,” use Allow.

Admin rules also have priority (1–4096, lower number higher priority), direction, protocol (TCP, UDP, ICMP, ESP, AH, Any), and source/destination as IP/CIDR or service tags (with a few platform tags unsupported).

High-risk ports baseline

Microsoft guidance for security admin rules commonly blocks management and historically abused ports from untrusted sources—examples include 22 (SSH), 3389 (RDP), 445 (SMB), unencrypted FTP ports, and other remote management vectors. Create exceptions (higher-priority allows from Bastion subnet, jump host ASG/CIDR, or Always Allow only where justified) rather than leaving Internet exposure.

---

Configuration Structure and Deployment

Think of the object model as:

Virtual Network Manager instance
  └── Security admin configuration
        └── Rule collection(s)  → associated to network group(s)
              └── Security admin rule(s)

Deployment notes:

• You deploy configurations to target regions. Rules are not live from save alone—deployment is the commit step.
• Only one security admin configuration can be deployed to a given region at a time. Need multiple rule sets? Put multiple rule collections inside that single security configuration rather than expecting several simultaneous security configs per region.
• Multiple connectivity configurations can exist more flexibly than security admin deployments.
• Eventual consistency: after deploy or after adding VMs/VNets, allow a short propagation window.

Non-application / exceptions

Some platform services have network intent policies. Security admin rules may skip certain VNets or subnets (examples historically include subnets hosting Azure Firewall, Bastion, VPN Gateway, ExpressRoute Gateway, Virtual WAN components, and some services like SQL Managed Instance or Databricks at VNet level unless special allow-rules-only modes are used). For SC-500, remember: admin rules are powerful but not literally universal on every platform subnet—do not assume they replace service-specific required rules.

Private endpoints: Security admin rules currently do not apply to private endpoints under a managed VNet in the same way as ordinary NICs—design private endpoint controls with NSG network policies, Private Link, and PaaS firewalls as appropriate.

---

Enterprise-Scale Use Cases

Governance model: Platform team owns AVNM + admin baselines. Application teams own NSGs/ASGs for micro-segmentation inside the allowed envelope. Network Watcher effective security rules show both layers on a NIC.

---

Worked Scenario: Contoso Landing Zone

Contoso has 120 spoke VNets. Auditors require: no direct Internet RDP/SSH; DNS to Azure DNS allowed; app teams still control HTTP east-west.

Solution sketch:

1. Deploy AVNM at the intermediate root management group scope covering landing-zone subscriptions.
2. Dynamic network group ng-prod for VNets with env=prod.
3. Security admin configuration with rule collection on ng-prod:
   • Priority 100: Deny inbound Internet → any on TCP 3389.
   • Priority 110: Deny inbound Internet → any on TCP 22.
   • Priority 200: Allow inbound VirtualNetwork → VirtualNetwork on necessary ports or leave east-west to NSGs after a broad admin Allow if required by design.
4. Deploy to all regions hosting prod hubs/spokes.
5. App teams attach subnet NSGs + ASGs for tiering.
6. Validate a random VM NIC with Network Watcher effective rules—confirm admin Denies appear above NSG allows.

If a team creates an NSG Allow Internet→3389 at priority 100, admin Deny still wins (evaluated first and terminates). That is the SC-500 punchline for central enforcement.

SC-500 Exam Traps (AVNM)

• Admin rules outrank NSGs; Always Allow/Deny stop NSG processing.
• Deploy the configuration—saving is not enforcement.
• One security admin configuration per region deployment slot—use rule collections for multiple policies.
• Connectivity mesh ≠ secure by default; pair with admin rules/NSGs.
• ASGs are not AVNM network groups (NICs vs VNets).
• Admin rules are not a full substitute for Azure Firewall L7 inspection.