Part 3: Naming, Tagging & Inheritance

Source: John Savill's Azure Master Class v3 - Part 3: Governance
Video Timestamps: 32:15 - 45:00
AZ-104 Relevance: ⭐⭐⭐⭐ Tags and inheritance are tested; naming is best practice knowledge

---

Naming Standards

Why It Matters

Looking at a resource, you should immediately know:

• What type it is
• Which workload/app it belongs to
• Which environment (dev/prod)
• Which region
• Instance number (if multiple)

Cloud Adoption Framework Recommendation

{resource-type}-{workload}-{environment}-{region}-{instance}

Examples:

Resource	Name
Storage Account	staboraboraprodeus001
VM	vm-webapp-prod-westeu-001
Resource Group	rg-payments-dev-eastus
VNet	vnet-hub-prod-westeu

Key Points

• Be consistent across cloud AND on-premises
• Define abbreviations upfront (st, vm, rg, vnet, nsg, etc.)
• Document your convention - make it discoverable
• Some resources have naming restrictions (storage = lowercase, no hyphens)

📎 Azure naming conventions

---

Tags

What They Are

Key-value pairs attached to resources for metadata, filtering, and billing.

Where Tags Apply

Scope	Tags Supported?
Management Groups	❌ No
Subscriptions	✅ Yes
Resource Groups	✅ Yes
Resources	✅ Yes

Tag Limits

Limit	Value
Tags per resource	50 (some resources: 15)
Tag name length	512 characters
Tag value length	256 characters

Recommended Minimum Tags

Tag	Purpose
Environment	prod, dev, test, staging
Owner	Email of responsible person
CostCenter	For billing/chargeback
Application	Which app/workload
BusinessUnit	Finance, Marketing, etc.
Criticality	High, Medium, Low

⚠️ Critical: Tags Are NOT Inherited

If you tag a subscription, resources inside do NOT get that tag automatically.

Making Tags Inherit (via Policy)

Azure Policy can force inheritance:

Policy	Behavior
Inherit tag from resource group if missing	Copies tag only if resource doesn't have it
Inherit tag from subscription if missing	Same, from subscription
Inherit tag from resource group	Always copies (overwrites)

Portal path: Policy → Definitions → Category: Tags → Search "inherit"

Tag Values Can Be JSON

Need more than 50 tags? Store a JSON document as the value:

{
  "malwareVersion": "2.1.5",
  "firewallConfig": "standard",
  "lastPatchDate": "2026-01-15"
}

Then parse it with automation.

Tag Uses

Use Case	How
Filter portal views	Resource list → Add filter → Tag
Cost analysis	Cost Management → Group by tag
Policy enforcement	Require certain tags on creation
Automation	Scripts query by tag

---

Inheritance (The Core Concept)

What Inherits Down?

Governance Type	Inherits Down?
RBAC (permissions)	✅ Yes
Policy	✅ Yes
Locks	✅ Yes
Tags	❌ No (use policy)
Budget	Rolls UP (not down)

Cannot Block Inheritance

Important: There is NO way to block inherited permissions.

If someone has Owner at subscription level, you as an RG owner CANNOT remove their access to your RG. This is by design - otherwise you'd undermine the entire hierarchy.

Inheritance Diagram

The Three Pillars at Each Scope

Pillar	Controls	Inheritance
RBAC	WHO can do things	Down ✅
Policy	WHAT can be done	Down ✅
Budget	HOW MUCH spend	Rolls up ↑

---

Locks (Quick Overview)

Locks prevent accidental changes/deletions at control plane level.

Lock Type	Can Modify?	Can Delete?
ReadOnly	❌ No	❌ No
CannotDelete	✅ Yes	❌ No

Key Points

• Applied at: Subscription, Resource Group, or Resource
• Inherited down (lock on RG applies to all resources in it)
• Control plane only - doesn't stop data operations (can still delete blobs in a locked storage account)
• Only Owner at the scope can remove the lock

---

Mental Model

Tags = Post-it Notes 📝

• Stick them on resources for info
• They don't automatically appear on things inside
• Useful for searching and billing

Inheritance = Water Flowing Downhill 💧

• RBAC and Policy flow DOWN from MG → Sub → RG → Resource
• You can't build a dam to stop it (no blocking)
• Budget flows UP like evaporation (aggregates)

---

AZ-104 Exam Tips

Topic	Key Point
Tags inheritance	NO - must use policy to inherit
Max tags	50 per resource
Tags on MG	Not supported
RBAC inheritance	Cannot be blocked
Lock types	ReadOnly vs CannotDelete
Locks scope	Control plane only, not data plane

---

Practical Exercises

Exercise 1: Add Tags to a Resource Group (5 min)

1. Open any Resource Group → Tags
2. Add: Environment = test, Owner = your email
3. Create a resource in that RG
4. Check: Does the new resource have those tags? (Hint: No!)

Exercise 2: Check Tag Inheritance Policy (5 min)

1. Portal → Policy → Definitions
2. Filter Category: Tags
3. Search "inherit"
4. Read the description of "Inherit a tag from the resource group if missing"

Exercise 3: Apply a Lock (5 min)

1. Create a test Resource Group
2. Go to Locks → Add
3. Choose CannotDelete
4. Try to delete the RG - what happens?
5. Remove the lock when done

Exercise 4: View Inherited Permissions (3 min)

1. Open a Resource Group → Access Control (IAM) → Role assignments
2. Notice the "Inherited" column
3. Trace back: where did each inherited permission come from?

---

What's Next?

Part 4: Locks & ARM Resource Structure - Deep dive into how Azure resources are structured (resource providers, types, properties) and why it matters for Policy and RBAC.

---

End of Part 3