What is Identity & Access — Entra ID & RBAC in Microsoft Azure?

7 / 24

Microsoft Azure

Identity & Access — Entra ID & RBAC

Authenticate identities with Entra ID and authorize actions with role-based access control.

Entra ID authenticates. RBAC authorises. Keeping those separate is the first thing to get right.

Entra ID is the company's ID office that verifies who you are (with extra checks for risky logins), while RBAC is the org chart of permissions: a title (role) granted at a level (scope) automatically applies to everything beneath it. Managed identities are staff badges issued to robots so they never carry written-down passwords.

Key Concepts

    Entra ID   who are you?      users, groups, apps, managed identities
    RBAC       what may you do?  role assigned at a scope

RBAC is a triple: principal, role, scope.

    assign  "Storage Blob Data Reader"
    to      the app's managed identity
    at      this one storage account

Scope inherits downward through the hierarchy:

    Management Group -> Subscription -> Resource Group -> Resource

A role granted at a resource group applies to everything in it, which is why granting Contributor at subscription scope "just to unblock someone" is so hard to walk back.

Managed identity is the feature to lead with. An Azure resource gets an Entra identity automatically, so code authenticates to other services with no secret stored anywhere — no connection string, nothing to rotate, nothing to leak.

Conditional Access is where real-world security lives. Policies grant or block based on user, device compliance, location and risk — require MFA from outside the corporate network, block legacy authentication, require a managed device for administrators.

PIM makes admin roles temporary. Instead of standing Owner access, a user activates the role for a few hours with approval and justification, and it expires. That removes the permanently privileged account, which is what attackers look for.

Deny assignments exist but are rare — you cannot usually create them directly; they come from Azure Blueprints and managed applications. So unlike AWS IAM, an explicit deny is not the everyday tool.

Service principals versus managed identities. A service principal is an app identity with a secret or certificate you manage. A managed identity is one Azure manages for you. Prefer managed identity whenever the caller runs in Azure; use workload identity federation for GitHub Actions and other external callers so no secret is stored there either.

Least privilege in practice. Built-in roles at the narrowest scope, groups rather than individuals, and a review of who holds Owner.

What the interviewer is probing.1. "What is a managed identity and what problem does it remove?" Probing: the headline feature. Stalls: "An account for a service." Moves up: an Entra identity the platform manages for a resource, so code authenticates with no secret stored anywhere and nothing to rotate.

2. "At what scopes can a role be assigned?" Probing: inheritance. Stalls: "On the resource." Moves up: management group, subscription, resource group or resource — and it inherits downward, which is why Contributor at subscription scope is hard to walk back.

3. "What does Conditional Access add over RBAC?" Probing: the two layers. Stalls: "The same thing." Moves up: RBAC decides what an identity may do; Conditional Access decides whether to let them authenticate at all, based on device, location and risk.

4. "How do you avoid standing administrator access?" Probing: PIM. Stalls: "Only trust the right people." Moves up: Privileged Identity Management — roles are activated just in time with approval and expire, so there is no permanently privileged account.