Resource Locks
What Are Resource Locks?
Resource locks prevent accidental deletion or modification of Azure resources, regardless of RBAC permissions.
Even if a user has Owner or Contributor rights, a lock prevents certain actions. This is an important extra layer of protection for critical resources.
Real-world scenario: An engineer accidentally runs a script that deletes all resources in a resource group — including the production database. A lock would have prevented this.
Lock Types
Azure provides two types of locks:
|
Lock Type |
What It Prevents |
|---|---|
|
CanNotDelete |
Prevents deletion — users can still read and modify the resource |
|
ReadOnly |
Prevents modification AND deletion — users can only read |
ReadOnly Lock on a VM:
✓ Can: Read VM details, view configuration
✗ Cannot: Start/stop VM, resize VM, delete VM, change settings
CanNotDelete Lock on a Storage Account:
✓ Can: Read files, upload files, modify settings
✗ Cannot: Delete the storage account
Lock Inheritance
Locks applied at a higher scope apply to all resources within that scope:
Lock on Resource Group "Production-RG"
└── Applies to ALL resources inside:
├── VM-01 (locked)
├── SQL Database (locked)
├── Storage Account (locked)
└── Virtual Network (locked)
Managing Locks
Locks can be applied via:
-
Azure Portal (Resource → Settings → Locks)
-
Azure CLI:
az lock create -
Azure PowerShell:
New-AzResourceLock -
ARM Templates
To delete or modify a locked resource, you must first remove the lock — and only users with the right permissions can do that (Owner or specific lock management role).
Lock Levels
|
Applied At |
Applies To |
|---|---|
|
Subscription |
All resource groups and resources within |
|
Resource Group |
All resources within the group |
|
Individual Resource |
Just that specific resource |
Locks Summary
CanNotDelete → Protect from accidental deletion (still editable)
ReadOnly → Protect from any changes (view only)
Locks override RBAC — even Owners can't bypass a lock without removing it first.
Apply locks to: production databases, core networking resources, key vaults
Tags
What Are Tags?
Tags are name-value pairs that you attach to Azure resources and resource groups for organization, tracking, and automation.
Tags don't affect how resources function — they're purely metadata that helps you manage and understand your Azure environment.
Tag Examples
Resource: "prod-sql-eastus"
Tags applied:
Environment = Production
Department = Finance
Project = ERP-Migration
Owner = john.smith@company.com
CostCenter = CC-2045
ManagedBy = CloudOps-Team
What You Can Do with Tags
|
Use Case |
How Tags Help |
|---|---|
|
Cost allocation |
Filter billing by Department or Project tag |
|
Automation |
Shut down all VMs with tag |
|
Filtering |
Search for all resources in a specific project |
|
Compliance |
Enforce required tags using Azure Policy |
|
Resource ownership |
Know who owns a resource via the Owner tag |
|
Charge-back |
Bill departments based on their tag's resource costs |
Tag Rules and Limits
|
Rule |
Detail |
|---|---|
|
Max tags per resource |
50 |
|
Tag name max length |
512 characters |
|
Tag value max length |
256 characters |
|
Case sensitivity |
Tag names are NOT case-sensitive; values ARE |
|
Resource group tags |
Do NOT automatically apply to resources inside |
|
Azure Policy |
Can enforce required tags on all resources |
Enforcing Tags with Azure Policy
Use policy to require specific tags on all resources:
Policy: "Require tag 'Department' on all resources"
├── Effect: Deny → Block creation of any resource without this tag
└── Effect: Audit → Allow creation but flag as non-compliant
Tags in Billing Reports
In Azure Cost Management, you can group and filter costs by tag:
Monthly spending by Department tag:
Engineering: $4,200
Finance: $1,800
Marketing: $950
HR: $300
─────────────────────
Total: $7,250
This allows you to accurately charge each department for their cloud usage (chargeback model).
Azure Arc
What Is It?
Azure Arc extends Azure's management capabilities to infrastructure outside of Azure — including:
-
On-premises servers (Windows/Linux)
-
Virtual machines on other cloud providers (AWS, GCP)
-
Kubernetes clusters running anywhere
-
SQL Server instances outside Azure
Azure Arc lets you manage everything from a single control plane — the Azure portal.
The Problem Azure Arc Solves
Most organizations have a mix of infrastructure:
Without Arc:
Azure Portal → manages Azure resources only
VMware vCenter → manages on-premises VMs
AWS Console → manages AWS resources
Kubernetes CLI → manages Kubernetes clusters
(4 separate tools, 4 separate workflows)
With Arc:
Azure Portal → manages EVERYTHING from one place
(1 tool, 1 workflow)
Azure Arc Components
|
Component |
What It Does |
|---|---|
|
Arc-enabled servers |
Register non-Azure Windows/Linux machines in Azure |
|
Arc-enabled Kubernetes |
Bring any Kubernetes cluster into Azure management |
|
Arc-enabled SQL Server |
Manage on-premises SQL Server from Azure |
|
Arc-enabled data services |
Run Azure SQL Managed Instance or PostgreSQL anywhere |
What You Can Do with Arc-Enabled Servers
Once a non-Azure server is Arc-enabled (via an agent installed on the server), you can:
-
View it in the Azure portal like a native Azure VM
-
Apply Azure Policy to it
-
Use Azure Monitor for logs and metrics
-
Assign Azure tags
-
Use Microsoft Defender for Cloud to protect it
-
Manage extensions (monitoring agents, antivirus)
-
Perform Update Management centrally
Azure Arc Use Cases
|
Scenario |
How Arc Helps |
|---|---|
|
Hybrid cloud governance |
Apply Azure Policy to on-premises servers |
|
Centralized monitoring |
Azure Monitor for on-premises and cloud together |
|
Consistent security |
Defender for Cloud across all environments |
|
Kubernetes at the edge |
Manage K8s clusters in factory floors or remote locations |
|
Regulated industries |
Extend Azure governance to on-premises without cloud migration |
Arc Architecture (Simplified)
On-Premises Server (Windows/Linux)
└── Azure Connected Machine Agent installed
│ Secure HTTPS outbound connection
▼
Azure Arc Service (in Azure)
│
▼
Resources appear in Azure Portal
→ Apply Policy, Monitor, Tag, Defend
The agent communicates outbound to Azure (no inbound connections required), so it works through most corporate firewalls.
Summary of All Three Topics
|
Topic |
Purpose |
|---|---|
|
Resource Locks |
Prevent accidental deletion or modification |
|
Tags |
Organize, filter, and track resources with metadata |
|
Azure Arc |
Extend Azure management to non-Azure infrastructure |
Quick Recap
Locks:
CanNotDelete → Can edit, cannot delete
ReadOnly → Can only read, cannot edit or delete
Locks inherit downward and override RBAC permissions
Tags:
Key-value metadata on resources
Use for billing, automation, compliance, filtering
Max 50 tags per resource; enforce with Azure Policy
Azure Arc:
Bring non-Azure servers and K8s into Azure management
1 pane of glass for hybrid and multi-cloud environments
Apply Policy, Monitor, Defend — everywhere
Official References
Next Chapter → Chapter 19: Azure Compliance & Privacy