Building a Mental Model for Azure IAM (Without Losing Your Mind)

Of all the cloud providers I have used, I have to admit that Azure has the best interface and at the same time the worst experience for how long you have to wait especially when you are authenticating.

Its Identity and Access Management (IAM) model is also arguably the most difficult to reason about among the major hyperscalers. A bit of context explains why. Azure was built with enterprise customers in mind from day one. Microsoft has an entire ecosystem of tightly integrated products, and Azure sits inside that ecosystem.

That is great for large organisations that want centralised control. It is less great when you just want to get something done and do not care about Entra ID.

This article builds a mental model that makes Azure predictable.

Case Study

You are a platform engineer at Acme Corp. You have been tasked with provisioning a Kubernetes cluster with the following requirements: The cluster runs inside a private subnet within a VNet

• It pulls images from Azure Container Registry (ACR) via a private endpoint
• It accesses Azure Key Vault securely
• It exposes traffic only through a gateway
• You have been assigned the Contributor role on a resource group: rg-acme-web-product

We will focus on provisioning and IAM, not Kubernetes internals.

How Do You Provision Infrastructure on Azure?

Azure provides multiple ways to interact with its infrastructure. These methods build on top of each other.

1. Azure Portal

This is the simplest and easiest way to access Azure cloud resources. You can simply visit https://azure.microsoft.com. Click on the Get started with Azure button, follow the prompt to create an account. Once your account has been created, you visit https://portal.azure.com, provide the same credentials used to register to gain access to your new cloud account. This process is straightforward until you have to deal with Microsoft Entra ID. We will talk about Entra ID later.

Azure PowerShell & Azure CLI:

These are both CLI apps that allow you to authenticate and create cloud resources on Azure cloud. For example you can create a VM successfully with Azure powershell using this command:

New-AzVm -ResourceGroupName "myResourceGroup" -Name "myVM" -Location "EastUS" -Image "Win2019Datacenter"

or with Azure CLI using the command:

az vm create \
  --resource-group MyResourceGroup \
  --name MyWindowsVM \
  --image Win2022AzureEditionCore \
  --admin-username azureuser \
  --admin-password YourSecurePassword123

Before any command works, you must authenticate. This step becomes important later.

3. SDKs

This should probably not exist on its own but I believe it is worth being mentioned. Essentially, platform and programming language specific libraries have been built around the Azure cloud resources to make it easy to natively work with Azure cloud resources from any platform or programming language. Most SDKs are built in such a way that it interacts directly with the REST API infrastructure that powers the Azure Portal. It achieves this either via integration with installed CLI or programmatically via code. You can find some examples here: Azure SDKs

4. REST API

Everything in Azure is ultimately exposed via HTTP APIs. Any tool capable of making HTTP requests can interact with Azure. This is because all Azure cloud resources like VMs, Object Storage(Blob storage), Virtual Networks all maintain a dedicated provider responsible for taking a request with the specific metadata and creating the resource you requested. I know it sounds confusing right now but what I just mentioned is where things start getting interesting and it will be clear soon.

In summary, you need a way to interact with the actual infrastructure present in Microsoft data center and Microsoft has built an entire backend system around managing and provisioning these infrastructure, not just managing and provisioning but also implementing granular access control to those resources.

What Actually Happens When You Create a Resource?

You have seen methods in which you can “instruct” the Azure Cloud backbone to provision your resources, but what actually happens behind the scenes.

You may be wondering why it is necessary to understand what happens behind the scenes when you submit all the necessary metadata to create a resource on Azure. If you understand how it works, it will make it easy for you to understand where the full IAM falls into, especially roles and permissions.

At this point, you are not creating infrastructure directly. You are sending a request to Azure’s control plane - Azure Resource Manager.

Let’s slow this down and peel it layer by layer because understanding this is key to understanding IAM.

The invisible backbone: Azure Resource Manager (ARM)

Every request, whether from the Portal, CLI, SDK, or Terraform, goes through Azure Resource Manager (ARM). Think of ARM as the control plane of Azure. It is not a UI, not a CLI, not a tool. It is the backend system that receives your request and decides what to do with it.

When you run a command like az vm create or or click Create VM in the portal, ARM is doing the actual work. What actually happens is: ARM is the one doing the heavy lifting:

• Validating your request
• Checking your permissions
• Routing the request to the correct service

Resource Providers: Where Things Are Created

Each Azure service is backed by a Resource Provider. Examples:

• Microsoft.Compute → Virtual Machines
• Microsoft.Network → VNets, Subnets
• Microsoft.ContainerService → AKS
• Microsoft.ContainerRegistry → ACR When you run a command like az vm create or or click Create VM in the portal, remember that everything is essentially a HTTP request to Azure Resource Manager. The request could look something conceptually like so

https://management.azure.com/resource/create
Auth="Bearer <token-from-entra-id>

# Request Body
{
    "subscription_id": "xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx",
    "resource_group": "rg-my-resource-group",
    "resource_type" "virtual_machine",
    "handler": "Microsoft.Compute/virtualMachines",
    "resource_name": "my-virtual-machine"
}

