A scenario says a deployment must be secure. That is not yet enough information to select a control. First identify what needs to be restricted: the caller's permissions, the resource's configuration, or an operation such as accidental deletion. Azure RBAC, Azure Policy and management locks can work together, but they do not answer the same question.
Start with the requirement, not the product name
| Requirement | Starting point | What to check |
|---|---|---|
| A particular identity needs permission | Azure RBAC | Principal, role and scope |
| A resource must meet a configuration rule | Azure Policy | Definition, effect and assignment scope |
| Prevent accidental management-plane deletion | A CanNotDelete lock | Inherited locks and the operation's plane |
Treat this table as a starting point, not a universal shortcut. A complete answer needs the requested action, its scope and any other controls that also apply. In your notes, write a short requirement sentence before naming a service. That makes it easier to notice when an option solves only half the problem.
Scenario 1: the support team needs limited access
A support group needs to inspect virtual-machine configuration in a training resource group, without changing resources. The group has no other relevant assignments. Your task is to decide what kind of control to investigate, not to memorize a role name from a short scenario.
Azure RBAC is the starting point because the requirement is about an identity performing actions at a defined scope. A role assignment combines a principal, a role definition and a scope. Check the role's actual permissions and any inherited access before deciding it is sufficiently restricted. Microsoft also distinguishes data actions, so permission to inspect a resource should not be assumed to grant access to every piece of data inside it.
Why not start with a lock? The problem is assigning the group's access, not protecting a resource from everybody's accidental management operations. Why not start with a region policy? It would address a deployment condition rather than this group's inspection permissions. Write those reasons explicitly; merely remembering 'RBAC equals users' is too shallow.
Scenario 2: deployments must use approved regions
A project team already has permission to deploy resources. The organization now requires applicable new resources to use approved Azure regions. Granting more permissions would not express that restriction. Review an Azure Policy definition and its assignment for the location requirement.
Policy evaluates resources and actions against defined rules. The effect matters: an audit result and a deployment restriction are not the same outcome. Check what the chosen definition covers, its parameters and assignment scope. Do not assume a rule that reports existing noncompliance automatically repairs it; remediation depends on the policy effect and configuration.
Change one fact in the exercise: suppose the team now needs permission to deploy, but no regional restriction exists. Your answer should change too. This contrast helps separate the requirement from the familiar words in the question. Keep a two-column note: permission to act on one side, conditions the deployment must satisfy on the other.
Scenario 3: prevent accidental deletion, not data loss
An administrator wants a resource to remain editable but protected from accidental deletion through Azure Resource Manager. A CanNotDelete management lock fits that starting requirement: authorized users can read and modify the resource while the lock prevents deletion. Inspect parent scopes because locks can be inherited.
Now the administrator asks whether this also prevents someone deleting application data. That conclusion does not follow. Microsoft states that management locks apply to control-plane operations, not data-plane operations. A lock is therefore not a substitute for checking data permissions, backups and recovery requirements. ReadOnly and CanNotDelete also differ; do not choose the broader restriction simply because it sounds safer.
Use a four-question review checklist
- What exact action is requested or prohibited? Replace broad words such as secure with a testable requirement.
- Who performs it, and where? Record the identity and relevant subscription, resource group or resource.
- Which control addresses that requirement, and what does it leave unresolved? Name at least one boundary.
- What change to the scenario would make another control necessary? Explain how the controls could complement each other.
For administration coverage, continue with the AZ-104 study guide and AZ-104 practice. For architecture trade-offs, use the AZ-305 decision journal alongside AZ-305 practice. A correct answer on these three scenarios does not establish coverage of either full exam.