Skip to main content

Troubleshooting Lab: Configure management groups

Diagnostic Scenarios​

Scenario 1 — Root Cause​

A platform administrator reports that they just applied an Azure Policy with Deny effect to block resource creation outside the Brazil South region. The policy was assigned to the MG-Corporativo management group, which contains three child groups: MG-App, MG-Dados, and MG-Segurança.

Two days after the implementation, the data team opens a ticket reporting that they successfully created a Storage Account in the East US 2 region within a subscription belonging to MG-Dados. The administrator checks the portal and confirms that the policy appears as active and correctly assigned to the MG-Corporativo group.

Information collected during the investigation:

Policy assignment scope : /providers/Microsoft.Management/managementGroups/MG-Corporativo
Policy effect          : Deny
Compliance state       : Not started
Last evaluated         : Never
Assignment date        : 2024-11-01T09:00:00Z
Current date/time      : 2024-11-01T09:47:00Z

The administrator also verifies that the MG-Dados group has no scope exclusions configured and that the subscription is correctly listed as a member of MG-Dados.

What is the root cause of the observed behavior?

A) The subscription within MG-Dados has an Audit effect policy that is overriding the Deny inherited from the parent group.

B) The policy has not yet been evaluated by the Azure compliance cycle, which can take up to 30 minutes after assignment to process existing resources and new creations.

C) The assignment scope is incorrect; policies assigned to management groups do not automatically propagate to child groups without additional configuration.

D) The Storage Account creation occurred during an Azure Policy maintenance window, during which compliance evaluations are temporarily suspended.

Scenario 2 — Action Decision​

The governance team identified the cause of a recurring problem: new project subscriptions are being created directly under the Tenant Root Group instead of being moved to the MG-Projetos management group immediately after provisioning. This happens because subscription creators have the Owner role on the newly created subscription, but don't have permission to move subscriptions to management groups.

The environment has the following constraints:

  • The company has an internal policy that prohibits granting roles with Tenant Root Group scope to users who are not part of the central platform team.
  • There is a project onboarding process that is already executed by a dedicated service principal, called sp-onboarding, used for post-provisioning automations.
  • The platform team consists of only two people and cannot manually review each new project.
  • The solution must work without manual intervention starting next week.

What is the correct action to take at this time?

A) Grant the Management Group Contributor role on the Tenant Root Group to all subscription Owners, so they can move their own subscriptions autonomously.

B) Assign the Management Group Contributor role on the MG-Projetos group to sp-onboarding and add the subscription movement step to the existing automated onboarding process.

C) Create an Azure Monitor alert to notify the platform team whenever a new subscription appears directly under the Tenant Root Group, so the movement can be done manually.

D) Assign the Owner role on the MG-Projetos group to sp-onboarding, ensuring it has complete permission to manage all resources within the target group.

Scenario 3 — Root Cause​

An administrator receives the following error when trying to move the MG-Regional management group into the MG-Global group via Azure portal:

Error: MoveManagementGroupFailed
Message: The management group 'MG-Global' cannot be a descendant of 'MG-Regional'.
Code: ParentChangeNotAllowed

The environment has the following hierarchical structure at the time of the attempt:

Tenant Root Group
└── MG-Regional
    ├── MG-Global          <-- group that will be the new parent
    │   └── MG-EMEA
    └── MG-Americas

The administrator reports having the Management Group Contributor role on both groups and has verified that no management locks are active. They also mention trying the operation outside business hours to avoid impact, and that the MG-EMEA group is currently empty.

What is the root cause of the error?

A) The Management Group Contributor role is not sufficient for management group movement operations; the operation requires the Owner role on the Tenant Root Group.

B) Management groups with active child groups cannot be moved; the MG-Global group needs to be empty before the movement.

C) The operation would create a cycle in the hierarchy, since MG-Global is currently a descendant of MG-Regional, making MG-Regional a descendant of its own child.

D) The operation timing coincided with an Azure hierarchy synchronization process, which temporarily blocks group movements.

Scenario 4 — Diagnostic Sequence​

An administrator receives the following report: "I applied a change to the management group hierarchy yesterday and now some teams can no longer access resources they normally accessed."

The administrator needs to investigate the cause. The following investigation steps are available, but in incorrect order:

  1. Check the Azure activity log to identify which changes were made to the hierarchy in the last 24 hours.
  2. Confirm if role assignments inherited from the previous management group are still active in the new scope.
  3. Identify which management group the affected subscriptions were in before and where they are now.
  4. Verify if the affected teams can authenticate to Microsoft Entra ID without errors.
  5. Compare the effective role assignments of affected users before and after the hierarchical change.

What is the correct investigation sequence?

A) 4 → 1 → 3 → 2 → 5

B) 1 → 3 → 2 → 5 → 4

C) 1 → 4 → 3 → 5 → 2

D) 3 → 1 → 4 → 2 → 5

Answer Key and Explanations​

