☁️ Azure & Entra ID: Guide to Identities, Hierarchy and AI Foundry

Technical preparation guide focused on architecture, security models in Microsoft Entra ID (formerly Azure AD), resource management in Azure, governance, deployment of AI loads in Azure AI Foundry, and direct equivalencies for engineers from Amazon Web Services (AWS).

01. Entra vs Azure: Separate Control Planes

Although both environments are managed from the same portal (portal.azure.com), they correspond to two independent permission systems that operate in completely isolated layers.

Building Analogy: Imagine a corporate office building.

Identity & Directory

Microsoft Enter ID

It's reception and HR: validate who you are, what groups you belong to and if you have access to the building. Formerly known as Azure AD.

• Lives at the global level of the Tenant (the organization).

• Manage Users, Groups, App Registrations, Service Principals and Identities.

• Their roles (e.g. Global Administrator, User Administrator) manage the directory, not the cloud resources.

Cloud Resources

Azure (Infra/PaaS Platform)

They are the offices, desks and internal tools: Virtual Machines, Storage Accounts, Datasets, Networks and Databases.

• It is organized through Management Groups, Subscriptions and Resource Groups.

• It is controlled by Azure RBAC (e.g. Owner, Contributor, Reader).

• Permissions are assigned with a Scope (specific scope of application).

🌐 portal.azure.com — Shared gateway

Microsoft Enter ID (Identity Plane)
Azure Resources (Data Plane/Infra)

Being Global Administrator in Entra does not grant permissions to create or modify resources within Azure subscriptions. Likewise, being Owner of an Azure subscription does not allow you to create users or alter the directory in Entra ID. They are two disconnected control planes.

💡 Interview Tip: "Entra answers who are you and can you authenticate?; Azure RBAC answers what specific resources can you manipulate and to what extent?. The only bridge is that Azure RBAC assigns roles on resources to identities defined in Entra."

02. Identity Types in Entra & Azure

The primary goal of modern cloud identity design is to allow applications to authenticate against Azure resources without storing passwords or secrets in the source code.

App Registration vs Service Principal

To grant an application its own identity in Entra ID, two interconnected objects are required:

The Mold / Definition

App Registration

The global definition of the application: its name, credentials (certificates, secrets or federated credentials), API permissions (e.g. Microsoft Graph) and Redirect URIs are specified.

• Resides in a single tenant (the origin tenant / home).

• Location in console: Enter ID > App registrations.

• It is a configuration template (it does not receive roles directly).

The Instance/Subject of Permissions

Service Principal

The local instance of that application in a specific tenant. This is the actual identity that authenticates and receives Azure RBAC assignments.

• Automatically generated when registering the app (or granting access to an external tenant).

• Location in console: Enter ID > Enterprise applications.

• It is the object evaluated by RBAC for infrastructure permits.

💡 Interview Analogy: The App Registration is the manufacturing mold (it is defined only once in the origin tenant); The Principal Service is the concrete sculpture created from the mold in each tenant (the one that occupies space and receives permissions). Therefore, a multi-tenant architecture has 1 App Registration and multiple Service Principals.

Managed Identities & Workload Identity Federation

To avoid manual rotation of secrets or certificates, Azure provides automatic managed identities:

Base Concept

Managed Identity

A Service Principal whose secrets are automatically created, injected, and rotated by the Azure platform. The application code interacts with the local metadata API to obtain tokens.

Usage: Workloads run within Azure without credential management.

Variant A (1:1)

System-assigned

Enabled directly on a resource (VM, App Service, Function). Its life cycle is rigidly coupled to the resource: if the resource is deleted, the identity is destroyed in Enter ID.

Usage: Isolated individual resources that do not share permissions context.

Variant B (N:M)

User-assigned

Created as a standalone resource in Azure. It can be associated with multiple resources simultaneously and persists even if the associated resources are deleted.

Usage: Identical microservices in scale or pre-deployment permission provisioning.

External Integration

Workload Identity Federation

Allows loads outside of Azure (GitHub Actions, AWS, GCP, Kubernetes On-Premise) to authenticate using OIDC. Enter validates the JWT token issued by the third-party provider and delivers an Azure token without using secrets.

Use: CI/CD pipelines and Passwordless multicloud deployments.

