Design governance

Ardent Global is designing its Azure foundation. A central platform team will own the hub networking, identity services, and central logging subscriptions. Two business units will deploy workloads: the EU unit must be prevented by policy from creating resources outside EU regions, while the Americas unit has no location restriction. Developers need sandbox subscriptions where most production policies do not apply. The company wants the fewest management group levels that still allow each policy to be assigned exactly once at the correct level.

Which management group hierarchy should you recommend?

1. ARoot, then one management group per Azure region containing all subscriptions deployed in that regionSubscriptions are not bound to a region, so a per-region hierarchy cannot host the EU restriction cleanly and gives no natural home for platform or sandbox policies.
2. BRoot, then an organization-wide intermediate group containing a Platform group with connectivity, identity, and management subscriptions, a Landing Zones group with child groups for EU and Americas, and a Sandbox groupThis Cloud Adoption Framework pattern gives each policy one correct scope: baseline policies on the intermediate group, platform-only policies on Platform, the allowed-locations policy on the EU child group only, and relaxed policy on Sandbox, with no duplication.
3. CRoot, then one management group per department mirroring the organization chart, with the platform subscriptions placed in the IT department groupOrganization charts change frequently and do not map to policy boundaries; the EU location policy and sandbox exemptions would still need repeated assignments across departmental groups.
4. DA single management group under root with all subscriptions, applying the EU allowed-locations policy directly on each EU subscriptionA flat hierarchy forces per-subscription assignments for the EU restriction and the sandbox relaxations, which violates the goal of assigning each policy once.

Kellerman Shipping assigns an Azure Policy initiative at its Landing Zones management group that denies storage accounts without secure transfer required. A legacy application in subscription sub-port-ops uses one storage account, stlegacyport, that must allow HTTP for 90 more days while the vendor ships a fix. The compliance team requires that the exception be documented with a reason, expire automatically, and apply only to that one storage account, without changing the initiative assignment or its effect for any other resource.

What should you recommend?

1. AAdd sub-port-ops to the excluded scopes of the initiative assignmentAn exclusion removes the whole subscription from every policy in the initiative, does not expire, and carries no documented justification.
2. BCreate a policy exemption for stlegacyport on the initiative assignment with the Waiver category, a reason, and an expiration date 90 days outExemptions are scoped to a specific resource, record a category and description, expire automatically on the set date, and leave the assignment itself unchanged for everything else.
3. CChange the initiative assignment's effect from Deny to Audit for 90 daysChanging the effect weakens enforcement for every storage account in the landing zones, not just the one with the approved exception.
4. DCreate a second initiative assignment on sub-port-ops that overrides the policy with an Allow effectAzure Policy has no Allow effect that overrides a Deny from a higher scope; multiple assignments are cumulative and the most restrictive wins.

Penhallow Media wants to make sure that no one in any of its 25 subscriptions can create a virtual machine outside an approved list of Standard_D and Standard_E sizes. The restriction must apply to every deployment method, including the portal, Bicep, and the CLI, and must stop the deployment rather than report it afterwards.

What should you recommend?

1. AA custom Azure RBAC role that omits permission to create large VM sizesRBAC permissions are per operation, not per SKU; a role cannot allow creating some VM sizes and not others.
2. BThe built-in Azure Policy definition Allowed virtual machine size SKUs assigned at the root management group with the Deny effectAzure Policy evaluates every Resource Manager request regardless of client, and the Deny effect rejects the deployment; assigning at the management group covers all 25 subscriptions at once.
3. CAzure Advisor cost recommendations reviewed weeklyAdvisor suggests right-sizing after the fact; it cannot prevent a deployment.
4. DA ReadOnly lock on each subscriptionA ReadOnly lock blocks all changes, including approved VM sizes, so it is far too broad.

Ravelstone Consulting has 1,200 guest users from client organizations in its Microsoft Entra tenant, many of whom finished their projects long ago. The company wants the owner of each Microsoft 365 group containing guests to confirm every quarter which guests still need access, and wants guests who are not approved to be removed automatically. The tenant is licensed for Microsoft Entra ID Governance.

What should you recommend?

1. AMicrosoft Entra access reviews of guest users in groups, recurring quarterly, with group owners as reviewers and auto-apply of resultsAccess reviews are built for recurring attestation: they target guest members of groups, route decisions to group owners, and can automatically remove users who are denied or not reviewed.
2. BPrivileged Identity Management eligible assignments for guest usersPIM governs just-in-time activation of roles; it is not a periodic review of group membership.
3. CA Conditional Access policy that blocks guests after 90 daysConditional Access evaluates sign-in conditions; it has no concept of project ownership and cannot ask owners to attest or remove memberships.
4. DA PowerShell script run by an administrator each quarter that emails group owners a list of guestsA script reimplements the review workflow manually and does not record decisions or automatically remove unapproved guests.