Azure / Basic: scope, identity, location, and resources / Lesson 2

Microsoft Entra identity and Azure RBAC

Separate authentication, directory administration, resource authorization, and data access. Model a principal, role, and scope before interpreting an allowed or denied operation.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Distinguish Entra ID roles from Azure resource roles.
Explain assignment scope and control/data planes.
Use least-privilege reasoning without real identities.

An authenticated identity is not universal permission

Microsoft Entra ID is the identity service formerly named Azure Active Directory; Microsoft Entra is the broader product family. A tenant holds an identity directory context. Users, groups, service principals, and managed identities can participate in access designs, but their identifiers and lifecycles differ. Authentication establishes which identity a token represents under its issuer and audience contract. Authorization then evaluates the requested operation and scope. A valid token for the wrong audience or tenant is not a usable credential for every Azure service. Never infer permission merely because the portal sign-in succeeded.

Directory roles and resource roles have different purposes

Microsoft Entra administrative roles govern directory responsibilities, while Azure RBAC governs Azure resource access through role assignments. An assignment combines a security principal, role definition, and scope. Inheritance through management groups, subscriptions, and resource groups can broaden effective access, so review parent scopes as well as the visible local assignment. A directory administrator is not automatically the application’s data reader under every resource policy. Distinguish the authority to manage or assign access from the permission to use particular data operations. Additional deny assignments, conditions, service settings, and credentials can affect the real outcome.

Control-plane reading does not imply blob-data reading

A resource can expose management operations and separate data operations. Azure’s Reader role is a management-plane example; Storage Blob Data Reader is a data-access example. The teaching JSON below records that distinction without creating an assignment. It intentionally omits actual principal IDs, subscription IDs, and deployment schemas. Network restrictions are another boundary: having the right role does not guarantee a service endpoint is reachable, and reaching it does not grant data permission. Shared keys or other credential paths need their own review because they can change the authorization route being exercised.

json A role/operation distinction, not a role assignment

{
  "model": "permission-planning-only",
  "cases": [
    {
      "role": "Reader",
      "operation": "management.read",
      "expected": "candidate-allow"
    },
    {
      "role": "Reader",
      "operation": "blob.read",
      "expected": "not-granted-by-this-role"
    },
    {
      "role": "Storage Blob Data Reader",
      "operation": "blob.read",
      "expected": "candidate-allow"
    }
  ]
}

Expected output

management and data permissions are evaluated separately

Candidate outcomes are not live authorization results. Real scope, deny rules, conditions, network access, and credential paths remain untested.

Scope matching must respect the resource boundary

Choose the narrowest scope that supports the legitimate task and include access review and removal in the lifecycle. A parent-scope grant can cover descendants, but a similarly spelled sibling is not a descendant. The offline function checks path-segment boundaries for synthetic identifiers so rg-a does not accidentally match rg-a2. It is not an implementation of Azure RBAC, which includes richer semantics and service-specific checks. Use it to expose a reasoning mistake, not to replace the platform authorization system or to validate a real assignment. No identity or cloud API is contacted.

python Offline scope-boundary reasoning

def within(scope, target):
    return target == scope or target.startswith(scope + "/")
scope = "/subscriptions/s-lab/resourceGroups/rg-a"
print(within(scope, scope + "/providers/example/items/one"))
print(within(scope, "/subscriptions/s-lab/resourceGroups/rg-a2"))

Expected output

True
False

The synthetic path check rejects a sibling prefix. It does not inspect real inherited Azure permissions.

Plan for workload identity and access evidence

Managed identities can reduce application secret handling for supported Azure resources and services, but they still need correct role assignment and target-service configuration. Separate identity selection from role scope and from network connectivity. Review human emergency access, privileged changes, and noninteractive workload access as different use cases. For a denied request, preserve safe operation, target, and correlation context without logging tokens. A future authorized test should include both a permitted case and a denied cross-scope case. This course uses only hypothetical assignments and cannot claim an actual tenant, token, or permission was validated.

Common errors and fixes

Directory administration is assumed to grant every data operation

Why it happens: Identity governance and resource authorization are conflated.
How to fix it: Inspect the actual resource role, data operation, and scope.
Prevent it next time: Document directory and resource responsibilities separately.

A broad parent grant is overlooked

Why it happens: Only the local visible assignment is reviewed.
How to fix it: Review inherited grants and relevant deny/condition behavior.
Prevent it next time: Include parent scopes in access reviews.

A token is copied into a diagnostic report

Why it happens: Sensitive authentication evidence is treated as ordinary text.
How to fix it: Use safe identifiers and failure categories instead.
Prevent it next time: Define redaction and retention before collecting access evidence.

Check your understanding

1. A principal can view a storage account but cannot read blobs. What should be separated?

Show worked solution

Separate management-plane permission from the blob-data operation, then inspect the intended data role, scope, credential path, and network policy. Do not grant a broad owner role merely to make the symptom disappear. A future authorized positive and negative test should confirm the narrow intended access.

2. Does the offline scope function implement Azure RBAC?