A company hosts a web application on an Azure App Service named app-invoices, which is deployed inside a resource group named rg-finance-prod. To protect the resources, an administrator applies a CanNotDelete lock directly to app-invoices. Additionally, a ReadOnly lock is applied to the resource group rg-finance-prod. A developer with Owner permissions attempts to update the configuration settings of app-invoices. What is the outcome of this update attempt?
- AThe update succeeds because the developer holds Owner permissions, which bypass resource locks.
- BThe update succeeds because the lock applied directly to the App Service is CanNotDelete, which allows configuration changes.
- The update is blocked because the App Service inherits the ReadOnly lock from the resource group.Answer
- DThe update is blocked because a CanNotDelete lock prevents both resource deletion and configuration modifications.
Answer
The update is blocked because the App Service inherits the ReadOnly lock from the resource group.
The correct answer is correct because resource locks are inherited from parent scopes (the resource group) to child resources (the App Service). Since a ReadOnly lock is more restrictive than a CanNotDelete lock, it takes precedence. Under a ReadOnly lock, all configuration modification and deletion attempts are blocked, regardless of the user's high-privilege RBAC roles.
Step-by-Step Solution
Key Concept
Azure Resource Lock inheritance and behavior