ARM inspect the request and goes “Okay, this is a Compute request, let me pass this to Microsoft.Compute”

But before ARM hands your request to the corresponding provider, it performs a few but extremely important actions and that is where IAM enters the picture

Where IAM Enters the Picture

ARM does not just provision resources. It also enforces access control. The key question ARM answers is:

Can this identity perform this action on this resource at this scope?

Identity being a unique identifier(ObjectID) extracted from token given to CLI/Portal/SDK/REST Client by Microsoft Entra ID But how does ARM

• Ask this question
• Get the answers it needs to allow/deny access to the resource you are trying to resource you are accessing

That’s where the next section comes in

Azure RBAC: Roles and Permissions

Azure RBAC is a built in component of Azure Resource Manager. Its function is to provide answer to the question:

Can this identity perform this action on this resource at this scope?

What is inside a Role?

A role is not magic. It is just a structured list of permissions. Here is an example of Microsoft Contributor Role for Azure

{
  "assignableScopes": ["/"],
  "description": "Grants full access to manage all resources, but does not allow you to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries.",
  "id": "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c",
  "name": "b24988ac-6180-42a0-ab88-20f7382dd24c",
  "permissions": [
    {
      "actions": ["*"],
      "notActions": [
        "Microsoft.Authorization/*/Delete",
        "Microsoft.Authorization/*/Write",
        "Microsoft.Authorization/elevateAccess/Action",
        "Microsoft.Blueprint/blueprintAssignments/write",
        "Microsoft.Blueprint/blueprintAssignments/delete",
        "Microsoft.Compute/galleries/share/action",
        "Microsoft.Purview/consents/write",
        "Microsoft.Purview/consents/delete",
        "Microsoft.Resources/deploymentStacks/manageDenySetting/action",
        "Microsoft.Subscription/cancel/action",
        "Microsoft.Subscription/enable/action"
      ],
      "dataActions": [],
      "notDataActions": []
    }
  ],
  "roleName": "Contributor",
  "roleType": "BuiltInRole",
  "type": "Microsoft.Authorization/roleDefinitions"
}

You can see more built-in roles for Azure here

The Contributor role allows you to create and manage resources but prevents you from assigning roles. Which translates to: “You can do everything… except anything related to access control” In practical terms:

• You can create VMs ✅
• You can create AKS ✅
• You can create VNets ✅
• You cannot assign roles ❌

How Azure RBAC actually works during a request

Let’s connect everything together. When you send a request:

Auth: Bearer <token>
Resource: Microsoft.Compute/virtualMachines
Action: write
Scope: /subscriptions/xxx/resourceGroups/yyy

ARM does the following:

1. Validates your token
2. Extracts your identity (user ID)
3. Looks up all role assignments tied to you
4. Evaluates:
   • does your role allow this action?
   • at this scope?

If yes✅ → request continues

If no❌ → request is rejected

But Who Gave You That Role?

At this point, a very natural question comes up:

If Azure RBAC is validating my role… who assigned me that role and where is it checked against?

This is where things connect.

Enter Microsoft Entra ID (formerly Azure AD)

Everything starts here.

Microsoft Entra ID is a cloud based Identity solution that supports all the modern authentication systems.

That was a very generic definition, something you can easily read from any of Microsoft’s documentation.

Here is a better one.

You remember at the beginning of this article, I mentioned that Microsoft and Azure catered for enterprise clients from the onset, Entra is a general interface used to administer what everyone across the organisation can do.

Because Azure is one of the many products Microsoft owns, they also own Teams, Office 365, Microsoft CoPilot 365, Windows Desktop, Windows Server, Azure and many more.

It would not make sense that each of their products has a separate method of identifying who you are(Authentication) and also checking for what you are allowed to do(Authorisation) on each of these Apps.

So they built Microsoft Entra ID(formerly called Azure AD).

Everything done in Azure Cloud starts with identity.

Microsoft Entra ID is the central identity system across Microsoft products.

It is where:

• Users are created
• Authentication happens
• Organisational access is managed

Azure does not manage identity independently. It relies on Entra ID.

What is Entra ID used for and how is it related to Azure Cloud.

Entra ID is a hosted cloud authentication system owned by a specific organisation. The actual domain is accessed via entra.microsoft.com. Usually a central administrator will be responsible for it. They login with their Global Administrator credentials and they have access to the interface below:

When a new person is hired, this interface is where their credentials will be created, their email and password, they can also be assigned to a group, given a role(a non Azure role), this role is not to be confused with the Azure Roles which we have been talking about. The role here is the ones required for accessing apps like Windows, Teams or Office 365 apps. Because there is about a 90% chance that your first real introduction to Building production ready apps on Azure cloud is for an organisation, it makes sense that you should know what Entra ID is and what it is used for. You can watch this video to have a better understand of the interface and what happen in Entra ID: youtu.be/PG0eBWvzaHY

How does it relate to Azure Cloud

