Which of the following allows you to easily manage access policies and compliance across multiple subscriptions?

Azure management group structure

Azure management groups belong in an Azure administrator's toolkit, particularly at organizations that pay for many subscriptions under a Microsoft EA. The hierarchical structure in Azure management groups proves unnecessary for small teams or independent users, such as developers.

The groups work similarly to Active Directory (AD) security groups for Windows Server but tailored for public cloud. The cloud administrator bundles logically related Azure subscriptions into a single management unit, with policies that apply to every group member. As with AD groups, Azure management groups have policies that persist from parent to subgroups and subscriptions automatically. For example, a global Azure administrator can define a policy that limits the type of VM instances available and further define that instances can only be created in two Azure regions. This policy automatically applies to every management group, subscription and resource hierarchically under the global admin's group.

At the top of the hierarchy is a root management group that sets policies for the entire organization. The AD administrator or a similar IT professional should manage the root group; no one has default access to it. After the first Azure management group is created, the chosen root manager can elevate himself to the role. Once they have access, administrators can assign management permissions to others. New subscriptions are automatically members of the root management group but must be assigned to other groups.

Azure management groups also support the service's role-based access control (RBAC), a set of access and security policies for Azure resources that follow hierarchical rules of group precedence. Any RBAC role assigned to a parent group automatically applies to subgroups below it. RBAC permissions use the security principle of least privilege, meaning that a rule must explicitly allow a user to perform an action.

Seven predefined roles are available to Azure management groups. Custom RBAC roles are not supported. This feature is the highest priority among members of the Azure Management Groups support forum, so expect to see custom RBAC definitions added in a future update.

Also, consider using Azure management groups to apply the Azure Policy service, enforcing rules onto multiple accounts in the same automatically persisting hierarchical manner as explained with RBAC.

Usage and limitations

To create an Azure management group, navigate through the Azure Resource Manager portal, under the All services sidebar menu (see below). Input a unique group ID, an optional descriptive display name and the parent group (if any) under which the new group should reside. Alternatively, use Microsoft PowerShell to create a group with the Add-AzureRmManagementGroups cmdlet or the Azure command-line interface using the az account management-group create command.

Management groups are subject to some limits:

• There can be no more than 10,000 management groups in a single directory.
• Group hierarchy can be no more than six levels deep, not counting the root level.
• Each group and subscription can only have one parent, but can have multiple children.
• All subscriptions and management groups exist within a single hierarchy in each directory.
• The name and ID of the root management group are fixed by default, although admins can change the display name.
• The user cannot move or delete the root group.

To take advantage of the benefits of Azure management groups, plan each group structure, and study how to use RBAC definitions to manage access policies for cloud resources. If the Azure deployment is complicated, pull in the Azure Policy service alongside management groups to refine resource usage and security controls.