Troubleshooting Lab: Manage Subscriptions
Diagnostic Scenarios
Scenario 1 — Root Cause
A company's security team reports that resources are being created in the westeurope region within the production subscription, violating an internal policy that requires exclusive use of the brazilsouth and eastus regions. The administrator verifies that there is an Azure Policy with deny effect assigned to the parent management group of the subscription, covering exactly the two allowed regions. The policy is in Enabled status and the enforcementMode field is configured as Default.
The administrator also observes the following when listing the policy assignments on the subscription directly:
az policy assignment list --scope /subscriptions/<subscription-id> --output table
Name DisplayName EnforcementMode
-------------------------- --------------------------- ---------------
AllowedLocations-Override Allowed Locations Override DoNotEnforce
The subscription is 45 days old. The staging environment, which uses the same management group hierarchy, does not have this problem. The network team confirms that the VNets created in westeurope have no peering configured.
What is the root cause of the problem?
A) The deny effect in the management group does not propagate to subscriptions created less than 60 days ago
B) The policy assignment on the subscription with EnforcementMode: DoNotEnforce is overriding the effect of the policy inherited from the management group
C) The Enabled status of the policy in the management group indicates it is in audit mode, not effective blocking
D) The absence of peering in VNets created in westeurope indicates that the location policy does not cover network resources
Scenario 2 — Action Decision
The cause has already been identified: a production subscription was accidentally transferred to an incorrect management group called MG-Sandbox, which has a deny policy blocking the creation of Microsoft.Compute/virtualMachines resources. The operations team needs to deploy a critical update involving the creation of new VMs in less than two hours. Moving the subscription to the correct management group (MG-Production) would take at most 5 minutes and does not cause downtime for existing resources.
However, the available administrator has the Reader role on the subscription and Contributor on the target resource group. He does not have permissions on management groups.
A second administrator with Management Group Contributor permissions is available but is in a different time zone and will only respond in approximately 3 hours.
What is the correct action to take at this time?
A) The available administrator should move the subscription to MG-Production using the Azure portal, as the Contributor role on the resource group is sufficient for management group operations
B) Create a policy assignment exemption on the subscription for the Microsoft.Compute/virtualMachines type using the Contributor permissions on the resource group
C) Escalate to the second administrator and wait, as none of the available actions can be executed with current permissions without risk of greater impact
D) Create the VMs directly via Azure CLI authenticated with the available administrator's credentials, as the data plane is not affected by management group policies
Scenario 3 — Root Cause
A developer opens a ticket reporting that they cannot view any resources in a subscription they were recently added to. When accessing the Azure portal, they see the subscription listed in the directory selector, but when clicking on it, the resource list appears completely empty. The developer confirms they can access other subscriptions normally.
The administrator verifies the following:
az role assignment list --assignee <developer-object-id> \
--scope /subscriptions/<subscription-id> --output table
PrincipalName RoleDefinitionName Scope
--------------- -------------------- ------------------------------------------
dev-user Reader /subscriptions/<id>/resourceGroups/rg-app01
The administrator also confirms that the subscription is active, that there are no locks applied, and that the Microsoft Entra ID tenant associated with the subscription is the same tenant as the user. The subscription has 12 resource groups in total, all with deployed resources. The network team reports that the subscription's VNets have custom DNS configured.
What is the root cause of the problem?
A) The subscription is associated with a different tenant than the user's tenant, preventing resource visualization
B) Locks applied on the subscription are blocking read operations for users without the Owner role
C) The developer has the Reader role with scope restricted to a single resource group, without read permission at the subscription level
D) The custom DNS configuration in the VNets is preventing name resolution necessary to list resources in the portal
Scenario 4 — Collateral Impact
An administrator identifies that a production subscription was associated with the wrong Microsoft Entra ID tenant during a corporate reorganization process. To fix the problem, he executes the transfer of the subscription to the correct tenant. The operation is completed successfully and resources remain available.
Two days later, several teams report that CI/CD pipelines are failing with authentication errors, and that production applications consuming internal APIs started returning 401 Unauthorized errors.
The transfer was the correct action and solved the tenant association problem. The question is: what collateral consequence of this action caused the reported failures?
A) Tenant transfer changes the Azure Resource Manager endpoint, requiring all clients to update the base URL for API calls
B) Managed identities assigned to resources were invalidated with the transfer, and service principals associated with pipelines and applications ceased to exist in the source tenant
C) Microsoft Entra ID group role assignments were preserved, but groups need to be recreated in the new tenant to reactivate permissions
D) Azure Policies inherited from the management group were disassociated during transfer, exposing resources to creations outside governance standards
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The decisive clue is in the output of the az policy assignment list command executed directly on the subscription scope. It reveals a local policy assignment called AllowedLocations-Override with EnforcementMode: DoNotEnforce. This mode disables the application of the policy effect (the deny is not executed), but maintains compliance evaluation. When there is a policy assignment in the subscription scope with this mode, it doesn't override the management group one in the sense of removing the inherited effect, but the presence of DoNotEnforce in a local assignment indicates that someone created a specific assignment to suspend effective application in that scope.
The information about the absence of peering in VNets is the irrelevant information purposefully included. Peering has no relation whatsoever to Azure Policy evaluation for resource location.
Alternative A is wrong: there is no 60-day grace period rule for policy propagation. Alternative C represents a common misconception: the status: Enabled field of a policy definition is different from EnforcementMode; one does not control the other. Alternative D is a distractor that tries to divert focus to an infrastructure detail completely irrelevant to policy behavior.
The most dangerous mistake would be choosing C and investigating the policy definition status in the management group, losing time while the local assignment with DoNotEnforce continues allowing creations outside the permitted regions.
Answer Key — Scenario 2
Answer: C
The critical restriction of the scenario is permission: moving a subscription between management groups requires the Owner or Management Group Contributor role on the destination management group, and at minimum Owner or Contributor on the subscription. The available administrator has only Reader on the subscription and Contributor on a resource group, which is insufficient for any operations on the management groups hierarchy.
Alternative A is wrong because Contributor on resource group does not grant permission for operations on the management groups management plane. Alternative B is technically valid in another context, but creating a policy exemption requires permission at the subscription scope, not just on a resource group. Alternative D represents a serious conceptual mistake: Azure Policy acts on the control plane (ARM), not the data plane, but VM creation is a control plane operation that will be blocked by the policy regardless of the tool used.
The correct action is to escalate and wait, documenting the impediment. Acting outside the scope of available permissions would cause errors or, worse, incorrect modifications to the governance hierarchy.
Answer Key — Scenario 3
Answer: C
The output of the az role assignment list command is the definitive clue. It shows that the developer has the Reader role with scope on /subscriptions/<id>/resourceGroups/rg-app01, that is, on only one of the 12 resource groups. In the Azure portal, when a user accesses a subscription without role assignment at the subscription level, the portal lists the subscription but displays resources only from the scopes where the user has permission. If the subscription has 12 resource groups and the user only has access to one, the portal may present the list as apparently empty depending on the selected view.
Alternative A is eliminated by the statement itself, which confirms the tenant is the same. Alternative B is eliminated because the statement confirms the absence of locks. Alternative D is the irrelevant information of the scenario: custom DNS in VNets has no relation whatsoever to RBAC permissions or resource listing in the portal.
The most dangerous distractor is A, as it leads the administrator to investigate tenant and identity problems unnecessarily, when the problem is RBAC scope visible in the first command output.
Answer Key — Scenario 4
Answer: B
When a subscription is transferred between Microsoft Entra ID tenants, managed identities (both system-assigned and user-assigned) are destroyed, as they are objects of the source tenant. Service principals of applications registered in the source tenant also cease to be valid in the context of the subscription in the new tenant. CI/CD pipelines that use service principals for Azure authentication and applications that use managed identities to access other services immediately lose the ability to authenticate, resulting in the reported 401 Unauthorized errors.
Alternative A is wrong: the Azure Resource Manager endpoint (management.azure.com) is global and does not change with tenant transfer. Alternative C inverts reality: group role assignments are removed in the transfer, not preserved, and groups cannot simply be "reactivated" in the new tenant without complete recreation of assignments. Alternative D is partially true (policies need to be reassigned), but does not explain the 401 authentication errors in pipelines and applications, which are caused by identity failure, not governance.
Troubleshooting Tree: Manage Subscriptions
Color legend:
| Color | Node type |
|---|---|
| Dark blue | Initial symptom (entry point) |
| Blue | Diagnostic question |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Intermediate verification or validation |
When facing a real problem, start at the root node identifying whether the symptom involves a blocked operation or a resource visibility problem. Follow the closed questions answering based on what you can directly observe, through commands like az policy assignment list and az role assignment list. Orange nodes indicate points where you need to gather information before proceeding. Never jump to a cause without going through intermediate verifications, especially in scenarios where the most obvious cause usually masks the real cause.