A water-lab engineer saved a security admin configuration that denies inbound Internet to a network group, then opened a test VM and found the port still reachable. What step is missing?
Select an answer to reveal the explanation.
Short Explanation
Saving an AVNM config is like drafting a city ordinance—nothing sticks until you deploy it to the regions that host those VNets.
Full Explanation
Azure Virtual Network Manager security configurations must be created, associated with network groups, and deployed to regions before they enforce. A water-lab engineer who only saved a Deny inbound Internet configuration still has a draft until it is deployed to the regions holding those VNets—so a test VM can remain reachable until deployment completes.
Enabling NSG flow logs and assuming a saved draft is enforced fails: logs do not deploy AVNM configurations. Deleting the network group so orphaned admin rules apply globally fails by concept. Converting every subnet NSG into an Application Security Group does not activate AVNM drafts.
Exam caveat: create, associate, then deploy is the AVNM operational sequence tested on exams. Operational check: deploy the configuration to the correct regions, wait for success, retest the previously open port (should deny), and document deployment pipelines so drafts cannot be mistaken for production enforcement. 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. 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.