Practice Test #4

No. A resource group's location only determines where the resource group's metadata is stored; it does not determine the location of resources inside the group. Because the scenario does not explicitly state the location of storage1, you cannot conclude that storage1 is in West US just because it is in RG1. Therefore the statement is false, while move-related statements must be evaluated based on resource support rather than resource group region.

No. The location of a virtual network is its own property and is not inherited from the resource group. The scenario never states that VNet1 is in West US, so the statement cannot be confirmed as true. Although NICs and VMs must align regionally with the VNet they use, that still does not let you infer the VNet's region from the resource group's location alone.

No. A network interface has its own Azure region and does not inherit the region of its resource group. While a NIC must be in the same region as the virtual network/subnet and VM it is associated with, the scenario does not explicitly provide those resource locations. Since RG1 being in West US is not enough to prove NIC1 is in West US, the statement is false.

No. Managed disks are regional resources, but their region is not determined by the resource group's location. Even though an attached managed disk must be in the same region as its VM, the scenario never explicitly states VM1's region. Therefore you cannot assert that Disk1 is in West US, so the statement is false.

No. Virtual machines have their own location property, and that property is independent of the resource group's location. The fact that VM1 is in RG1 does not mean VM1 is in West US, because Azure allows resources in a resource group to exist in different regions. Since the scenario does not explicitly state VM1's region, the statement is false.

Yes. You can move a storage account between resource groups within the same subscription. This is a common Azure Resource Manager operation used for reorganizing resources for governance, billing, or lifecycle management. Important constraints: the move does not change the storage account’s location (it would remain West US), and you must ensure there are no move-blocking locks or policies. Also, some resources have dependencies that must be moved together, but storage accounts are generally move-supported. So, moving storage1 to RG2 is allowed (assuming same subscription and no locks), and only the resource group assignment changes.

No. NIC1 is attached to VM1 (VM1 “connects to NIC1”). A NIC that is in use by a VM is a dependent resource and typically cannot be moved on its own to another resource group while still attached. In Azure, when you move resources, you must include all required dependent resources in the same move operation. For a VM, that commonly includes the VM resource, its NIC(s), and sometimes other dependencies. Attempting to move only NIC1 to RG2 would fail because VM1 would still reference it. Therefore, you cannot move NIC1 to RG2 by itself in this scenario. The correct approach would be to move VM1 and its dependent resources together (or detach the NIC if the platform and configuration allow, which is not implied here).

No. Moving a resource between resource groups does not change the resource’s location/region. The location property is set at creation time for regional resources like Public IP addresses. IP2 is explicitly stated to be in East US and is currently in RG2. If you move IP2 to RG1, only the resource group changes; IP2 remains an East US public IP. This is a key AZ-104 concept: resource group is a management container, not a mechanism to redeploy resources into a different region. To change a resource’s region, you generally must recreate it in the target region (or use a service-specific migration method), not simply move it to a different resource group.

App1 cannot be moved to RG2 because RG2 has a ReadOnly management lock applied at the resource group scope. A ReadOnly lock means you can view resources but cannot perform operations that modify the resource group’s contents, including adding resources to the group or moving resources into it. The move operation is treated as a write action (it changes the resource’s resourceGroup property and updates ARM metadata), so it is blocked. The fact that RG2 is in West Europe (same as App1) does not help; resource group location does not restrict which regions its resources can be in, and moving between RGs does not change the resource’s region anyway. The lock is the deciding factor.

App1 can be moved to RG3. RG3 has a Delete (CanNotDelete) lock, which prevents deletion of the resource group or resources within it, but it does not prevent updates or write operations such as moving a resource into the group. Therefore, the lock type does not block the move. Although RG3 is in a different region (East Europe), that is not a blocker because resource group location is not a placement constraint for resources, and moving a Web App between resource groups does not change the Web App’s region (App1 would remain in West Europe). The main assumption for cross-subscription moves is that Subscription1 and Subscription2 are in the same Azure AD tenant and you have sufficient permissions; the question typically assumes these prerequisites are met unless stated otherwise.

App1 can be moved to RG4 because RG4 has no management lock, so there is no governance control preventing write operations like a resource move. As with RG3, the fact that RG4 is shown as Central US does not prevent placing a West Europe resource in that resource group; the resource group’s region is not a constraint on resource regions, and the move does not relocate the Web App to Central US. This is a cross-subscription move (Subscription1 to Subscription2). For AZ-104, remember the typical prerequisites: both subscriptions must be under the same Azure AD tenant, you must have appropriate RBAC permissions on source and target scopes, and the resource type must support moves. App Service Web Apps support resource group and subscription moves under normal conditions.