A production subscription contains a shared network, a recovery vault, several storage accounts, and a small number of resources that would cause a serious outage if deleted. The team responds by placing locks everywhere. Six months later, routine automation fails because a Read-only lock blocks a control-plane update, an engineer removes a lock to finish a deployment, and nobody notices that the storage data itself was never protected by the resource lock. The control was present, but the operating model around it was weak.
Azure resource locks are useful precisely because they are blunt. For AZ-104, the important lesson is to understand what a lock protects, where it inherits, what it can disrupt, and how it fits with RBAC, Azure Policy, backup, and change management. A lock is a guardrail against certain administrative actions, not a complete resilience strategy.
Delete and Read-only locks answer different failure modes
Azure exposes two familiar lock behaviors. A Delete lock, represented as CanNotDelete in command-line tooling, allows authorized users to read and modify the resource but blocks deletion. A Read-only lock blocks deletion and control-plane modification, producing a result similar to restricting authorized users to Reader-like control-plane behavior for that resource.
The choice should follow the risk. A production database may need protection from accidental deletion while still allowing normal approved configuration changes, which makes a Delete lock plausible. A rarely changed foundational resource may justify Read-only protection if the team is prepared for the operational friction it introduces.
Applying the strongest lock everywhere is not maturity. It is a trade-off between change safety and changeability.
Locks inherit downward, so scope changes the blast radius
A lock applied at subscription scope affects resources beneath that subscription. A resource-group lock affects resources in that group. This inheritance is convenient for protecting a set of critical resources and dangerous when the set contains resources with different change patterns.
Before locking a broad scope, the team should inventory what automation, deployments, scaling actions, service integrations, and administrative tasks operate beneath it. A Read-only lock on a resource group can block operations on child resources in ways that surprise application teams because the lock was not created on the resource they are looking at.
As with RBAC, broad scope should be a deliberate decision. The organization should be able to explain why every child resource needs the inherited behavior.
A resource lock is primarily a control-plane guardrail
The most important limitation is that a lock does not automatically protect the data inside a service. Microsoft’s documentation explicitly distinguishes Azure Resource Manager control-plane operations from data-plane operations. A lock on a storage account can block control-plane deletion of the account or supported child resources, but it does not by itself stop an authorized data-plane operation from deleting or modifying blobs, queues, tables, or files.
This matters because teams sometimes treat a Delete lock as a substitute for backup, immutability, soft delete, versioning, or data-level authorization. Those controls solve different problems. If a malicious or mistaken application identity can delete objects through the data plane, the resource lock may remain perfectly intact while the data disappears.
Guardrails should therefore be selected at the layer where the damaging operation actually occurs.
RBAC controls who may change things; locks can still stop an authorized user
A user may have Owner permissions and still be blocked by a lock. That is intentional. RBAC says the identity is authorized to perform the action; the lock adds a resource-level constraint that can override the allowed control-plane operation.
This is valuable for resources where accidental action is a larger concern than ordinary authorization. It also means lock administration is privileged. If everyone who can delete the resource can casually remove the lock without additional scrutiny, the guardrail may add little during a high-pressure change.
Azure RBAC is useful here: identity authorization and resource guardrails should be reviewed as separate layers.
Azure Policy is better when the rule describes acceptable state at scale
A lock is tied to preventing deletion or modification. Azure Policy can express broader requirements across large scopes: allowed locations, tags, resource types, diagnostic settings, network configuration, and many other properties supported by the policy engine. Modern Policy also includes deny-action capability for supported operations such as deletion, but the governance model remains different from a traditional lock.
If the organization wants “these named foundational resources should not be deleted during normal work,” locks are intuitive. If it wants “resources of this class across every subscription must satisfy this organizational rule,” Policy is usually the more scalable expression.
Azure cloud governance becomes stronger when guardrails have clear purposes instead of stacking overlapping controls without knowing which one is expected to stop which failure.
Automation and infrastructure as code need a lock-aware operating model
Production Azure environments change through infrastructure as code such as templates, Bicep, and Terraform, plus pipelines, deployment stacks, scripts, and service-managed operations. A lock can interrupt those flows. An automation account that is correctly authorized may still fail because the locked resource cannot be modified through the required control-plane action.
The bad workaround is habitual lock removal before every deployment with no evidence or review. A better operating model defines which resources stay locked during normal releases, which changes legitimately require temporary removal, who can remove the lock, how the removal is approved, and how the lock is restored and verified afterward.
Where possible, pipelines can test for expected lock state before and after change. That turns the guardrail into an observable control rather than a portal setting people remember only after a deployment fails.
Measure exceptions, lock changes, and attempted violations
A mature lock strategy has telemetry. Activity logs can show creation and removal of locks and failed control-plane operations. Those events are useful because a sudden lock removal on a critical resource can be more important than a routine configuration change.
Teams should track which resources are locked, why, who owns the decision, and whether the lock still matches the current architecture. Orphaned locks create operational pain; missing locks create accidental-deletion risk. Temporary removal should have a visible reason and a short lifecycle.
Testing should include the negative path. Confirm that an authorized administrator cannot delete the protected resource while the lock is present. Confirm that necessary operational tasks still work. Confirm that data-protection assumptions do not depend on the lock where the relevant operation is actually data-plane.
A lock strategy should be tied to recovery and ownership
Suppose a shared hub virtual network is used by dozens of applications. Accidental deletion would cause a broad outage, and rebuilding it could be difficult because peerings, private endpoints, DNS paths, and firewall rules depend on it. A Delete lock adds sensible friction. The network team can still make approved configuration changes, but deletion requires an explicit lock-management step that should attract attention.
Now compare a storage account that contains critical files. A Delete lock on the storage account can protect the resource from certain control-plane deletion actions, but an application with powerful data-plane rights may still delete the files themselves. Protecting that workload may require soft delete, backup, versioning, immutability where appropriate, and narrower data permissions in addition to the resource lock.
These two examples look similar in the portal because both resources can display a lock. Their recovery models are different. That is why lock inventories should include the protected failure scenario and owner, not merely the lock type. Without that context, future administrators cannot tell whether a lock is an essential control or an obsolete obstacle.
Organizations should also define an emergency path. During a severe incident, a legitimate recovery action may require removing a lock. The process should be fast enough for recovery but still attributable, with the lock restored or intentionally retired after the emergency.
Use locks where a simple guardrail adds meaningful friction
Resource locks are strongest when the organization can name the failure they are meant to stop. Protect a critical shared network from accidental deletion. Add friction around a production resource that should change rarely. Prevent a routine deployment identity from removing an essential control-plane object even though it has broad rights for other reasons.
For the Azure Administrator Associate path, the durable rule is to keep the boundaries clear. RBAC answers who may act. Azure Policy expresses desired or prohibited resource state at scale. Locks add deletion or modification resistance to specific Azure scopes. Backup and service-specific protection preserve data. The architecture is safer when each control does the job it was designed to do and its exceptions are operated deliberately.
Lock placement should be reviewed whenever architecture changes. A resource that was once foundational may be replaced, while a newer shared dependency may now deserve protection. Inherited locks can also remain after teams reorganize resource groups. Periodic review should confirm that lock scope still matches ownership and that automation has not developed undocumented workarounds. A guardrail that everyone routinely removes is signaling either poor placement or a broken change process.
Locks should also be visible in architecture and runbooks. A recovery engineer who discovers a Read-only lock for the first time during an outage may lose valuable time determining whether removal is safe. Document which critical resources are intentionally locked, what operations the lock is expected to block, and who can authorize removal. That small amount of context turns a blunt platform feature into an operated resilience control.
Critical lock changes can also feed central monitoring. An alert for removal of a lock on a shared network, recovery vault, or other foundational resource gives responders a chance to distinguish approved maintenance from suspicious preparation for destructive action. The value comes from the context and response, not from alerting on every lock event indiscriminately.
