Production lock VNets across three subscriptions must share one network security baseline, while a sandbox VNet must stay out. Where should the security engineer apply the Azure Virtual Network Manager security admin configuration?
Select an answer to reveal the explanation.
Short Explanation
Herd the production lock VNets into an AVNM network group, hang the security admin config on that group, and leave the sandbox cow outside the fence.
Full Explanation
Azure Virtual Network Manager targets security admin and connectivity configurations at network groups of virtual networks. To share one network security baseline across production lock VNets in three subscriptions while excluding a sandbox VNet, put the production VNets in an AVNM network group and associate the security admin configuration with that group—not with the sandbox.
Assigning an Azure Policy initiative at the management group fails as a network datapath enforcer substitute for AVNM security admin rules. Attaching the security admin configuration directly to every NIC in the sandbox only fails the production scope requirement. Publishing the baseline as an NSG flow-log workspace query fails because queries observe traffic; they do not enforce a baseline.
Exam caveat: network groups are the scoping primitive for AVNM configurations. Operational check: create a production network group, add the three-subscription VNets, exclude sandbox, associate and deploy the security admin configuration, and verify sandbox remains unaffected. In municipal Azure estates, document the decision in the change record, validate with a nonproduction rehearsal, and confirm monitoring still pages the on-call operator when the control fails closed during an incident drill.