03. Resource Hierarchy and Role Inheritance

Azure's organizational structure follows a strictly top-down tree where access and IAM policies are automatically propagated to lower levels.

1. Management Group
Bundle multiple subscriptions. Allows you to apply governance policies (Azure Policy) and corporate RBAC roles.

2. Subscription
Main billing limit, quotas and administrative boundaries. Every resource belongs to a subscription.

3. Resource Group
Logical container that groups resources that share the same life cycle (deployment, update, deletion).

4. Resource
Individual infrastructure instance (VM, Storage Account, AKS Cluster, DB).

↓
Permissions assigned at a higher level are inherited cumulatively to all lower levels and cannot be revoked at subordinate layers.

Service Groups Public Preview

Unlike the rigid vertical hierarchy (Management Group > Subscription > Resource Group), Service Groups are logical groupings at the Tenant level that allow you to create cross-sectional views between different subscriptions.

Vertical Structure

Standard Hierarchy

• Only one parent per resource (strict relationship).

• Designed for Cumulative RBAC and Azure Policy.

• Mandatory inheritance of permissions to resources.

Cross View

Service Groups

• A resource can be part of multiple Service Groups.

• Designed for inventory, observability and logical grouping.

• Permissions are NOT inherited to member resources (respecting the principle of least privilege).

04. Azure AI Foundry: Hub, Projects and Accounts

Azure AI Foundry is the unified development environment for building, testing, and deploying generative AI and machine learning models.

Hub-Project Architecture

🏛️ AI Foundry Hub (Main Resource)

Centralizes private network connections, storage (Storage Account), key managers (Key Vault) and computing capabilities.

AlphaHereda Security & Compute Project
BetaHereda Project Security & Compute
GammaHereda Security & Compute Project

Types of AI Accounts (Kinds)

RBAC Permissions Requirements in AI Foundry

When deploying secure environments with private VNet and restricted access, Azure applies a deny-by-default policy. Because the Hub and Projects are interconnected using Connections (which do not automatically propagate RBAC roles), three identities need to be explicitly authorized:

05. AI Model Deployment Strategies

Azure offers four main approaches to running foundational models, balancing operational complexity with infrastructure control.

Serverless API (Foundry)

Serverless API (Pay-as-you-go)

Consumption of the model as a managed service via REST API. Without machine or GPU management.

• Strict payment per token processed.

• Instant auto-scalability.

• Ideal for loads with variable demand or prototypes.

Managed Compute (Foundry)

Managed Compute (Dedicated Infrastructure)

Deploying model weights to dedicated GPU instances within the subscription, managed by Foundry.

• Fixed payment per reserved GPU hour.

• Complete network isolation within own VNet.

• Required for models in the catalog that do not have a Serverless option.

Self-Managed IaaS

VMs with Dedicated GPUs (NC / ND / NV Series)

Manual provisioning of IaaS instances with NVIDIA GPUs. The engineering team manages the operating system, CUDA drivers, runtime (e.g. vLLM, Ollama, Triton) and the API layer.

• Absolute control: Allows you to run any model or architecture not supported in the catalog.

• Multipurpose: Suitable for heavy fine-tuning, distributed training and HPC processing.

• Operational Load: Full responsibility for patches, high availability and manual scaling.

Business Orchestration

AKS Cluster with GPU Node Pools

Deployed inference servers orchestrated on Kubernetes using Azure Kubernetes Service. Provides declarative deployments, scaling based on custom metrics (KEDA) and balancing between replicas.

• GPU Slicing in AKS:

• Time-Slicing (Software): Software multiplexing for Dev/Test environments or lightweight models. No memory isolation (risk of noisy neighbor).

• MIG / Multi-Instance GPU (Hardware - A100/H100): Physical partitioning of the GPU into up to 7 independent instances with dedicated memory and cores for production.

06. Equivalence Matrix: AWS vs Azure

Direct correspondence table for architects and engineers with previous experience in Amazon Web Services.

📌 Paradigm Shift Summary (AWS → Azure):

1. An Azure Subscription is equivalent to an AWS Account.

1. Resource Groups are required in Azure to manage the lifecycle of resources.

1. The identity plane (Enter ID) is decoupled from the resource management plane (Azure RBAC).