Resource lock

Security impact is indirect but real. A lock does not authenticate users, encrypt data, rotate secrets, or block every data-plane delete. Its security value is protecting control-plane assets that support security controls, such as key vaults, diagnostic settings, firewalls, private DNS zones, and monitoring workspaces. The risk is assuming a lock replaces RBAC, soft delete, backup, or least privilege. Anyone with permission to manage locks can lower the barrier. Protect lock permissions with Privileged Identity Management, change approval, Activity Log alerts, and least-privilege roles. Treat unexpected lock removal as suspicious. Lock governance should be reviewed with the same seriousness as privileged access.

Locks have no direct SKU charge, but they affect cost control in both good and bad ways. A CanNotDelete lock can prevent accidental deletion of expensive-to-recover resources, avoiding emergency rebuild labor and downtime. It can also stop a cleanup script from removing retired resources, leaving disks, databases, plans, or gateways billing for months. ReadOnly locks may block right-sizing or retention changes that would reduce spend. FinOps reviews should include lock inventory, owner notes, and retirement status. The cost question is whether protection prevents a worse loss or preserves waste. Cost reports should flag locked resources with no recent owner confirmation.

Reliability impact is direct at the management layer. Locks reduce the chance that a critical resource disappears during cleanup, migration, failed deployment rollback, or incident response. They also limit blast radius when automation has overly broad scope. The tradeoff is operational friction: ReadOnly locks can block scale, start, stop, backup cleanup, diagnostic changes, list-key operations, or provider actions depending on service behavior. Reliable use means choosing the narrowest lock level, documenting owners, testing deployments against locks, and building runbooks that remove and restore protection safely during maintenance. The relock step should be treated as part of service restoration, not optional cleanup.

Runtime performance is usually not affected because locks act on Azure Resource Manager operations rather than application data paths. A locked web app, database, or network still handles traffic normally unless a blocked management change prevents scaling, patching, tuning, or diagnostics. Operational performance is affected: engineers can diagnose lock-related deployment failures quickly when lock IDs and scopes are documented. Broad ReadOnly locks can slow incident response because every blocked action requires an unlock decision. Good lock design preserves runtime speed while adding only intentional friction to risky management operations. That balance is what keeps protection from becoming a bottleneck during incidents.

Operators manage locks by listing scope, level, notes, and inheritance before making changes. They create locks through templates, CLI, or portal workflows, then record why the lock exists and who can remove it. Troubleshooting often starts with a failed deployment or delete operation that names a blocking lock. Change windows should include explicit steps to remove the lock, complete the work, validate the resource, and recreate the lock. Operations teams should review stale locks because protected retired resources can become expensive clutter. Lock evidence belongs in audit and incident records. The review should include inherited locks that are not visible on the child resource at first glance.