Skip to main content

Technical Lab: Implement and manage virtual network security by using Azure Virtual Network Manager

Questions​

Question 1 — Multiple Choice​

Azure Virtual Network Manager (AVNM) operates with two main configuration types: connectivity and security. When designing a hub-and-spoke topology managed by AVNM, an architect needs to ensure that spoke VNets do not communicate directly with each other, only with the hub. Which AVNM feature controls this behavior declaratively?

A) A security configuration with deny rules between spoke network groups, applied via deployment.

B) A connectivity configuration of hub-and-spoke type with the direct connectivity option between spokes disabled.

C) A routing policy applied to the network group that removes routes between spokes at the UDR level.

D) An administrative NSG with maximum priority deny rules associated with each spoke subnet.

Question 2 — Technical Scenario​

A platform team uses AVNM to manage 40 VNets distributed across three subscriptions. They created a static network group called ng-producao and manually added 15 VNets. After a reorganization, five new production VNets were created but don't appear in the group. The network manager requests that new production VNets be included automatically without manual intervention.

Which change resolves this requirement?

A) Convert the network group to dynamic and define an Azure Policy with conditions based on VNet tags or names.

B) Enable the auto-membership option in AVNM settings, which detects VNets created after group formation.

C) Create a subscription-level network group that automatically includes all VNets from selected subscriptions.

D) Replace the static group with a connectivity configuration with subscription scope, which groups VNets implicitly.

Question 3 — True or False​

In Azure Virtual Network Manager, security admin rules take precedence over NSG rules associated with subnets or NICs, and cannot be overridden by higher numerical priority NSG rules defined by VNet owners.

Question 4 — Technical Scenario​

An engineer applies a security configuration via AVNM with the following admin rule:

Rule: block-rdp-inbound
Action     : Deny
Direction  : Inbound
Protocol   : TCP
Dest Port  : 3389
Priority   : 100

After deployment, an administrator of one of the managed VNets creates an NSG with the following rule:

Rule: allow-rdp
Action     : Allow
Direction  : Inbound
Protocol   : TCP
Dest Port  : 3389
Priority   : 100

What is the resulting behavior for RDP traffic on VMs in this VNet?

A) The NSG rule prevails because it has the same numerical priority as the AVNM admin rule.

B) RDP traffic will be blocked, as AVNM security admin rules are evaluated before NSG rules and cannot be overridden by them.

C) The behavior is indeterminate, as equal priority conflicts between rules from different sources require manual resolution in the portal.

D) The NSG rule prevails because it's applied directly at the NIC or subnet level, while the AVNM rule acts only at the VNet level.

Question 5 — Multiple Choice​

When working with Azure Virtual Network Manager, an engineer needs to understand the difference between deployment of a configuration and simply creating or editing the configuration in the portal. Which statement correctly describes this distinction?

A) Creating the configuration already applies policies to VNets in the network group; deployment is only necessary to update existing configurations.

B) Deployment is the process that effectively propagates and applies the configuration to network resources in selected regions; without it, changes exist only as a draft in AVNM.

C) Deployment replicates the configuration between Azure regions to ensure AVNM high availability, without direct impact on network resources.

D) Creating the configuration applies rules immediately to VNets, and deployment is used only to generate a compliance report of the changes.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

Explanation:

  • In AVNM, the hub-and-spoke connectivity configuration has an explicit option called "direct connectivity" between spokes. When this option is disabled, traffic between spokes is forced to go through the hub, respecting the desired topology. This configuration is declarative and centrally managed by AVNM.
  • Alternative A confuses the correct mechanism: security rules control traffic permission but don't define connectivity topology between VNets. Disabling direct connectivity is a topology decision, not a security one.
  • Alternative C is incorrect because AVNM doesn't directly manage UDRs as a hub-and-spoke topology mechanism; UDRs are separate resources.
  • Alternative D describes a valid security approach but is operationally inferior: it requires managing individual NSGs instead of a centralized AVNM configuration.

Answer Key — Question 2​

Answer: A

Explanation:

  • Dynamic network groups in AVNM use Azure Policy to define automatic inclusion criteria. When a VNet is created and meets the condition defined in the policy (such as an environment=producao tag or a name pattern), it's automatically included in the group without manual intervention.
  • Alternative B describes functionality that doesn't exist in AVNM: there's no option called "auto-membership" directly configurable in the product; dynamic association is always mediated by Azure Policy.
  • Alternative C is a non-existent concept: there's no group type called "subscription-level network group" with automatic inclusion of all VNets from a subscription as default behavior.
  • Alternative D confuses connectivity configuration with resource grouping; these are distinct entities in AVNM and are not interchangeable.

Answer Key — Question 3​

Answer: True

Explanation:

  • AVNM security admin rules form a security layer evaluated before NSG rules. They're designed for central platform administrators to define policies that cannot be bypassed by local teams managing individual NSGs.
  • This is especially relevant in organizations with multiple teams: a deny rule in AVNM blocks traffic regardless of any allow rule in the local NSG, even if the NSG has lower numerical priority (higher NSG precedence). The evaluation hierarchy is: security admin rules first, NSG second.
  • The common misconception is assuming that an NSG rule's numerical priority can "beat" an AVNM administrative rule. The two layers are independent and the AVNM layer always has structural precedence.

Answer Key — Question 4​

Answer: B

Explanation:

  • AVNM security admin rules are evaluated by the data plane before NSG rules. A Deny rule in AVNM blocks traffic at the security administration layer, and this block cannot be reversed by an Allow rule in an NSG, regardless of that NSG's numerical priority.
  • Alternative A represents the most common error: applying NSG numerical priority logic (where lower numbers have precedence) to the relationship between AVNM and NSG. This relationship is not about comparable numerical priority, but distinct hierarchical layers.
  • Alternative C is incorrect: there's no indeterminate behavior in this case; the AVNM specification clearly defines that security admin rules have precedence.
  • Alternative D reverses the hierarchy: the physical proximity of the rule (NIC/subnet) doesn't determine precedence when there's a centralized administration layer through AVNM above NSGs.

Answer Key — Question 5​

Answer: B

Explanation:

  • In AVNM, creating or editing a configuration is a control plane operation on the manager that produces a draft. Only after explicit deployment, targeted to specific regions, are configurations effectively applied to network resources (VNets, network groups). This two-stage model is intentional and allows review before application.
  • Alternative A reverses the behavior: creation never applies automatically; deployment is mandatory for both new configurations and updates.
  • Alternative C describes replication for high availability, which is not the deployment function; AVNM doesn't use deployment as a geographic redundancy mechanism for the service itself.
  • Alternative D also reverses the behavior and attributes to deployment a reporting function, which doesn't correspond to its actual role of propagation and effective application of configurations.