Entra ID is the global point-of-view for everything Identity across all Microsoft Products and Azure is one of those products. This means that when you join a new organisation and you are handed your azure cloud credentials which you use to authenticate via any of the means listed above.

You might be tempted to assume that you are authenticating against a separate backend system for Azure Portal, you are in fact authenticating against Microsoft Entra ID. Entra ID is the authoritative Authentication system across all Microsoft’s products including Azure Cloud.

So assuming you head on to Azure Portal and provide your email and password, possibly pass through some Multi-Factor-Authentication system. Once your access is accepted or rejected, it means that your credentials were checked against your organisation’s Entra ID and you were found or not found. Once you learn these, you then understand who to reach out to when an authentication issue related to your Azure cloud account comes up.

Remember, we are still trying to answer the question: who gave me this role? After your account has been created on Entra ID of your organisation, you are then assigned a role. I briefly mentioned that the Global Administrator of your Organisation’s Entra account can also give you a role

The role you can possibly be assigned on the Entra Interface has nothing to do with Azure cloud. Azure Cloud has a built in and focused set of roles and permission encoded in a “module” called Azure RBAC, which is built into the Azure Resource Manager(The control plane of Azure cloud resources).

There are 3 Major roles you can have:

1. Owner: access to all resources including assigning someone else or a service(AKS, ACR etc) a role
2. Contributor: You have access to everything an Owner has except anything related to assigning roles to users or services
3. Reader: a role for only seeing resources that exists in your Azure Cloud account but to not make any modifications(create, edit or delete)

Azure roles are scoped at different levels:

1. Management groups
2. Subscriptions
3. Resource groups
4. Resources.

The statement above is important because it answer the question about who can assign another person a role, specifically the roles required to access Azure Cloud resources(not the Entra ID roles needed to access Teams or Office 365)

Because roles in Azure are scoped and there is a hierarchy involved, it means that a role scoped to a higher hierarchy has broader access.

See this diagram for reference:

If you are given an Owner role at the Management Group level, it means you can perform all the duties available to that type of role in your management group, all subscription in your management groups, all resource groups across all the subscriptions under your management groups and all the resources in all the resource groups across all the subscriptions in your management group

Separation of Concerns

This distinction is critical:

• Entra ID → who you are (identity)
• ARM → accepts your request to create resource(gatekeeper)
• Azure RBAC → what you can do (permissions)

Three separate systems working together.

Back to the Case Study

Let us walk through your scenario at Acme Corp.

Step 1: Identity Creation

An Entra administrator creates your account:

[email protected]

At this stage, you exist but have no permissions.

Step 2: Role Assignment

Now comes someone else (or sometimes the same person with enough privileges):

• Azure Admin (Owner / RBAC Admin) An Azure administrator assigns you: They go into:

Azure Portal → Subscription → Access Control (IAM)

And assign:

Role: Contributor
Scope: Resource Group(name=rg-acme-web-product)
Principal: [email protected]

Now you can operate within that scope.

Full Request Flow

1. You log in → Entra authenticates you
2. Entra gives you a token
3. You send a request to ARM
4. ARM checks RBAC
5. RBAC validates your role (Contributor) + permissions
6. ARM allows(forwards to resource provider) or denies request(sends an error response to the client - Portal/CLI/Terraform/SDK)
6. The resource provider executes the request(if ARM allowed)

What if you are NOT in an organization?

This is where things get interesting.

If you are trying to study and understand Azure cloud for yourself maybe as a way to upskill or add more cloud platforms to your toolbelt as cloud, devops or platform engineer. You might have noticed that you could just create an Azure account, and you never set up Entra ID

Even personal Azure accounts use Entra ID. Azure creates a hidden tenant for you and assigns you the Owner role. It feels like IAM does not exist, but it does. It is just abstracted away.

So the flow remains the same even if you create a “standalone” Azure cloud account

Personal account scenario

When you sign up with:

• Gmail
• Outlook
• Microsoft account

Azure does this:

Create hidden Entra tenant
↓
Create your identity inside it
↓
Assign you Owner role

Why you don’t notice it

Because:

• you are the only user
• you are already Owner
• no need to manage users/groups

So it feels like “No IAM exists”

But it does.

Key Takeaways

• You cannot use Azure without Entra ID
• Identity and permissions are separate concerns
• ARM is the control plane
• Resource providers create resources

Bringing it all together

Let’s tie everything back to your original goal: You are trying to:

• provision AKS
• connect to ACR
• access Key Vault securely

Now you understand:

• how requests are sent
• how they are validated
• how permissions are enforced
• where identity comes from

Final Summary

Let’s walk the entire flow one last time:

1. Identity (Entra ID)
  - You exist as a user

2. Authentication
  - You login → get token

3. Control Plane (ARM)
  - Receives your request
  - Validates permissions

3. Authorization (Azure RBAC)
  - Your role defines what you can do

5. Resource Provider
  - Executes the request

6. Resource created

Final thought

Azure IAM feels complex at first because it is built for enterprise-scale control, not speed. But once you understand:

• identity vs permission
• Entra vs RBAC
• ARM vs resource providers

Everything becomes predictable.