Curriculum Overview: Mastering Azure Resource Locks

This curriculum provides a structured path to understanding how to protect Azure resources from accidental deletion or modification using Resource Locks. This is a critical component of the AZ-900: Microsoft Azure Fundamentals exam and everyday cloud governance.

Prerequisites

Before starting this module, students should have a baseline understanding of the following:

• Azure Resource Hierarchy: Knowledge of Management Groups, Subscriptions, and Resource Groups.
• Azure Resource Manager (ARM): Understanding that ARM is the deployment and management service for Azure.
• Role-Based Access Control (RBAC): Basic familiarity with how permissions are assigned to users and groups.

Module Breakdown

Learning Objectives per Module

Module 1: Fundamentals of Locks

• Define a resource lock as a mechanism to prevent accidental changes.
• Explain why locks apply to all users, even those with Owner or User Access Administrator roles.

Module 2: Lock Types & Behaviors

• Distinguish between the two primary lock types:
  • ReadOnly (ReadOnly): Prevents any changes to properties and prevents deletion.
  • Delete (CanNotDelete): Prevents deletion but allows authorized users to modify properties.
• Understand that ReadOnly can have unpredictable side effects (e.g., blocking key listing in Storage Accounts).

Module 3: Inheritance & Scope

• Explain the flow of inheritance from Subscription → Resource Group → Resource.
• Apply the "Most Restrictive Wins" rule when multiple locks are applied.

Module 4: Troubleshooting & Management

• Identify how to remove or edit locks via the Azure Portal.
• Understand that CLI or PowerShell provide more detailed error messages than the Portal for lock-related denials.

Success Metrics

To demonstrate mastery of this curriculum, the learner must be able to:

1. Correctly identify which lock type allows a user to update a Virtual Machine's size but prevents them from deleting it.
2. Predict the behavior of a new resource added to a Resource Group that already has a CanNotDelete lock applied.
3. Explain the limitation of locks regarding internal resource operations (e.g., adding secrets to a Key Vault even with a ReadOnly lock).
4. Diagram a hierarchy showing how a subscription-level lock affects a specific resource.

Real-World Application

Resource locks are not just theoretical; they are essential for "Production Safety":

• The "Fat Finger" Guard: Preventing an administrator from accidentally deleting a production database during a routine cleanup of unused resources.
• Compliance & Governance: Ensuring that critical networking infrastructure (like ExpressRoute circuits or Hub VNETs) cannot be modified without an explicit, multi-step process (removing the lock first).
• Automation Safety: Preventing automated scripts or CI/CD pipelines from over-provisioning or deleting core shared services.

[!IMPORTANT] Always remember: Locks override RBAC. Even if you are the Global Admin, you must manually remove the lock before you can delete the protected resource.

Visual Summary of Lock Logic

The following TikZ diagram illustrates the logic used to determine if an action is allowed based on the lock type.

\begin{tikzpicture}[node distance=2cm, auto] \node [draw, rectangle, rounded corners] (start) {User Request}; \node [draw, diamond, below=of start, aspect=2] (lock) {Is there a Lock?}; \node [draw, diamond, right=of lock, aspect=2] (type) {Type?}; \node [draw, rectangle, below=of lock] (allow) {Action Allowed}; \node [draw, rectangle, below=of type] (delete) {Allow Modify, Block Delete}; \node [draw, rectangle, right=of type] (readonly) {Block All Changes};

\end{tikzpicture}