Technical Lab: Implement and manage virtual network connectivity by using Azure Virtual Network Manager
Questions
Question 1 — Multiple Choice
A network team needs to apply a connectivity policy that forces all VNets in a subscription to route traffic between each other without requiring individual peering configuration. The environment has VNets in multiple regions and the requirement is that new VNets added to the scope are automatically included.
Which combination of Azure Virtual Network Manager resources meets this requirement?
A) Network group with static membership + Mesh connectivity configuration type
B) Network group with policy-based dynamic membership + Mesh connectivity configuration type
C) Network group with policy-based dynamic membership + Hub and Spoke connectivity configuration
D) Network group with static membership + Hub and Spoke connectivity configuration
Question 2 — Technical Scenario
An administrator created an Azure Virtual Network Manager with scope on a subscription, defined a network group, created a Hub and Spoke connectivity configuration and clicked "Save". After waiting a few minutes, they verified that no peering was created between the member VNets and the hub VNet.
Network Manager Scope: Subscription A
Network Group: group-prod (3 VNets as static members)
Connectivity Config: HubSpoke-Config (hub: vnet-hub, spokes: group-prod)
Configuration Status: Saved (not deployed)
What is the cause of the observed behavior?
A) The member VNets need to be in the same region as the hub VNet for peering to be created automatically
B) The configuration was saved but not deployed to any region; deployment is a separate and mandatory step
C) Network groups with static members do not support Hub and Spoke configuration types
D) Network Manager needs explicit Contributor permission on each individual VNet to create peerings
Question 3 — True or False
A security admin rule defined in Azure Virtual Network Manager can block traffic in a VNet even if a Network Security Group applied to that VNet's subnet explicitly allows that traffic.
True or False?
Question 4 — Technical Scenario
An organization uses Azure Virtual Network Manager with the following configuration:
Topology: Hub and Spoke
Hub: vnet-hub (region: East US)
Spokes: vnet-app1, vnet-app2 (region: East US)
Enabled option: "Enable direct connectivity between spokes"
The team reports that vnet-app1 can communicate with vnet-hub, but cannot communicate directly with vnet-app2, even with direct connectivity option enabled.
After investigation, it is found that the configuration was redeployed in the correct region. What is the most likely cause?
A) Direct connectivity between spokes in Hub and Spoke topology requires VNets to be in different regions
B) The "Enable direct connectivity between spokes" option creates a route but not direct peering; traffic still depends on an NVA in the hub
C) The configuration was deployed, but no previous deployment was removed, generating state conflict
D) There is an NSG in one of the subnets of vnet-app2 blocking traffic; security admin rules do not override NSGs in spoke-to-spoke topology
Question 5 — Multiple Choice
When defining the scope of an Azure Virtual Network Manager, which statement below correctly describes a real platform limitation?
A) A Network Manager can have a management group as scope, but cannot manage VNets from child subscriptions contained in that group
B) A Network Manager can manage VNets from multiple subscriptions as long as those subscriptions are within the defined scope (subscription or management group)
C) A Network Manager's scope is immutable after creation; to change scope it is necessary to recreate the resource
D) A Network Manager created in subscription A cannot include VNets from subscription B in scope, even if both are in the same management group
Answer Key and Explanations
Answer Key — Question 1
Answer: B
Automatic inclusion of new VNets requires dynamic membership, which uses Azure Policy to evaluate resources and add them to the network group without manual intervention. Static membership (options A and D) requires each VNet to be added explicitly, which contradicts the automatic inclusion requirement.
The Mesh topology creates peering between all network group members, establishing any-to-any connectivity. Hub and Spoke topology (option C) would partially meet the requirement, but does not create direct communication between all members by default, requiring routing through the hub.
A common misconception is assuming that Hub and Spoke with direct connectivity enabled equals Mesh. The fundamental difference lies in the architectural intent and default routing behavior of each topology.
Answer Key — Question 2
Answer: B
In Azure Virtual Network Manager, saving a configuration and deploying it are distinct steps. Saving persists the configuration definition in the control plane, but does not apply any changes to VNets. Deployment (Deploy) is the act of sending the configuration to specific regions, which actually creates peerings and applies policies.
Option A is incorrect because AVNM Hub and Spoke supports global peering between regions. Option C is incorrect because static members are fully supported in Hub and Spoke topologies. Option D represents a misconception about permissions: Network Manager needs permission at the defined scope, not necessarily on each VNet individually, although it needs sufficient access to manage network resources.
The error of not deploying after saving is one of the most frequent in real environments and in exams.
Answer Key — Question 3
Answer: True
Security admin rules operate at a precedence layer above NSGs. They are evaluated before NSG rules and can enforce blocking or allowing traffic regardless of what the NSG defines.
This is especially relevant in centralized governance scenarios, where the platform team needs to ensure certain traffic policies cannot be bypassed by individual VNet administrators who control their own NSGs.
A common confusion is equating security admin rules to NSG behavior, assuming the most specific rule prevails. In AVNM, the hierarchy is intentional: security admin rules take precedence over NSGs by design.
Answer Key — Question 4
Answer: C
When a configuration is redeployed without the previous deployment being explicitly removed (or cleanly replaced), state conflicts can occur between the active configuration and the new one. The expected behavior after enabling "Enable direct connectivity between spokes" is the creation of direct peering between spokes, which should allow communication without passing through the hub.
Option A is incorrect because direct connectivity between spokes is supported in both intra-region and inter-region scenarios. Option B represents a relevant conceptual misconception: the direct connectivity option precisely creates direct peering between spokes, it does not depend on NVA. Option D reverses the hierarchy: security admin rules take precedence over NSGs, not the other way around, and the scenario describes absence of communication, not NSG blocking.
In real environments, always check deployment history and current state before diagnosing connectivity failures in AVNM.
Answer Key — Question 5
Answer: B
Azure Virtual Network Manager supports scopes at subscription or management group level. When the scope is a management group, all subscriptions contained within it (including nested child subscriptions) are eligible for management, enabling centralized governance at organizational scale.
Option A is false: this is exactly the most valuable use case for management group scope. Option C is false: scope can be modified after creation. Option D is false and represents the most common misconception: as long as subscription B is within the management group defined as scope, Network Manager can manage its VNets normally.
Understanding scope hierarchy is essential for designing centralized connectivity solutions in multi-subscription environments.