Which Azure feature prevents accidental deletion of a resource while still allowing read and modify operations?
Show answer and explanation
Answer: B
The CanNotDelete lock is scoped to exactly this problem: management-plane delete requests are refused while every other authorized operation, including reads and modifications, continues to work normally until someone deliberately removes the lock.
A ReadOnly lock goes further and freezes modifications too, a policy deny effect governs what configurations can be created or changed rather than serving as this specific delete guard, and revoking delete rights through RBAC still means authorized roles could delete.
Why the other options are wrong
- A. A ReadOnly lock blocks modification as well as deletion, which goes beyond the requirement to keep reads and modifications working.
- C. A policy deny effect rejects non-compliant configurations during creation or change; the purpose-built feature for blocking deletes on an existing resource is the lock.
- D. An RBAC assignment withholding delete permission simply hides the capability from that identity; any authorized identity can still delete, so it is not the resource-level safeguard described.
Exam tip. CanNotDelete = delete blocked, modify allowed. ReadOnly = both delete and modify blocked.