Hotspot Question You have an Azure subscription that contains the resource groups shown in the following table. RG1 contains the resources shown in the following table. RG2 contains the resources…

Question

Exhibits

Answer Area

• Resources that you can move from RG1 to RG2:
  NoneIP1 onlyIP1 and storage1 onlyIP1 and VNET1 onlyIP1, VNET2, and storage1
• Resources that you can move from RG2 to RG1:
  NoneIP2 onlyIP2 and storage2 onlyIP2 and VNET2 onlyIP2, VNET2, and storage2

Explanation

The correct selections indicate that Public IP addresses, Storage Accounts, and Virtual Networks (assuming no blocking dependencies or that dependencies are moved concurrently) are movable between resource groups, even if resources in different RGs share the same name.

Approach. The question asks to identify which resources can be moved between Resource Group 1 (RG1) and Resource Group 2 (RG2). Based on the correct selections shown in the image:

1. Resources that you can move from RG1 to RG2: The correct selection is 'IP1, VNET2, and storage1'. This implies that a Public IP (IP1), a Virtual Network (VNET2), and a Storage Account (storage1) that are initially located in RG1 can all be successfully moved to RG2. Public IP addresses and Storage Accounts are generally highly movable between resource groups within the same subscription and region. Virtual Networks (VNETs) are also movable, provided they do not have active dependencies (like VMs, VPN gateways, etc.) that cannot be moved with them, or if those dependent resources are included in the move operation. For this selection to be correct, we assume these conditions are met for VNET2 in RG1.

2. Resources that you can move from RG2 to RG1: The correct selection is 'IP2, VNET2, and storage2'. Similarly, this implies that a Public IP (IP2), a Virtual Network (VNET2), and a Storage Account (storage2) that are initially located in RG2 can all be successfully moved to RG1. The same movability principles apply here.

Key Insight for 'VNET2': The appearance of 'VNET2' in both correct selections implies that there are two distinct virtual networks, both coincidentally named 'VNET2' but residing in separate resource groups (one in RG1, one in RG2). If 'VNET2' referred to a single resource, it could only be moved from its original resource group once, not from both simultaneously. Azure resource names are unique within a resource group (for most resource types), but resources with identical 'friendly' names can exist in different resource groups if their full Azure Resource Manager IDs are distinct.

Common mistakes.

• common_mistake. Common mistakes stem from a misunderstanding of Azure resource group move capabilities and limitations:

• Ignoring Dependencies: Attempting to move a resource without its required dependencies (e.g., moving a VNet without the VMs deployed within it, or a Public IP without its associated network interface). This will cause the move to fail.
• Regional Restrictions: Resources cannot be moved between regions. While not explicitly stated in the question, assuming a move is possible implies resources are in compatible regions. Selecting resources from different regions would be incorrect.
• Unsupported Resource Types: Not all Azure resource types support resource group moves. While Public IPs, Storage Accounts, and VNETs generally do, certain other resources may not (e.g., some types of Azure Load Balancers or specific VM configurations).
• Confusing Resource Naming: Failing to recognize that 'VNET2' appearing in both lists implies two distinct resources. If one incorrectly assumes 'VNET2' is a single, global resource, they might incorrectly conclude it cannot be moved from both RG1 and RG2, leading to an incorrect selection like 'None' or omitting VNET2 from one of the options.

Concept tested. The core concept tested is the ability to move Azure resources between resource groups, including understanding resource dependencies, regional constraints, and the specific movability support for common Azure resource types like Public IP addresses, Storage Accounts, and Virtual Networks.

No community discussion yet for this question.