Write the permission question before opening the portal
Seeing a resource in Azure is different from being allowed to change it or read the data it stores. This worksheet helps you describe exactly what you expect a test identity to do. It is a learning exercise for an authorised lab, not a request to change access in a customer or production subscription.
Microsoft describes an Azure role assignment through three elements: the security principal, the role and the scope. Record all three. “My account has access” is too vague to reproduce a test.
Set up the exercise on paper first
Fictional scenario: a trainer provides a test identity named Learner A and a resource group named practice-rg. The intended assignment is Reader on that resource group, with no additional role or group membership granting broader access. The example describes expected results; no live Azure test was performed for this page.
- Identity: record the test principal's object identifier and tenant privately. Confirm the session is actually using that identity.
- Scope: record the subscription and full resource-group identifier. Use approved lab resources and non-sensitive sample data only.
- Role: record the exact role name and assignment scope, including inherited assignments and relevant group access.
- Environment: agree who owns the lab, which observations are allowed, any resource costs and how the lab will be cleaned up.
The test matrix
Copy each row into your notes with columns for expected result, observed result, evidence reference and explanation. Leave the observed result blank until the check actually happens.
- A — Read resource configuration inside practice-rg
- Expected under the scenario: permitted by Reader for control-plane resource information. Record the exact resource, operation and identity. A resource's absence is not itself an access-denied result.
- B — Change a resource setting inside practice-rg
- Expected: Reader alone does not grant this change. Start by inspecting effective permissions. Any attempted write requires the trainer's separate approval and a disposable target; an unexpected success could change the resource.
- C — Read a resource in another resource group
- Expected: the practice-rg assignment does not grant access there. A separate or inherited assignment could change the result, so inspect it before drawing a conclusion.
- D — Read the contents of a storage blob
- Expected: Reader alone does not grant blob data access. Other roles or authentication methods may allow it. Do not use an account key or a different identity to “make the test pass”.
The Reader role definition grants control-plane read actions and no data actions. This explains why a successful resource-configuration read does not demonstrate access to stored file contents.
Investigate a surprising result
- Check the identity and directory. A second signed-in account or a different tenant can make a comparison meaningless.
- Inspect the assignment scope. Azure roles can apply at broader scopes and be inherited. Use Microsoft's role-assignment listing guidance to inspect the assignments you are authorised to see.
- Record the precise operation. Distinguish a configuration read, a write and a data request. A network error or missing resource is not proof of an RBAC denial.
- Check timing and conditions. After an authorised role change, access may not reflect it immediately. Record when it changed and follow current Microsoft troubleshooting guidance before concluding that the role is wrong.
- Keep the failure useful. Save the redacted error, time and request reference. Ask the lab owner to explain the result instead of adding Owner or another broad role.
Hand over an honest result
A completed worksheet includes the intended assignment, each actual observation, what remains uncertain and any access the lab owner removed afterwards. “Not tested” is a valid entry. Do not record a denied write as observed just because the role definition predicts it.
Discuss this exercise alongside the access-control topics in Azure training. It is a suggested practice resource, not a promise that a particular subscription, paid lab or assignment is included in a batch. For a separate networking exercise, see tracing an Azure network request.