Who may do what, and where?
Ada has been asked to review the shop’s product images. Her manager reaches for Owner because it sounds certain to work. Imagine giving a stock reviewer the keys to every shop, permission to change the locks, and no return date. Start with the actual job instead: read images in one account. Then imagine an authorised builder trying to build in a location the company forbids. These are two different checks: RBAC asks what this identity may do here; Policy checks whether the proposed resource meets the applicable rule.
Azure role-based access control (RBAC) decides which identity may perform an operation on which Azure resources. One role assignment joins three parts: a person or group (who), a role definition (what they may do), and a scope (where that permission applies). A successful Entra sign-in proves identity; it does not by itself grant permission to change a resource.
- Who
- A user, security group, service principal or managed identity. We will use Ada, but a team group is often easier to review than many individual grants.
- What
- A role such as Reader, Contributor or Storage Blob Data Reader. The role contains specific allowed operations.
- Where
- A management group, subscription, resource group or single resource. An assignment normally applies to that scope and its child scopes.
Permissions from applicable role assignments add together. A narrow new assignment does not cancel a broad existing one. Check Ada's direct and group assignments at parent scopes before claiming that her effective access is limited to this storage account.1
Reading a resource is different from reading its data
A storage account is an Azure resource; a blob is a file-like object inside it. Control-plane operations manage the account and its settings. Data-plane operations read or change the blobs. The distinction explains why a general Reader role can see an account without automatically getting blob contents through Microsoft Entra authorization.
| Role | Typical purpose | Why it fits or misses |
|---|---|---|
| Reader | Inspect Azure resource settings | Does not include blob-data read permissions. |
| Storage Blob Data Reader | Read blob data | Fits the task when assigned at a suitable scope. |
| Contributor | Manage Azure resources | Far too broad. It may also obtain storage account keys when key access is enabled. |
| Owner | Manage resources and assign roles | Broader still; not justified by a read-only task. |
For the exercise, give Ada Storage Blob Data Reader on the one account after checking for inherited access. Do not give Contributor just because it lacks blob DataActions: Contributor can usually list account keys, and a key may grant data access when shared-key authorization is allowed. Some storage accounts disable shared-key authorization. The actual path depends on that configuration. There is also a distinct built-in role called Reader and Data Access; do not confuse it with ordinary Reader.2
A role definition lists Actions for management operations and DataActions for supported data operations. NotActions removes an operation from that role's Actions; it is not a general deny against other assignments. Contributor excludes access-management operations and other privileged operations, but its exclusions are more than a single pair of writes. Read the current definition before relying on a shorthand description.
Choose the smallest role and scope that meet the task. Then test with the intended identity. If a VM deployment fails, read the exact denied operation before granting broader access; an unrelated policy, network rule or missing data permission may be the real problem.
Try the access decision
Place Ada's role at a scope, choose what actually reads blob data, then remove the simulated assignment when her task ends. The diagram counts only its four illustrated resources. It does not measure every resource in a real subscription. On a phone, swipe the board sideways; you can use destination buttons instead of dragging.
What if the person is allowed, but the change is not?
RBAC can authorize a person to create a storage account. Azure Policy can check whether the proposed account meets a rule, such as an allowed region. A policy assignment has its own scope. If an applicable deny policy rejects the request, being Owner does not make that request pass.
- Audit
- Records a non-compliant result without blocking the request. Use it to see the impact of a proposed rule.
- Deny
- Rejects a matching create or update request. It does not delete an existing resource.
- Modify / DeployIfNotExists
- Can change or deploy supported properties or related resources. Their behavior and remediation prerequisites differ; neither means all old resources are automatically repaired.
A policy definition is the rule. An assignment applies it at a scope, often with parameters. An initiative groups definitions. An exemption records a justified exception. A policy can also exclude a child scope. These details matter: “we have a deny policy” does not prove that a particular resource was evaluated by it.3
A resource lock protects against certain changes such as deletion, but someone with permission to manage locks may remove it first. Policy is not a substitute for permissions on data inside a resource, and a policy assigned by a person who can remove or exempt it is not an unchangeable boundary. Review who can manage the assignment and where it sits.
How do you roll out access and rules safely?
Start by naming the work. Ada needs to read images in one account; a deployment identity needs specified create and update operations; an auditor needs resource metadata. These are different jobs. Choose a built-in role for each, inspect its definition, and narrow the scope. Review direct and inherited grants before and after the change.
For a new allowed-region rule, first inventory the resources and test an audit assignment in a controlled scope. An audit result shows what would be flagged; it does not block a deployment. Agree on exceptions and a migration plan, then introduce deny where it is appropriate. Existing resources may remain non-compliant without being deleted. Remediation is a separate, reviewed operation for effects that support it.
Privileged Identity Management (PIM) can make a supported role eligible for temporary activation instead of continuously active. Eligibility, activation duration, approvals and end date are distinct settings. A two-hour activation does not automatically make a six-week project assignment disappear when the project ends. Record an owner and an end date, and review or remove the assignment when the work finishes.4
The smallest useful grant
Ada receives Storage Blob Data Reader at the account she works with. The team checks whether she also has inherited permissions through another group. A separate engineer proposes an allowed-region rule in audit mode for the test subscription; the team reviews its findings before using deny. Nobody assumes that a label or diagram enforced either choice.
Check the source
Compare role assignments, role definitions, storage data roles and key permissions, and Policy effects. Use the role's actual permission list when a decision matters.
Inspect a role before granting it
Use a training subscription you are authorised to inspect. If you lack one, read the current built-in role pages linked above and complete the comparison on paper. The commands below only read Azure configuration.
In Bash Cloud Shell, confirm the selected subscription. Stop if it is not the training subscription you intended.
az account show --query '{name:name,subscriptionId:id}' --output tableInspect Reader, Contributor and Storage Blob Data Reader. Look at Actions, NotActions and DataActions; do not infer them from the role name.
az role definition list --name Reader --output json az role definition list --name Contributor --output json az role definition list --name 'Storage Blob Data Reader' --output json
Write one sentence for each: what does it allow, and what could it expose if assigned at the whole subscription? Do not create an assignment just to answer the question.
Find the effective scope
Open a training resource group and select Access control (IAM). View role assignments and notice the scope shown for direct and inherited entries.
Choose a training identity you are permitted to review. Use Check access to inspect how it receives its permissions. Record whether a parent scope or group membership contributes.
Open Policy → Compliance for the same scope. Pick one visible assignment and record its effect, scope and any exclusion. If none exists, describe what information you would need before claiming a deny applies.
Plan a temporary grant and a policy rollout
A contractor needs to deploy one test application for six weeks. Name the required operations and the smallest useful scope. Decide who approves the grant and who removes it.
The team proposes an allowed-region rule. List the current resources, select a test scope, run audit first, document legitimate exceptions, and decide when a deny would be safe. State separately what happens to existing non-compliant resources.
Three checks before declaring access safe
A role name or policy title is only a starting clue.
Which assignments apply through direct grants, groups and parent scopes?
Is the request for management of a resource or for data inside it? Could account keys change the answer?
Which policy effect, parameter, scope and exception actually apply to the request?
Test the chosen identity and request. Save the evidence with the change record.
Explain a blocked deployment
Ask for the exact operation and error. Check whether RBAC denied the caller, Policy denied the proposed resource, or a service-specific control blocked the action. Change the smallest relevant setting through the review process, then retry and verify. “Make them Owner” is not a diagnosis.
Continue with a supplied build
Before you start: Labs C and D wrap each step in a Bash function, defined in one paste and run on the next line. If that pattern is new, do step 6 of the terminal warm-up first; it takes two minutes. Use the existing disposable Policy lab to submit a compliant and non-compliant storage request. Record the policy denial separately from a missing RBAC permission. Follow its explicit assignment, definition and resource-group cleanup. For an actual role assignment and data-access proof, continue to the identity lab in Class Nine.
Check your understanding
Four graded drills and two unscored situations. Multi-select options shuffle; choose by meaning. Practice preserves your first-attempt score. Write each situation answer before revealing the reasoning.
B. Scope inheritance reaches child resources added later, but general Reader is not the same as a storage data role. Check data-plane permissions separately. A subscription assignment does not spread sideways to every other subscription.
Imagine Ada opening the portal tomorrow and seeing a new account under the same subscription. The inherited Reader grant can let her inspect its configuration, but that is not a promise that she can download its private images. Testing the actual operation with the intended identity avoids confusing a visible resource with readable data.
C. The task is reading blob data in one account. Owner and Contributor are broader management roles; Contributor may also retrieve account keys when key access is enabled. General Reader does not include blob-data read permission. Check existing grants before adding another.
The reviewer needs the images, not permission to resize the account, change its network rules or hand access to another person. Start from that read operation. A failed read may still involve network configuration or a propagating assignment, so keep the exact error and check the path instead of increasing the role until the error disappears.
The correct ideas are the three-part assignment, an applicable deny, and audit without a block. NotActions narrows only its own role definition; another assignment may still allow the operation. Role grants add together, so review and change an overly broad parent grant rather than expecting a narrower grant to undo it.
Picture two permission slips: one broad, one narrow. Giving Ada the narrow one does not tear up the broad one. In the same way, a restricted role definition does not become a global denial. Policy is a different check on the proposed resource. Diagnose the operation at the layer that actually refused it.
TRAINING ENVIRONMENT — PROPOSED ACCESS
1. Auditor: Reader on the test resource group.
2. Image reviewer: Storage Blob Data Reader on one account.
3. CI identity: Owner on the whole subscription so jobs never fail.
4. Contractor: task-specific role on one test resource group,
with a named removal date.Line three. A pipeline should get only the operations and scope its deployment needs. Owner at a whole subscription adds role-management power and broad reach. Start from the actual deployment steps; some pipelines may require a specific additional permission, which should be reviewed explicitly rather than hidden behind Owner.
A workflow file is code that runs with this identity. A careless or hostile change could therefore affect unrelated groups and their access under the proposed Owner grant. List the deployment operations, remove unnecessary grants and test a small scope. A specific role-management task needs an explicit reviewed permission, not an unnoticed blanket exception.
Concede the delivery pressure. “I want the contractor unblocked too. Which deployment operations do they need?” Start there rather than implying that the manager does not care about safety.
Name the consequence. Permanent subscription Owner permits far more than deploying this test app, including role-management power. A small role assignment does not cancel an inherited broad grant. Inspect effective access before choosing a role at the application group.
Offer a workable limit. Agree the six-week end date, name who removes or reviews access, and verify the actual deployment. Where PIM is available, short activation reduces standing access; it still needs a project-end assignment review.
Say what you would actually request. “For this test app, let us first try Contributor on its dedicated resource group, without role-assignment permission. If deployment needs an operation that role lacks, we will review that operation separately. I will record the approver and removal date, then watch the contractor deploy and confirm the job succeeds.” Contributor is still broad within that group, so a task-specific role may be preferable once the required operations are known. Six weeks describes the project window; it does not justify permanent subscription access.
Separate the two checks. “Owner can submit the operation, but the resource must still satisfy applicable Policy.” That explains the manager’s successful login without suggesting that identity permission should be removed just to restrict a region.
Plan the rollout. Inventory existing resources and legitimate exceptions. Use an audit-capable definition in a controlled scope before enforcement; do not assume every built-in deny definition has an audit switch. Test allowed and disallowed requests.
Explain the result. Deny blocks matching create or update requests; it does not delete existing resources. Record scope, exceptions and policy ownership, then verify the original failure is the intended policy denial.
Walk through a trial request. In the training scope, submit one resource in an approved region and one in a disallowed region. Before enforcement, an audit-capable rule should report the mismatch without stopping the second request. After a reviewed Deny assignment has propagated, the disallowed request should fail with a policy error while the approved request succeeds. If both fail, investigate the error rather than declaring the policy correct. Existing resources remain in place, though later updates may be affected by the applicable rule.
Five checks to carry forward
- A role assignment is who, what and where. Scope reaches children, and applicable role grants add together.
- Resource management and blob-data access differ. Check account-key paths before claiming a management role cannot reach data.
- Reader, Contributor and Owner have different reach; read the current role definition and choose the smallest useful grant.
- An applicable deny Policy can stop an authorized create request. Audit observes without blocking.
- Plan exceptions, ownership, expiry and verification. A short PIM activation does not automatically end a project assignment.
- Microsoft documents the three parts of a role assignment, scope inheritance, and the additive access model. ↩
- Compare storage roles and key permissions with disabling Shared Key authorization. Configuration changes the risk. ↩
- The Policy effects, assignment structure, and exemptions explain what actually applies. ↩
- Microsoft distinguishes PIM role activation from the assignment's eligibility period. ↩
Assign the least role that does the job, and say when Policy, not RBAC, is the right tool.
Play the lesson above to stamp this class.
Next: how an app proves who it is without a password to steal.
Next · Service Principals & Managed Identity →