You're a great admin... on-prem. Now, become a great admin in the cloud and prove it by passing the Microsoft Certified: Azure Administrator Associate exam!
Gauge your current knowledge
Gauge your current knowledge
An Azure Resource Group serves as a logical container designed to house resources sharing the same lifecycle. Although resources inside a group can span multiple physical regions, the resource group itself stores its deployment metadata in a single specified location. This structural design makes the choice of a resource group's region a critical decision point for organizations managing strict data residency compliance. To help organize these assets, administrators apply Tags, which are name-value pairs used for categorization and billing, though these tags are not automatically inherited by the resources inside the group.
To protect critical infrastructure from administrative errors, you can implement Resource Locks directly at the resource group scope. These locks are automatically inherited by all child resources and specifically target the Control Plane, meaning they do not restrict data-plane operations such as uploading files to a storage account. You must choose between two distinct lock types based on the level of protection required:
Authorization is managed by Azure Role-Based Access Control (RBAC), which assigns permissions to a Security Principal. When an administrator assigns a Role Definition at the resource group scope, those permissions automatically cascade down to all resources inside the group. This inheritance model simplifies permission management and ensures that the system enforces the principle of least privilege uniformly across all child components.
To enforce compliance at the resource level, organizations use Azure Policy to evaluate resource properties against defined business rules written in JSON format. Unlike RBAC, which controls user identities and permissions, Azure Policy governs the configuration state of the resources themselves, regardless of who created them. When a policy evaluates a resource, it applies one of several enforcement actions:
The lifecycle of a resource group often ends with its Deletion Process, which is a highly destructive and irreversible operation. Azure Resource Manager coordinates this deletion by first removing any child resources in a specific order before removing the group container. If any active resource locks are present, they will block this deletion, requiring administrators to manually delete the locks before the resource group can be removed.
Creating and configuring resource groups is the first step in setting up an Azure environment, as every resource must reside within one. Administrators can provision resource groups using multiple administrative interfaces, including the Azure Portal, PowerShell, Python SDK, and the Azure CLI. For example, the az group create command allows users to quickly provision a group by specifying a name and location. Administrators can also audit their environment by using az group list to view all active groups or az group show to inspect a specific group's properties.
Once a group is established, you can deploy resources directly into it using the Azure CLI or orchestration templates. For instance, creating an Azure Storage Account requires targeting a specific resource group and defining configuration options such as the location, performance tier, and replication SKU. For automated and repeatable deployments, administrators can run the az deployment group create command to deploy resources defined in ARM templates or Bicep files. This approach ensures that complex environments are configured consistently and align with organizational standards.
Administrators can also apply security locks and retrieve structural configurations directly through the command line to protect and copy resources. To prevent unauthorized modifications, the az lock create command applies a lock to the entire resource group, while other CLI commands allow administrators to list and delete these locks. If an organization needs to replicate an existing environment, they can export the configuration of an active resource group into an ARM template. This exported template serves as a structural blueprint that simplifies the creation of identical resources in other regions or subscriptions.
Effective management of resource groups involves maintaining control over their active lifecycles and organization. Because each resource can only exist in one resource group, grouping decisions should align closely with the operational lifespan of the resources. When a solution is no longer needed, deleting the resource group cleans up all nested resources simultaneously. This cleanup process relies on Azure Resource Manager, which systematically checks for resource dependencies and retries any failed deletions to ensure no orphaned resources are left behind.
As business requirements change, you may need to reorganize infrastructure by moving resources between resource groups or subscriptions. This operation can be initiated using the Azure Portal, CLI, PowerShell, or the Resource Manager API, but success depends on several constraints. Not all resource types support moves, and some resources have strict dependencies that must be moved together to prevent breaking active connections. Before initiating a move, administrators must verify compatibility and plan for potential service interruptions during the transition.
Resource Tagging provides a lightweight way to organize resources logically across different groups for cost management, compliance, and auditing. These key-value pairs allow billing systems to aggregate costs by department, environment, or project, even if those resources reside in different groups. Administrators must follow strict naming and tagging conventions to maintain consistency and prevent the exposure of sensitive data in tag names or values. Together with Azure RBAC and resource locks, these tagging structures ensure that the entire lifecycle of an Azure environment remains secure, organized, and visible.
StudyCerts
StudyCerts