Turn the requirement into a question
An Azure governance case may ask who may perform an action, what properties a resource must have, or whether an authorized person may accidentally delete or modify an existing resource. Azure RBAC, Azure Policy and resource locks can address different parts of those requirements. Do not reduce the entire product to one slogan: Policy has several effects and capabilities. For this foundation lesson, reason from the specific role assignment, property rule or lock described in the case.
Read permission and property rules separately
RBAC roles combine a principal, actions and scope. A Policy assignment evaluates supported resources/actions against its specified rule and scope; allowed locations and required tags are common property-rule examples. If authorized deployers must still create compliant resources while out-of-list resource locations must be rejected, removing everyone’s create permission is not an equivalent solution. The stated requirement preserves some operations while testing a particular property. Scope and the chosen effect matter, so not every Policy assignment implies creation rejection.
Worked example
A fictional arts group wants existing deployment operators to keep creating approved resources, but every new project resource must carry its supplied ProjectCode tag. First separate action permission from the resource condition. The operators’ role can authorize deployment without enforcing that property. A suitable scoped Policy deny rule for missing ProjectCode directly matches the new-resource constraint. A spending notification reports a different condition. A deletion lock protects a different operation. The conclusion does not mean tags grant access or that all governance needs are solved by this one rule.
Locks protect named management operations
A CanNotDelete lock permits authorized reads and modifications but prevents deletion; ReadOnly prevents updates as well as deletion for the relevant management operations. Neither description means that a lock creates a missing RBAC permission or validates every application data operation. The official guidance distinguishes management-plane protection from data-plane behavior. When accidental deletion is the stated concern but required updates must remain possible, inspect that distinction rather than choosing the most restrictive-sounding label without considering its effect.
Transfer check
A fictional maintenance task must update a resource’s configuration while protecting it from accidental deletion. The operator already has the required permission. A colleague chooses a ReadOnly lock because it sounds safest. What conflicts with the task? Check basis: the stated update must remain possible, while ReadOnly also blocks relevant modifications. A correctly scoped CanNotDelete lock matches the narrower deletion-protection purpose in this conceptual case. Check actual service/operation effects before any real use; no account or resource is changed by this exercise.
Try it, then explain it.
Complete a short set without looking at the example. After each answer, explain which evidence or rule supports your decision and why the alternatives do not fit.
Sources & authorship
Original OpenExam explanations and examples. References support the concepts; they are not the source of copied questions. Independent educator review is pending.
What is Azure role-based access control (Azure RBAC)?What is Azure Policy?Lock your Azure resources to protect your infrastructureTutorial: Create and manage budgets