Microsoft Entra ID & Role-Based Access Control

AWS Fundamentals Chapter 2 covered IAM — users, groups, roles, and policies, scoped per AWS account. Azure's own identity system is genuinely shaped differently from the very foundation up, and this chapter covers exactly how.

Microsoft Entra ID: Real Origin & Rename

Microsoft's own identity service launched 27 October 2008 as Azure Active Directory (Azure AD) — the same real month Azure itself was first announced (Chapter 1). Microsoft renamed it Microsoft Entra ID, announced 11 July 2023 and effective 15 July 2023, as part of a real, broader push to bring naming consistency across Microsoft's own cloud product line.

A Real Structural Difference From AWS IAM

The Real RBAC Scope Hierarchy

Azure's role-based access control (RBAC) applies permissions at a real, nested scope, with each level inheriting downward:

• Management Group — the broadest real scope, grouping multiple subscriptions together.
• Subscription — a billing and access boundary, roughly analogous to an AWS account.
• Resource Group — Chapter 1's own real, mandatory grouping construct.
• Resource — an individual real resource (a VM, a storage account).

A role granted at a higher level (say, a Resource Group) automatically applies to everything inside it — every resource in that group — unless overridden more narrowly at a lower level. This is a genuinely different default than AWS IAM's own flatter model, where a policy attaches directly to a specific identity rather than inheriting down a real, nested scope tree.

Real Built-in Roles

The real, meaningful distinction between Owner and Contributor — the ability to grant access to other identities — is exactly the kind of narrow, deliberate permission split least privilege (introduced in AWS Fundamentals Chapter 2) calls for: most real day-to-day work needs Contributor, not Owner.

Role Assignments

A real Azure role assignment combines exactly three things: a role definition (what's allowed — e.g. Reader), a security principal (who — a user, group, or Managed Identity), and a scope (where — a Management Group, Subscription, Resource Group, or single Resource). This maps conceptually onto AWS's own Policy + Identity + Resource model, but structured through Azure's own real, hierarchical scope system instead of AWS's flatter policy-attachment approach.

Managed Identities

Azure's real, direct equivalent of AWS's own IAM roles for services (Chapter 3 of AWS Fundamentals) is the Managed Identity — an identity Azure automatically creates and manages for a resource (a VM, a Function App), with no credentials for you to store, rotate, or leak at all. A system-assigned Managed Identity is tied to one specific resource's own lifecycle (deleted when the resource is); a user-assigned Managed Identity exists independently and can be attached to multiple resources at once.

A Real, Recent Case Study: The 2025 Entra ID Vulnerability

This is a real, current illustration of why identity — not any individual resource — sits at the real center of cloud security: a flaw in the identity layer itself has the potential to undermine every other real access control covered in this chapter, regardless of how carefully RBAC scopes and role assignments are otherwise configured.

AWS IAM vs. Azure RBAC

Hands-On Exercises