Start here! Get your feet wet with the Microsoft cloud and begin your journey to earning your Microsoft Certified: Azure Fundamentals certification!
Gauge your current knowledge
Gauge your current knowledge
Azure resources are individual services that you create and manage in the cloud to build and run your applications. Common examples include virtual machines for compute workloads, storage accounts for reliable data storage, and managed databases like Azure SQL Database. Connecting these services together requires networking components, such as virtual networks, network interfaces, and security groups that control traffic.
Every service is deployed and maintained through Azure Resource Manager, which acts as a consistent management layer. Resources are uniquely identified across the entire cloud platform by a resource ID, which is a hierarchical text path detailing the subscription, resource group, and specific resource provider. This resource provider acts as the underlying API that defines the structure and rules for each resource type.
To manage access and security, Azure organizes resources into a clear hierarchy. This structure starts at management groups, flows down to subscriptions, goes into resource groups, and finally reaches individual resources. When you assign roles using role-based access control (RBAC), permissions inherit down this hierarchy, allowing you to limit risk by granting users only the minimum access they need.
A resource group is a fundamental container in Azure designed to hold related resources for a specific cloud solution. You decide which resources to include based on what makes sense for your organization, such as grouping assets by their purpose or their lifecycle. This logical organization simplifies cloud governance by allowing you to manage, monitor, and secure connected services as a single unit.
Every resource group stores metadata about the items it contains to keep track of their configuration and status. When you create a group, you must select a location, which determines where this management metadata is physically stored. Control plane operations, such as creating or updating a resource, are routed through this location to keep the group in a consistent state.
Managing your resources collectively through a single group provides several distinct operational advantages. Instead of configuring each service one by one, you can deploy and update them simultaneously using target templates. This unified control plane also allows you to view costs collectively, enforce consistent tagging standards, and delete all resources in the group at the same time.
Administrators can create and manage resource groups using several different tools depending on their workflow preferences. For a visual experience, you can use the Azure portal to click through configuration screens. If you prefer scripting and automation, you can use the Azure CLI with commands like az group create or Azure PowerShell with New-AzResourceGroup. Programmatic deployments are also supported through the Python SDK or declarative Bicep templates.
Beyond creation, daily management involves listing your groups, retrieving their details, or deleting them when they are no longer needed. Command-line tools let you list groups using az group list or Get-AzResourceGroup, while SDKs use client methods to retrieve group data. It is important to remember that deleting a resource group will permanently remove all resources inside it, making cleanup quick but requiring caution.
To run your cloud environment efficiently, you should adopt industry best practices for organizing resource groups. Grouping resources that share the same lifecycle ensures you can deploy and decommission entire environments together without leaving orphaned services behind. Additionally, aligning your resource group region with your user base helps with data residency compliance and minimizes latency.
Securing your cloud infrastructure requires applying permissions and policies at the resource group level to enforce organizational standards. Using role-based access control, administrators can assign specific roles to users, groups, or applications to define what actions they can perform. Applying these permissions at the resource group scope ensures that all child resources within that group automatically inherit the same security settings.
When you configure a role assignment at this level, you must specify the target scope using a formatted resource ID path. This string explicitly connects the role to the specific subscription and resource group name. Following the principle of least privilege ensures that users only receive the specific access level they need to perform their daily tasks.
To supplement access controls, Azure Policy helps enforce business rules and configuration standards across your resource groups. You can use policy definitions to automatically deny the creation of unauthorized resource types or audit existing resources for missing tags. This automated governance blocks non-compliant deployments and ensures your cloud resources continuously align with company guidelines.
Automating your cloud deployments helps reduce errors and ensures that environments are set up consistently every time. You can use ARM templates, which are JSON files that define the exact infrastructure you want to deploy as code. This approach allows you to store your infrastructure configurations in source control and deploy them automatically using CI/CD pipelines in Azure DevOps Services.
For simpler, recurring administrative tasks, you can set up automated workflows directly within your resource group. These lightweight automation tasks use Azure Logic Apps behind the scenes to perform actions on a schedule or trigger. Common examples include starting or stopping virtual machines to save money, sending monthly cost reports, or deleting old storage files. These tasks differ from Azure Automation by running on a multi-tenant consumption plan for basic operations.
Implementing these automation tools supports a mature DevOps culture across development, test, and production environments. Utilizing staging strategies like blue-green deployments or canary releases allows you to validate changes safely before they go live. If a deployment fails, you can use rollback flags in the CLI to instantly return your resource group to its previous stable state.