AZ-104 Manage Azure Identities and Governance Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Step 1: Create the virtual network with address space. Step 2: Add a subnet. Step 3: Associate a Network Security Group (NSG) to the subnet. Step 4: Deploy a virtual machine into the subnet. Step 5: Verify network connectivity.

  Why this is correct

  This is the correct sequence. First you define the VNet and its CIDR address space, then partition it into at least one subnet to provide a logical segment for resources. Associating an NSG to that subnet applies allowed/denied traffic rules before any VM is deployed, so the VM launches with its intended security posture from the first boot. Finally, deploying the VM targets the subnet and NSG-protected environment, and verification confirms IP connectivity and security rules behave as designed.

• ✗

  Step 1: Create the virtual network with address space. Step 2: Deploy the virtual machine. Step 3: Add a subnet. Step 4: Associate an NSG to the subnet. Step 5: Verify network connectivity.

  Why it's wrong here

  This order is invalid because a virtual machine cannot be deployed without a subnet existing. During VM creation (portal, CLI, or template), you must specify an existing virtual network and subnet for the NIC; the subnet is a mandatory parameter and cannot be created after the VM. Skipping or reordering the subnet creation causes the deployment to fail with a resource-not-found error.

• ✗

  Step 1: Create the virtual network with address space. Step 2: Add a subnet. Step 3: Deploy the virtual machine. Step 4: Associate an NSG to the subnet. Step 5: Verify network connectivity.

  Why it's wrong here

  This order incorrectly prioritizes VM deployment over NSG association. While a VM can technically be deployed without an NSG, best practice is to associate the NSG to the subnet first so that the planned inbound and outbound rules are evaluated as soon as the VM's NIC comes online. Deploying the VM first leaves a time window during which traffic is governed only by Azure's default rules, potentially allowing unintended access to the instance.

• ✗

  Step 1: Deploy the virtual machine. Step 2: Create the virtual network with address space. Step 3: Add a subnet. Step 4: Associate an NSG to the subnet. Step 5: Verify network connectivity.

  Why it's wrong here

  This sequence cannot work because a VM is a resource that depends on foundational network infrastructure: it requires a virtual network and a subnet before its NIC can be attached. Azure does not support dynamically creating a VNet or subnet at the moment of VM deployment; both must be pre-existing resources. Consequently, starting the process with a VM deployment is fundamentally invalid and the request will be rejected.

Go deeper

Related to this question