Resource groups: Refers to a collection of manageable resources sharing many attributes and managed as a unit.
Resource group rules:
1. Resource groups cannot be renamed 2. Resources can only exist in a single group
3. Resources are not confined to a single region within the group
4. Resources can be moved from one group to another at any time, but restrictions apply
5. Individual resources can be removed, or the entire resource group removed
Using Templates – ARM templates make deployments faster and more repeatable by defining all the ARM resources in deployment and providing deployment in a single operation.
Azure Storage (Overview) – Azure Storage is the Microsoft cloud approach to modern data storage scenarios supporting all different types to address the varying needs of today’s organizations.
Benefits: 1. It is highly available and scalable 2. It allows the secure transfer of data
3. It provides completely managed storage 4. It is accessible via the HTTP and HTTPS protocols
Storage uses – Azure storage is utilized in several different scenarios:
● Storage for virtual machines ● Unstructured data ● Structured data
🔹 1. Definition
A Resource Group is a logical container that holds related Azure resources such as virtual machines, storage accounts, virtual networks, databases, etc.
Each Azure resource must exist in one—and only one—resource group.
🔹 2. Purpose & Benefits
| Purpose | Details |
|---|---|
| Lifecycle Management | Resources in the same group can be deployed, updated, or deleted together. |
| Access Control | RBAC (Role-Based Access Control) can be applied at the RG level to control access to all resources within. |
| Billing & Tagging | RGs can be used to organize resources for cost tracking. Tags can add metadata. |
| Automation Scope | Azure policies, ARM/Bicep templates, and automation scripts can be scoped to RGs. |
🔹 3. Resource Group Characteristics
| Characteristic | Detail |
|---|---|
| Region of RG vs. Resources | The resource group itself is stored in a region, but the resources inside can be in any region. |
| Move Support | Many—but not all—resources can be moved between RGs or subscriptions. |
| Soft Delete | Deleting an RG deletes all resources within it. This operation is irreversible unless recovery features are used (e.g., soft-delete for key vaults). |
| Atomic Operations | Deployments to a RG are atomic using ARM templates—either all resources deploy, or none do. |
🔹 4. Deep Concepts
a. Security & RBAC
- RBAC can be assigned at the resource group level.
- Example: A user can have “Reader” access on the subscription but “Contributor” on a specific RG.
b. Azure Policy Inheritance
- Policies assigned at the RG level are inherited by resources in that RG.
- You can enforce naming conventions, SKU types, region restrictions, etc.
c. Resource Locking
- Locks can be placed at RG level (
CanNotDeleteorReadOnly) to prevent accidental modification or deletion.
d. Resource Dependencies
- Azure templates (ARM or Bicep) support
dependsOnto manage deployment order within a RG.
🔹 5. Resource Group Scoping in Azure Services
| Service | Behavior |
|---|---|
| Azure Monitor / Log Analytics | Log collection and monitoring settings can be scoped to a RG. |
| Azure DevOps Pipelines | ARM deployments can be scoped to specific RGs for deployment. |
| Azure Cost Management | Costs can be broken down by RG for showback/chargeback models. |
🔹 6. Best Practices
| Area | Best Practice |
|---|---|
| Naming Convention | Follow a consistent naming pattern: rg-<project>-<env>-<region> |
| Least Privilege | Assign roles at RG level to isolate access (e.g., dev/test/prod) |
| Resource Isolation | Separate RGs for staging, production, and development. |
| Tagging | Use tags like CostCenter, Owner, Environment, Application |
| Policy Enforcement | Apply Azure Policies at RG level to enforce compliance. |
| Lock Critical RGs | Protect production RGs with CanNotDelete lock. |
🔹 7. Advanced Scenarios
a. Multi-Region DR Setup
- Primary and secondary regions can each have their own RG.
- Resource Manager supports cross-RG dependencies.
b. Subscription Governance
- RGs can be grouped into management groups for organization-wide governance.
- Useful in multi-subscription environments.
c. Service Principals & Automation
- Automate RG-level resource deployment using:
- Azure CLI (
az group) - ARM/Bicep templates
- Terraform or Pulumi
- Azure CLI (
d. Resource Graph Queries
- Azure Resource Graph allows querying resources across RGs:
kust Resources
| where resourceGroup == "rg-prod-eastus"
| project name, type, location, tags
🔹 8. Limitations
- Max 800 deployments per RG (history cap), though this can be cleaned up.
- Resources cannot span RGs; a VM and its NIC or disk must be in the same subscription, but not necessarily same RG.
- Some classic (ASM) resources don’t support RGs (legacy).