Answer Key — Scenario 1​

Answer: B

Explanation:

  • The definitive clue is in the collected output: Last evaluated: Never and Compliance state: Not started. These fields indicate that the Azure Policy evaluation cycle has not yet processed the assignment. Azure Policy is not instantaneous: after a new assignment, the evaluation engine can take between 5 and 30 minutes to process the complete scope.
  • The time elapsed between the assignment (09:00) and the investigation (09:47) is less than an hour, and the output confirms that no evaluation has occurred yet. The resource was created within this window.
  • The information about MG-Dados having no scope exclusions and the subscription being correctly listed are relevant data that eliminate scope configuration problems, directing the diagnosis toward evaluation latency.
  • Alternative A represents a classic conceptual error: an Audit effect policy does not block or replace an inherited Deny. Both coexist.
  • Alternative C is false: propagation to child groups is automatic and requires no additional configuration.
  • Alternative D describes behavior that doesn't exist in the platform: Azure Policy does not have maintenance windows that suspend evaluations.
  • The most dangerous distractor is C, because it would lead the administrator to unnecessarily alter the policy scope, potentially breaking the correct configuration that was already in place.

Answer Key — Scenario 2​

Answer: B

Explanation:

  • The central constraint of the scenario is that the solution must be automated, work without manual intervention, and not violate the internal policy that prohibits roles with Tenant Root Group scope for users outside the platform team.
  • The sp-onboarding already exists, is already trusted, and already executes post-provisioning automations. Granting it the Management Group Contributor role specifically on the MG-Projetos group meets all three constraints simultaneously: it's automated, doesn't grant access to the Tenant Root Group, and doesn't depend on manual review.
  • Alternative A directly violates the company's internal policy by granting access with Tenant Root Group scope to users who are not part of the platform team.
  • Alternative C partially meets requirements (creates visibility), but maintains dependency on manual action from the platform team, contradicting the scale requirement and deadline.
  • Alternative D grants the Owner role to sp-onboarding on the MG-Projetos group, which is excessive: subscription movement requires only Management Group Contributor on the destination, not Owner. Following the principle of least privilege is part of the correct decision here.

Answer Key — Scenario 3​

Answer: C

Explanation:

  • The error message The management group 'MG-Global' cannot be a descendant of 'MG-Regional' and the code ParentChangeNotAllowed precisely describe a hierarchical cycle problem. The current structure shows that MG-Global is already a child of MG-Regional. Making MG-Regional a child of MG-Global would create a circular reference, which is structurally impossible in a tree hierarchy.
  • The information about the operation timing and the MG-EMEA group being empty are irrelevant data introduced intentionally. They have no relation to the error and serve to divert diagnosis toward availability or child state causes.
  • Alternative A is plausible as a permission mistake, but the error is not authorization-related (AuthorizationFailed); it's structural logic (ParentChangeNotAllowed). Permissions are not the problem here.
  • Alternative B confuses the concept of empty group with movement prerequisite. Management groups can be moved with children; the impediment is topological, not about the state of children.
  • The most dangerous distractor is A, as it would lead the administrator to unnecessarily escalate permissions, wasting time and potentially creating security risks, while the real problem remains unsolved.

Answer Key — Scenario 4​

Answer: B

Explanation:

  • The correct sequence follows the logic of progressive diagnosis from broadest to most specific, without deviating to unnecessary hypotheses before confirming the change that caused the problem.
  • Step 1 (activity log): confirming what was changed is always the starting point when there's a declared recent event. Without knowing exactly what changed, any subsequent investigation is speculation.
  • Step 3 (subscription location): after confirming the change, identifying which subscriptions were moved and where connects the alteration to the reported impact.
  • Step 2 (inherited role assignments): with movement confirmed and subscriptions identified, checking if role assignments from the previous group are still effective in the new scope is the most likely hypothesis for access loss.
  • Step 5 (effective permissions comparison): after raising the inheritance loss hypothesis, comparing effective permissions before and after confirms or refutes the hypothesis with concrete evidence.
  • Step 4 (Entra ID authentication): checking authentication is a valid step in general access troubleshooting, but in this context, with a hierarchical change declared as a recent event, authentication is the least likely hypothesis and should be investigated last, only if previous steps don't explain the failure.
  • Sequence A (starting with step 4) represents the error of investigating the identity layer before investigating the authorization and structure layer, which is where the change occurred.

Troubleshooting Tree: Configure management groups​

100%
Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Legend:

ColorMeaning
Dark blueInitial symptom (entry point)
BlueDiagnostic question (decision node)
RedIdentified cause
OrangeIntermediate validation or verification

To use this tree when facing a real problem, start at the root node and answer each decision question based on what you directly observe in the environment, without assuming the cause. Follow the path indicated by your answer until you reach a red identified cause node. If you reach an orange validation node, execute the suggested verification before continuing. When you identify the cause, use the node description as a starting point for corrective action.