Technical Lab: Manage Resource Groups
Questions
Question 1 — Multiple Choice
An operations team needs to move a set of resources from the resource group rg-producao-eastus to rg-producao-westus. The administrator performs the move operation through the Azure portal and receives an error indicating that one of the resources does not support the Move operation.
Which of the options below correctly describes the expected Azure behavior in this scenario?
A) The move is completely blocked until all resources in the group support the operation, without moving any resources partially.
B) Azure automatically moves compatible resources and leaves incompatible ones in the source group without notifying the administrator.
C) The administrator can individually select resources that support the operation and move them, leaving incompatible ones in the source group.
D) The move is only allowed between resource groups within the same region, as resources cannot change logical location.
Question 2 — Technical Scenario
An administrator applies the following lock to a production resource group:
az lock create \
--name "lock-producao" \
--resource-group rg-producao \
--lock-type ReadOnly
Later, a developer tries to list the access keys of a Storage Account contained in this resource group using the command:
az storage account keys list \
--resource-group rg-producao \
--account-name stproddata01
The command returns an authorization error. What is the most likely cause?
A) The ReadOnly lock prevents any POST operation on the management plane, and listing keys is internally implemented as a POST action, not GET.
B) The ReadOnly lock automatically blocks access to the Storage Account data plane, including blob and metadata reading.
C) The ReadOnly lock was applied to the resource group, but doesn't propagate to child resources, so the error has another unrelated cause.
D) The ReadOnly lock only affects resources of type Microsoft.Resources, not storage services.
Question 3 — True or False
When deleting a resource group, all Microsoft Azure Policy policies assigned directly to the resource group are automatically removed, but policies inherited from the subscription scope remain active over resources recreated in the future in the same scope.
Question 4 — Technical Scenario
An organization uses the following tag structure for cost tracking:
| Resource Group | Tag applied to RG |
|---|---|
| rg-financas | centro-custo: financas |
| rg-ti | centro-custo: ti |
The administrator notices that when generating the Cost Analysis report filtered by the centro-custo tag, several resources within rg-financas don't appear in the results.
What is the most likely cause of this behavior?
A) Cost Analysis ignores tags applied to resource groups and only considers tags applied directly to individual resources.
B) Tags applied to resource groups are automatically inherited by all child resources, but Cost Analysis doesn't support filtering by inherited tags.
C) The resource exported its own cost data to an external Storage Account, disappearing from the default Cost Analysis.
D) Tags are only visible in Cost Analysis when applied at subscription scope, not on resource groups or individual resources.
Question 5 — Multiple Choice
An administrator needs to ensure that all future resources created in a specific resource group are mandatorily deployed in the brazilsouth region. They don't want to block the creation of other resource types, only restrict the location.
What is the correct approach?
A) Apply a ReadOnly lock to the resource group with a location condition defined in the lock properties.
B) Assign an Azure Policy with Deny effect using the built-in definition that restricts allowed locations, at the resource group scope.
C) Configure the resource group's location property as brazilsouth, which forces all child resources to automatically inherit this location.
D) Create a location: brazilsouth tag on the resource group and activate the tag inheritance option with enforcement in the Azure portal.
Answer Key and Explanations
Answer Key — Question 1
Answer: C
Azure allows selecting which resources will be moved in a Move operation between resource groups. The operation is not atomic for all resources in the group. The administrator can move only compatible resources, keeping incompatible ones in the source group.
The main conceptual error in incorrect alternatives is treating the move as an operation that requires 100% of resources to be compatible (A) or as something that happens automatically and silently (B). Alternative D confuses the logical location of the resource group with the physical location of resources: moving a resource between resource groups doesn't change its deployment region.
Answer Key — Question 2
Answer: A
The az storage account keys list operation is implemented by Azure Resource Manager as a POST action on the management plane, specifically Microsoft.Storage/storageAccounts/listKeys/action. A ReadOnly lock blocks all operations that aren't simple reads (GET) on the management plane, including POST actions, even if they semantically seem like a read.
Alternative B represents a common misconception: locks act on the management plane, not the data plane. They don't block access to blobs, queues, or tables directly. Alternative C is wrong because locks applied to resource groups propagate to all child resources. Alternative D is incorrect as locks apply to all resource types within scope, not just Microsoft.Resources type resources.
Answer Key — Question 3
Answer: True
When deleting a resource group, policy assignments made directly at that scope are removed along with the group. However, policies assigned at higher scopes, such as subscription or management group, continue to exist independently. If a new resource group is created in the same subscription scope, these higher-level policies will be automatically applied to it.
The non-obvious point here is the distinction between assignment scope and effect scope: deleting the resource group only removes what was assigned at that specific scope, without affecting inherited assignments.
Answer Key — Question 4
Answer: A
Tags applied to resource groups are not automatically inherited by child resources in Azure, unless an Azure Policy with Modify effect is explicitly configured to propagate the tags. Since Cost Analysis filters by individual resource tags, resources without the tag applied directly don't appear in filtered reports.
Alternative B inverts the logic correctly: automatic inheritance doesn't exist by default, and Cost Analysis itself isn't the problem. Alternatives C and D represent behaviors that don't exist in the platform. This is one of the most common operational errors in Azure cost governance strategies.
Answer Key — Question 5
Answer: B
The correct way to restrict the location of new resources in a resource group is to assign an Azure Policy with Deny effect using the built-in definition Allowed locations at the desired scope. This policy evaluates each creation request and rejects those that don't meet the location criteria.
Alternative A is wrong because locks don't have conditional location logic. Alternative C represents a frequent misconception: the resource group's location property only defines where the group's metadata is stored, it doesn't impose any restriction on child resource locations. Alternative D describes a non-existent functionality: tags don't have deployment enforcement capability.