4.2 Resource Group Organization & Tagging Strategy Design
Key Takeaways
- Every Azure resource belongs to exactly one resource group, and resource groups cannot be nested or span subscriptions — group resources that share a deployment lifecycle, typically by application/workload rather than by resource type
- A resource, resource group, or subscription can carry a maximum of 50 tag name/value pairs (15 for Azure API Management and Azure Automation); tag names are limited to 512 characters and values to 256 characters
- Tags are not applied automatically — Azure Policy's Append effect adds a tag only at creation time, while the Modify effect is the only effect that can also add or fix tags on resources that already exist, via a remediation task
- Design tags as cross-cutting metadata (cost center, environment, owner, data classification) that lets you report and query resources across resource-group and subscription boundaries
- A common enterprise pattern is a mandatory tag policy (Deny on missing required tags) paired with a Modify-effect remediation policy that backfills tags on resources deployed before the policy existed
Why This Topic Matters
The second half of the "management groups, subscriptions, and resource groups, and a strategy for resource tagging" bullet asks you to design at the layer architects touch most often day-to-day: resource groups (the deployment/lifecycle container) and tags (the cross-cutting metadata layer). Exam scenarios in this area typically describe an organization that needs consistent tagging enforced at scale, or that needs resources grouped so an entire application can be deployed, updated, or torn down as a unit. Because tagging questions frequently combine with Azure Policy (covered fully in 4.3), you need to know exactly which policy effect can and cannot retrofit tags onto resources that already exist — this is one of the most reliably tested details in Domain 1.
Resource Groups: The Lifecycle Container
A resource group (RG) is a logical container that holds resources sharing a common lifecycle. Key rules:
- Every resource belongs to exactly one resource group.
- A resource group belongs to exactly one subscription — it cannot span subscriptions.
- Resource groups cannot be nested inside other resource groups.
- The resource group itself has a region (where its metadata is stored), but the resources inside it can each live in a different Azure region.
- Deleting a resource group deletes every resource inside it — a resource group is therefore also a deletion boundary, not just an organizational convenience.
Organization Patterns
| Pattern | Description | Exam guidance |
|---|---|---|
| By application/workload (recommended default) | All resources for one app's environment (e.g., rg-orders-prod) share one resource group | Enables a single RBAC scope for the app team and a clean "delete the whole environment" operation |
| By environment nested under workload | rg-orders-dev, rg-orders-test, rg-orders-prod | Standard combination pattern; isolates blast radius per environment while keeping app resources together |
| By resource type (anti-pattern for most designs) | All VMs in one RG, all storage accounts in another, regardless of application | Breaks the lifecycle principle — deleting or redeploying one app now requires touching multiple unrelated resource groups; avoid recommending this unless the requirement specifically calls for a shared-services pattern (e.g., a dedicated networking resource group in the Platform/Connectivity subscription) |
Tags: Cross-Cutting Metadata
While resource groups organize by lifecycle, tags are name/value pairs that let you organize and report across resource-group and subscription boundaries — for example, finding every resource tagged CostCenter: 4021 regardless of which app or environment it belongs to.
| Tag limit | Value |
|---|---|
| Tag name/value pairs per resource, resource group, or subscription | 50 (exceptions: Azure API Management and Azure Automation allow 15) |
| Tag name character limit | 512 characters (128 for storage accounts) |
| Tag value character limit | 256 characters |
Tags are commonly used for: CostCenter, Environment, Owner, Application, and DataClassification. None of these are applied automatically just because a resource sits inside a tagged resource group — tag inheritance is not automatic and must be engineered.
Enforcing and Backfilling Tags with Azure Policy
This is the detail the exam tests most precisely. Azure Policy has two effects relevant to tags, and they solve different problems:
| Effect | What it does | Can it fix existing resources? |
|---|---|---|
| Append | Adds a specified tag (or other property) during resource creation or update if it is missing; the caller cannot remove or override the appended value | No — only affects resources at creation/update time going forward |
| Modify | Adds, updates, or removes tags at creation/update time and can run a remediation task against resources that already exist | Yes — Modify is the only tag-related effect that can retroactively fix already-deployed resources |
| Deny (paired with a tag-existence condition) | Blocks deployment entirely if a required tag is missing | No — prevents new non-compliant resources but does nothing to resources deployed before the policy existed |
Exam Scenario
A company requires every resource group to carry Department and CostCenter tags, and resources missing these tags must be prevented from deployment. The architect should assign a Deny-effect policy (or a built-in initiative such as "Require a tag on resources") scoped to the management group covering all subscriptions. Separately, if the company also wants existing, already-deployed resource groups fixed automatically, that requires a Modify-effect policy with a remediation task — Deny alone cannot touch resources that already exist, and Append alone cannot fix resources that were created before the policy was assigned.
Takeaways for the Exam
- Match the requirement wording precisely: "prevent deployment" → Deny; "add tags automatically as resources are created" → Append; "fix tags on resources that already exist" → Modify with remediation.
- Group resources by lifecycle (resource group), not by type, unless a shared-services exception applies.
- Remember the concrete 50-tag limit and the two API/Automation exceptions at 15 tags — these numbers show up directly in exam options designed to look plausible but wrong (for example, an option stating "100 tags per resource").
An organization wants Azure Policy to automatically add a CostCenter tag to every resource deployed going forward, but resources are allowed to be deployed even if the tag is initially missing (the policy just adds a default value). Which Azure Policy effect fits this requirement?
A company has 3,000 resources deployed before any tagging policy existed. Compliance now requires every one of those existing resources to receive an Environment tag without redeploying them manually. Which approach satisfies this requirement?