For a senior Azure architect interview, I’d design this as a layered enterprise platform: ingestion → lakehouse → AI/ML → API serving → security/governance → observability. Azure’s current architecture guidance supports combining ADLS, Databricks/data pipelines, private networking, API Management, and Microsoft Foundry/Azure OpenAI for this pattern. (Microsoft Learn)

Reference architecture

                    USERS / APPLICATIONS
                           |
                    Azure Front Door
                     + WAF / DDoS
                           |
                           v
                 +--------------------+
                 | Azure API          |
                 | Management (APIM)  |
                 |--------------------|
                 | Auth / JWT         |
                 | Rate limiting      |
                 | AI gateway         |
                 | Quotas / logging   |
                 +---------+----------+
                           |
              +------------+-------------+
              |                          |
              v                          v
      +---------------+          +----------------+
      | AKS / App     |          | Microsoft      |
      | Services      |          | Foundry /      |
      |---------------|          | Azure OpenAI   |
      | REST APIs     |          |----------------|
      | AI agents     |--------->| GPT / LLM      |
      | Orchestrator  |          | Embeddings     |
      | RAG services  |          | Model inference|
      +-------+-------+          +----------------+
              |
              | Search context
              v
      +--------------------+
      | Azure AI Search    |
      |--------------------|
      | Vector index       |
      | Hybrid search      |
      | Semantic search    |
      +---------+----------+
                ^
                |
              Embeddings
                |
+---------------+------------------------------------------+
|                    DATA / AI PLATFORM                    |
|                                                          |
|        Azure Databricks / Spark                          |
|     +------------------------------------+               |
|     | Data cleaning / transformation     |               |
|     | Feature engineering                |               |
|     | ML training                        |               |
|     | Embedding generation               |               |
|     | Batch / streaming processing       |               |
|     | MLflow / model lifecycle           |               |
|     +-----------------+------------------+               |
|                       |                                  |
|                 Delta / Lakehouse                        |
|                       |                                  |
|                       v                                  |
|             +---------------------+                      |
|             | ADLS Gen2           |                      |
|             |---------------------|                      |
|             | Bronze - Raw        |                      |
|             | Silver - Clean      |                      |
|             | Gold - Curated      |                      |
|             | ML datasets         |                      |
|             | Documents           |                      |
|             +---------------------+                      |
+----------------------------------------------------------+
                       ^
                       |
             INGESTION / PIPELINES
                       |
        +--------------+---------------+
        |                              |
 Azure Data Factory               Event Hubs
 / Fabric Data Factory            / streaming
        |                              |
        +--------------+---------------+
                       |
       +---------------+------------------+
       |               |                  |
   Databases         APIs              Files
   SQL/Oracle        SaaS          CSV/JSON/PDF
       |
   On-premises
   systems

ADLS Gen2 gives you the scalable storage foundation for analytics and AI, while Databricks can provide Spark processing, Delta Lake/lakehouse processing and ML workflows. Microsoft recommends Unity Catalog as the modern Databricks governance/access pattern for storage rather than older direct-access configurations. (Microsoft Learn)

1. Data lake and pipelines

I would make ADLS Gen2 the system of record and divide it into:

Bronze
   ↓
Raw source data
   ↓
Silver
   ↓
Validated / cleaned / standardized
   ↓
Gold
   ↓
Business-ready / ML-ready datasets

Data arrives through Azure Data Factory for batch ingestion and Event Hubs for streaming workloads. ADF is designed to create and schedule data-driven ingestion and transformation workflows across different data stores. (Microsoft Learn)

For heavy transformation:

ADF
 |
 +----> Databricks Jobs
           |
           +--> Spark
           +--> Delta Lake
           +--> Feature engineering
           +--> ML pipelines

2. AI model layer

I would support two types of models.

For foundation models:

Microsoft Foundry
      |
Azure OpenAI / Foundry models
      |
+-----+-----+
|           |
GPT/LLM   Embeddings

For custom ML models:

ADLS
  |
Databricks
  |
Training
  |
MLflow
  |
Model registry
  |
Deployment
  |
AKS / managed inference endpoint

This separation is useful because I don’t want to run a GPT-class foundation model myself unless there is a strong requirement. Managed Foundry models handle that side, while proprietary classifiers, forecasting models and specialized models can follow a traditional MLOps lifecycle.

3. RAG architecture

For enterprise GenAI, I’d normally add Azure AI Search.

                   Offline pipeline

Documents
   |
ADLS
   |
Databricks / AI Search ingestion
   |
Chunk documents
   |
Generate embeddings
   |
Azure AI Search
Vector index


                    Runtime

User
 |
 v
APIM
 |
 v
AKS AI API
 |
 +---- query ----> Azure AI Search
 |                     |
 |                  Relevant
 |                  documents
 |                     |
 +<--------------------+
 |
 | Prompt + context
 v
Azure OpenAI
 |
 v
Grounded answer

Azure AI Search can provide integrated vectorization and retrieval for Azure OpenAI RAG workloads, reducing the amount of custom embedding/indexing code required in some designs.

4. API architecture

I would not expose the model endpoint directly.

Instead:

Client
  |
Front Door/WAF
  |
APIM
  |
AI orchestration API
  |
+-------+---------+---------+
|       |         |         |
GPT   Search   Databricks  Business
                     APIs

APIM becomes the enterprise control point for:

• OAuth2/OIDC and Microsoft Entra ID authentication
• JWT validation
• throttling and quotas
• request/response policies
• API versioning
• usage/cost controls
• model routing
• observability

Microsoft now specifically documents APIM as a gateway in front of Foundry/Azure OpenAI workloads for centralized routing, load balancing, throttling and observability. (Microsoft Learn)

For multiple model deployments, APIM can also use backend pools to distribute requests across several backends. (Microsoft Learn)

5. AKS application layer

For an enterprise deployment I’d use:

AKS
|
+-- System Node Pool
|
+-- API Node Pool
|     |
|     +-- REST APIs
|     +-- AI orchestration
|     +-- RAG services
|
+-- ML Node Pool
      |
      +-- Custom inference
      +-- GPU workloads if required

Then use:

HPA
 |
Pod scaling
Cluster Autoscaler
 |
Node scaling

The Azure Architecture Center maintains a dedicated baseline AKS architecture specifically for production infrastructure design. (Microsoft Learn)

6. Enterprise networking

This is where I would spend significant interview time.

                    Azure Landing Zone

                      HUB VNET
                 +----------------+
On-Prem -------->| ExpressRoute   |
                 | Azure Firewall |
                 | DNS Resolver   |
                 +-------+--------+
                         |
                  VNet Peering
                         |
               +---------+----------+
               |    AI Spoke VNet   |
               |                    |
               | AKS                |
               | APIM               |
               | Private Endpoints  |
               +---------+----------+
                         |
              Private Link only
                         |
        +----------------+----------------+
        |                |                |
       ADLS          Azure OpenAI      AI Search
        |                |                |
     Private           Private          Private
     Endpoint          Endpoint         Endpoint

For regulated environments, I would disable public access where supported and use Private Link/private endpoints for PaaS resources. Private endpoints assign a private VNet IP to reach the service rather than traversing a public endpoint. (Microsoft Learn)

Private DNS is critical:

AKS
 |
DNS query
 |
Azure DNS Private Resolver
 |
Private DNS Zone
 |
Private Endpoint IP
 |
Azure OpenAI / ADLS / AI Search

Microsoft’s Foundry landing-zone architecture explicitly uses private DNS zones to resolve private endpoints securely from workload networks. (Microsoft Learn)

7. Identity and secrets

Avoid credentials in applications.

Pod
 |
AKS Workload Identity
 |
Microsoft Entra ID
 |
+----------+----------+----------+
|          |          |          |
ADLS    Key Vault  AI Search  Azure OpenAI

Use:

Microsoft Entra ID → managed identities/workload identity → Azure RBAC

rather than embedding storage keys or model API keys inside Kubernetes Secrets whenever possible.

Key Vault stores unavoidable secrets, certificates and keys.

8. Governance

For a banking/regulated enterprise I’d add:

Microsoft Purview
      |
Data classification
Lineage
Sensitive-data discovery
Governance
Azure Policy
      |
Landing-zone guardrails
Private endpoints required
Allowed regions
Allowed SKUs
Databricks Unity Catalog
      |
Tables
Files
Models
Permissions
Lineage

9. Observability

The entire stack feeds centralized monitoring:

AKS
Azure OpenAI
APIM
Databricks
AI Search
ADF
   |
   v
Azure Monitor
   |
Log Analytics
   |
Application Insights
   |
Microsoft Sentinel

For AI specifically, capture:

Model latency
Token consumption
HTTP 429s
Model errors
APIM latency
Retrieval latency
Prompt/response safety signals
Cost per application
Model quality

Microsoft provides an architecture specifically for advanced monitoring of Foundry/Azure OpenAI models through a gateway.

10. CI/CD + MLOps

I’d separate application, infrastructure, data and model deployment pipelines:

GitHub / Azure DevOps
        |
        +---- Terraform/Bicep
        |        |
        |      Azure Infrastructure
        |
        +---- App CI/CD
        |        |
        |       ACR
        |        |
        |       AKS
        |
        +---- DataOps
        |        |
        |    Databricks / ADF
        |
        +---- MLOps
                 |
              Training
                 |
              MLflow
                 |
             Validation
                 |
             Registry
                 |
             Deployment

The interview answer I’d memorize

If the interviewer asks:

“Design an Azure architecture to host AI models, APIs, a data lake and supporting pipelines.”

You can answer:

“I’d build the platform around ADLS Gen2 as the enterprise data lake, with Data Factory and Event Hubs handling batch and streaming ingestion. Databricks would provide the lakehouse, Spark transformations, ML training and model lifecycle capabilities. For generative AI I’d use Microsoft Foundry/Azure OpenAI and Azure AI Search for RAG and vector retrieval.

Application and AI orchestration APIs would run on AKS and be exposed through Azure API Management, which provides authentication, throttling, model routing and API governance.

From a security perspective I’d deploy the platform into an Azure landing-zone hub-and-spoke architecture, use private endpoints for ADLS, AI Search and model services, use Entra ID and workload identities instead of static credentials, and Key Vault where secrets are unavoidable.

Finally, I’d use Azure Monitor, Log Analytics, Application Insights and Sentinel for centralized observability, with Terraform and CI/CD pipelines managing infrastructure and application deployments.”

That’s approximately a 90-second architect-level answer, while still giving the interviewer several areas—AKS, networking, AI, data, security and MLOps—to drill into. (Microsoft Learn)

For an enterprise Azure analytics platform, I would use a polyglot data architecture: each storage technology handles the workload it is best suited for, while ADLS Gen2 becomes the central analytical system of record. Microsoft’s current guidance supports ADLS-based medallion/lakehouse architectures and emphasizes storage layout, file formats, partitioning, and parallelism for analytical performance. (Microsoft Learn)

Reference architecture

                         DATA SOURCES
                              |
       +----------------------+----------------------+
       |                      |                      |
   Applications          Enterprise DBs        Files / APIs
       |                      |                      |
       v                      v                      v
   Cosmos DB              Azure SQL /           ADF / Event
 operational DB            SQL Server             Hubs
       |                      |                      |
       +----------------------+----------------------+
                              |
                              v
                    Azure Data Factory
                  / Event Hubs / Databricks
                              |
                              v
              +--------------------------------+
              | Azure Blob / ADLS Gen2         |
              |                                |
              |  BRONZE - Raw                  |
              |  SILVER - Cleaned              |
              |  GOLD   - Curated              |
              +---------------+----------------+
                              |
                         Delta / Parquet
                              |
                    Azure Databricks
                         Spark / SQL
                              |
               +--------------+-------------+
               |                            |
               v                            v
        Azure SQL DB /                 AI / ML
        SQL serving layer              workloads
               |
               v
        Power BI / APIs /
        Analytics applications

Azure Data Factory can directly copy and transform data into ADLS Gen2, making it appropriate as the orchestration and ingestion layer. (Microsoft Learn)

1. Azure Blob Storage / ADLS Gen2

This should contain the largest volume of analytical data.

Conceptually:

Storage Account
│
├── bronze/
│     ├── cosmos/
│     ├── sql/
│     ├── api/
│     └── documents/
│
├── silver/
│     ├── customers/
│     ├── transactions/
│     └── products/
│
└── gold/
      ├── customer_360/
      ├── revenue/
      ├── risk/
      └── ai_training/

I would normally enable the hierarchical namespace, effectively using Azure Data Lake Storage Gen2 capabilities on Azure Blob Storage. ADLS Gen2 is designed for large-scale analytical workloads. (Microsoft Learn)

Bronze — immutable/raw

Keep data as close to the source as possible:

Cosmos JSON
SQL extracts
CSV
JSON
Avro
application logs
documents

Example:

/bronze/cosmos/orders/year=2026/month=08/day=11/
/bronze/sql/customer/year=2026/month=08/day=11/

Do not let consumers directly modify Bronze.

2. Silver — analytical processing

Databricks transforms Bronze into standardized datasets:

Bronze
   |
   v
Azure Databricks
   |
   +-- schema enforcement
   +-- data cleaning
   +-- deduplication
   +-- joins
   +-- standardization
   +-- quality checks
   +-- PII handling
   |
   v
Silver

For example:

bronze:
customer JSON + transactions + CRM
             ↓
silver:
Customer
Transaction
Account
Product

I’d generally use Delta Lake/Parquet rather than CSV for analytical datasets. A lakehouse architecture combines scalable object storage with data-management and warehouse-style capabilities. (Microsoft Learn)

3. Gold — business-ready analytics

Gold contains datasets optimized for consumption rather than raw ingestion.

Silver
   |
   +----------+
   |          |
   v          v
Customer360  SalesMetrics
   |          |
   +----+-----+
        |
       GOLD

Example:

/gold/customer360/
/gold/monthly_revenue/
/gold/risk_analysis/
/gold/executive_reporting/

The Gold layer can then feed:

Power BI
Azure SQL
APIs
Databricks SQL
Machine learning
AI/RAG

This Bronze → Silver → Gold medallion structure is a common Azure lakehouse design; Microsoft’s architecture guidance also shows ADF ingestion, Databricks processing and Azure SQL as a downstream serving store. (Microsoft Learn)

4. Where Cosmos DB fits

This distinction matters in interviews:

Cosmos DB should generally not become your primary enterprise data lake.

Use Cosmos DB for:

High transaction volume
        +
Low-latency access
        +
Semi-structured JSON
        +
Global distribution
        +
Application operational data

Example:

{
  "customerId": "C10001",
  "eventType": "purchase",
  "productId": "P889",
  "amount": 142.75,
  "timestamp": "2026-08-11T18:05:03"
}

An application might use:

Web/Mobile App
       |
       v
     API
       |
       v
   Cosmos DB
 latency: milliseconds

Analytics should normally be separated:

        OLTP                        Analytics

Application
     |
     v
 Cosmos DB
     |
     +---------------------> Analytics platform
                              |
                              v
                         ADLS/Lakehouse

That prevents heavy analytical queries from competing with production application traffic.

5. Cosmos DB analytics: an important current change

This is worth knowing for a 2026 interview.

Historically, you would often hear:

Cosmos DB
    |
Analytical Store
    |
Synapse Link
    |
Synapse Analytics

But Microsoft now states that Azure Synapse Link for Cosmos DB isn’t supported for new projects and recommends Azure Cosmos DB Mirroring for Microsoft Fabric for new implementations. (Microsoft Learn)

So for a new Fabric-centric design:

Cosmos DB
    |
    | zero-ETL mirroring
    v
Microsoft Fabric
    |
OneLake
    |
Analytics / Power BI

For an existing estate that already uses Synapse Link, analytical store can still separate analytical access from the transactional workload and provide near-real-time analytical data without traditional ETL. (Microsoft Learn)

That’s a very useful distinction to make in an interview because many older architecture diagrams still recommend Synapse Link as the default for new solutions.

6. Where Azure SQL fits

I would use Azure SQL primarily for structured relational workloads and analytical serving, rather than storing petabytes of raw lake data.

For example:

                   ADLS Gold
                      |
                  Databricks
                      |
                      v
                  Azure SQL
                 Serving DB
                      |
             +--------+--------+
             |                 |
          Power BI            APIs

Azure SQL could contain:

DimCustomer
DimProduct
DimDate
FactSales
FactOrders
FactRevenue

Conceptually:

              FactSales
                  |
          +-------+-------+
          |       |       |
     Customer  Product   Date

That structure works well when consumers expect SQL semantics, relational joins, predictable schemas and conventional BI integration.

Microsoft’s medallion reference architecture explicitly describes Azure SQL as a persisted downstream serving store after ADF ingestion and Databricks processing. (Microsoft Learn)

7. Don’t query operational SQL for every report

This is an important architecture rule.

Avoid:

Power BI
   |
   v
Production Azure SQL

when complex BI queries could impact application traffic.

Instead:

Production SQL
      |
      | CDC / incremental ingestion
      v
     ADF
      |
      v
ADLS Bronze
      |
Databricks
      |
ADLS Gold
      |
      +----> BI serving layer
      |
      +----> Power BI

This creates separation between:

OLTP

many small
INSERT/UPDATE/SELECT

and OLAP

SELECT SUM(...)
FROM billions_of_rows
GROUP BY ...

8. File format optimization

For analytics, the storage format matters considerably.

I would prefer:

RAW
CSV / JSON / original source
          |
          v
       Bronze
              transform
                 ↓
Silver / Gold
Parquet / Delta

Why?

Parquet is column-oriented.

Imagine:

customer_id
name
country
age
salary
transaction_total

If a query needs only:

SELECT country, SUM(transaction_total)
FROM sales
GROUP BY country;

a columnar format can avoid unnecessarily reading all unrelated columns.

ADLS performance guidance emphasizes that file format, file size and directory structure affect both performance and cost, and recommends parallelizing ingestion and access. (Microsoft Learn)

9. Partitioning

Don’t create:

/data/everything.parquet

and don’t create millions of tiny files either.

Use useful business/query partitions:

/sales/
    year=2026/
       month=08/
          day=11/
             part-00001.parquet
             part-00002.parquet

Then:

WHERE year = 2026
AND month = 8

allows the processing engine to avoid scanning irrelevant partitions.

Possible partition keys:

date
region
source_system
business_domain

But avoid partitioning on very high-cardinality fields such as:

customer_id
transaction_id
GUID

because that can create a huge number of directories/files.

10. Handle the small-file problem

An enterprise ingestion system can easily produce:

10 million × 10 KB JSON files

which is inefficient for analytical processing.

I’d periodically compact them:

10,000 tiny files
       ↓
Databricks
       ↓
10–100 appropriately sized
Parquet / Delta files

Microsoft’s ADLS guidance notes that larger files generally provide better analytical performance and lower transaction overhead compared with large numbers of tiny files. (Microsoft Learn)

11. Data flow between the three storage systems

A good architecture might look like this:

                  OPERATIONAL SYSTEMS

              ┌──────────────────┐
              │    Cosmos DB     │
              │ JSON/events      │
              └────────┬─────────┘
                       |
                       |
┌─────────────┐        |         ┌─────────────┐
│ Azure SQL   │        |         │ APIs/Files  │
│ OLTP        │        |         │ SaaS        │
└──────┬──────┘        |         └──────┬──────┘
       |               |                |
       +---------------+----------------+
                       |
                ADF / Streaming
                       |
                       v
             ┌─────────────────────┐
             │ Azure Blob/ADLS G2  │
             │                     │
             │ BRONZE              │
             │ SILVER              │
             │ GOLD                │
             └──────────┬──────────┘
                        |
                   Databricks
                 Spark / Delta
                        |
           +------------+------------+
           |                         |
           v                         v
      Azure SQL                  AI / ML
   analytical serving            Models
           |
           v
        Power BI

12. Security architecture

For an enterprise deployment:

                Azure Landing Zone
                       |
                     VNet
                       |
              Private Endpoints
                       |
       +---------------+---------------+
       |               |               |
      ADLS          Cosmos DB       Azure SQL

I would add:

Microsoft Entra ID
      |
Managed Identity
      |
Azure RBAC

and:

Key Vault
   |
CMK/secrets/certificates

Plus:

• disable public network access where appropriate;
• use private endpoints;
• use managed identities rather than embedded account keys;
• encrypt data at rest and in transit;
• apply least-privilege RBAC;
• classify sensitive datasets;
• maintain audit logs and lineage.

13. Analytics performance design

My high-level optimization rules would be:

Microsoft specifically recommends maximizing parallel reads/writes for ADLS analytical workloads rather than serializing large ingestion jobs. (Microsoft Learn)

Interview architecture to memorize

                SOURCES
                   |
        +----------+----------+
        |                     |
   Azure SQL              Cosmos DB
     OLTP                Operational JSON
        |                     |
        +----------+----------+
                   |
              ADF / Events
                   |
                   v
              ADLS Gen2
           ┌─────────────┐
           │ BRONZE      │
           │ raw         │
           └──────┬──────┘
                  ↓
             Databricks
                  ↓
           ┌─────────────┐
           │ SILVER      │
           │ clean       │
           └──────┬──────┘
                  ↓
             Databricks
                  ↓
           ┌─────────────┐
           │ GOLD        │
           │ curated     │
           └──────┬──────┘
                  |
          +-------+-------+
          |               |
      Azure SQL          AI/ML
       Serving
          |
       Power BI

90-second interview answer

“I would use a polyglot storage architecture. Azure Blob Storage with ADLS Gen2 would be the central analytical data lake because it provides low-cost scalable storage for structured, semi-structured and unstructured data.

I would organize it using Bronze, Silver and Gold zones. Raw data from Azure SQL, Cosmos DB, APIs and other systems lands unchanged in Bronze. Databricks then performs schema enforcement, quality checks, deduplication and transformations, storing Silver and Gold datasets primarily in Delta or Parquet formats.

Cosmos DB remains the operational store for low-latency, high-volume JSON workloads rather than becoming the primary data lake. Azure SQL handles relational transactional workloads and can also provide a curated SQL serving layer for BI applications.

For performance, I’d use incremental ingestion, parallel processing, appropriate partitioning, columnar storage and file compaction. From a security perspective, all three platforms would use Entra ID, managed identities, RBAC and private endpoints.

Finally, I keep operational and analytical workloads isolated so large BI or ML queries never affect production databases.”

One particularly good 2026 interview point is to mention that although Cosmos DB Synapse Link appears in many older architectures, Microsoft now recommends Cosmos DB Mirroring for Microsoft Fabric for new projects rather than starting a new Synapse Link implementation. (Microsoft Learn)

Types of Accounts in Azure

Azure has a layered identity model — several distinct account and identity types, each serving a different purpose across the platform.

Category 1 — Human / Interactive Accounts

1. Microsoft Account (MSA)

A personal Microsoft account used to access Azure on a personal or pay-as-you-go basis.

Examples:   john@outlook.com
            jane@hotmail.com
            user@live.com
Use cases:
  - Personal Azure subscriptions
  - Free tier / Visual Studio subscriptions
  - Individual developers exploring Azure
Limitations:
  - Not managed by an organisation
  - No Conditional Access policies
  - No central IT control
  - Not suitable for enterprise use

2. Work or School Account (Entra ID Member)

The standard enterprise identity — managed by your organisation’s Entra ID tenant. This is the default account type for all corporate Azure users.

Format:     user@contoso.com
            admin@contoso.onmicrosoft.com
Properties:
  - Managed by IT admin
  - MFA enforced via Conditional Access
  - Password policies applied
  - Licences assigned (M365, Defender, etc.)
  - PIM eligible for elevated roles
  - Accessible via SSPR (self-service password reset)
Authentication:
  - Password + MFA (Authenticator app, FIDO2, SMS)
  - Certificate-based authentication
  - Windows Hello for Business
  - Passwordless (FIDO2 hardware key)

3. Guest Account (B2B — Business to Business)

External users from other organisations or personal email addresses invited into your tenant. They retain their home identity but can access resources you explicitly grant.

Examples:   partner@vendor.com (has their own Entra ID tenant)
            contractor@gmail.com (personal account)
How it works:
  You invite → They accept → Shadow account created in your tenant
  They authenticate with THEIR identity provider
  They access only what you grant via RBAC
Guest limitations by default:
  - Cannot enumerate users/groups in your tenant
  - Cannot register new applications
  - Cannot access the Azure portal (unless explicitly granted)
  - Subject to your Conditional Access policies (optional)
Use cases:
  - External consultants needing resource access
  - Partner company developers
  - Auditors needing read access

4. Break-Glass Emergency Access Account

A special account kept outside normal identity governance — used only when all normal admin access fails (MFA outage, Conditional Access misconfiguration locking out all admins).

Characteristics:
  - Cloud-only account (never synced from on-premises)
  - Not assigned to any individual person
  - Excluded from ALL Conditional Access policies
  - Uses very long, complex password (stored in physical vault)
  - No MFA device dependency
  - Assigned Global Administrator role
Monitoring:
  - ANY sign-in to this account → immediate alert to CISO
  - Azure Monitor alert on SigninLogs:
    | where UserPrincipalName == "breakglass@contoso.com"
    → PagerDuty + email + SMS to security team
Best practice: Have exactly 2 break-glass accounts.
               Store credentials in separate physical vaults.
               Test quarterly (sign in, verify access, sign out).

Category 2 — Non-Human / Workload Identities

5. Service Principal

The identity used by applications, scripts, and automation tools to authenticate to Azure. Created from an App Registration in Entra ID.

Components:
  App Registration (global, 1 per app)
    ├── Application ID (client_id): "a1b2c3d4-..."
    ├── Client secret or certificate
    └── API permissions
  Service Principal (per tenant, can be multi-tenant)
    └── The actual identity object in your tenant
Authentication:
  client_id + client_secret  → access token
  client_id + certificate    → access token (more secure)
Use cases:
  - CI/CD pipelines (Azure DevOps, GitHub Actions)
  - Terraform / infrastructure automation
  - External applications calling Azure APIs
  - Cross-tenant access
Risks:
  - Secrets expire — need rotation process
  - Secrets can be leaked in code/logs
  - Over-privileged SPs are a major attack vector

Service principal in a CI/CD pipeline:

# Authenticate as service principal
az login \
  --service-principal \
  --username $CLIENT_ID \
  --password $CLIENT_SECRET \
  --tenant $TENANT_ID
# Or with certificate (recommended)
az login \
  --service-principal \
  --username $CLIENT_ID \
  --certificate /path/to/cert.pem \
  --tenant $TENANT_ID

6. System-Assigned Managed Identity

An identity automatically created and managed by Azure for a specific resource. When the resource is deleted, the identity is deleted too — they share a lifecycle.

Supported resources:
  Virtual Machines, VM Scale Sets
  App Service, Azure Functions
  AKS (kubelet identity)
  ARO (cluster identity)
  Logic Apps, API Management
  Container Instances, Container Apps
  Azure Data Factory, Synapse
How it works:
  1. Enable on VM:
     az vm identity assign --resource-group rg --name my-vm
  2. Azure creates a service principal in Entra ID
     (you never see the secret — Azure manages it)
  3. VM gets an instance metadata endpoint:
     http://169.254.169.254/metadata/identity/oauth2/token
  4. Code on the VM requests a token:
     curl http://169.254.169.254/metadata/identity/oauth2/token
          ?api-version=2018-02-01
          &resource=https://vault.azure.net
     → Returns: { "access_token": "eyJ0..." }
  5. Token used to call Azure services:
     No password, no secret, no rotation needed
Characteristics:
  One identity per resource
  Deleted when resource is deleted
  Cannot be shared across resources
  Best for: single-purpose resource identities

7. User-Assigned Managed Identity

A standalone Entra ID resource — an identity that exists independently and can be assigned to multiple resources simultaneously.

Creation:
  az identity create \
    --resource-group rg-identities \
    --name id-payment-processor
    # Creates: /subscriptions/.../resourceGroups/rg-identities/
    #          providers/Microsoft.ManagedIdentity/
    #          userAssignedIdentities/id-payment-processor
Assignment to multiple resources:
  az vm identity assign \
    --resource-group rg-prod \
    --name vm-app-01 \
    --identities id-payment-processor
  az vm identity assign \
    --resource-group rg-prod \
    --name vm-app-02 \
    --identities id-payment-processor
  az functionapp identity assign \
    --resource-group rg-prod \
    --name func-payment \
    --identities id-payment-processor
Characteristics:
  Independent lifecycle (survives resource deletion)
  Shared across multiple resources
  Consistent RBAC assignments across all resources
  Best for: shared identity across a fleet of resources
RBAC assignment (one assignment covers all resources):
  az role assignment create \
    --assignee <principal-id-of-identity> \
    --role "Key Vault Secrets User" \
    --scope /subscriptions/.../vaults/kv-prod

System-Assigned vs User-Assigned — When to Use Which

Category 3 — Administrative Accounts (RBAC Roles)

Azure RBAC vs Entra ID Roles — Two Separate Systems

Entra ID roles:              Azure RBAC roles:
Controls Entra ID itself     Controls Azure resources
─────────────────────────    ────────────────────────
Global Administrator         Owner
User Administrator           Contributor
Security Administrator       Reader
Billing Administrator        Custom roles
Application Administrator    Resource-specific roles
A Global Admin has NO Azure resource access by default.
A Subscription Owner has NO Entra ID admin access by default.
These are completely separate permission systems.

Built-in Azure RBAC roles

Privileged Identity Management (PIM)

Best practice — never assign permanent privileged roles. Use PIM for just-in-time access:

Normal state:   user has Reader role (permanent)
Need access:    user requests Contributor for 2 hours
Approval:       manager approves in 5 minutes
Active window:  user has Contributor for 2 hours
Expires:        automatically reverts to Reader
Audit:          full log of why, when, approved by whom

Category 4 — Special / Hybrid Account Types

8. Hybrid Synced Account (Entra Connect)

On-premises Active Directory accounts synchronised to Entra ID via Microsoft Entra Connect (formerly Azure AD Connect):

On-premises AD:    CONTOSO\jsmith  (john.smith@contoso.local)
Synced to Entra:   john.smith@contoso.com
Sync scope:
  - Username, display name, UPN
  - Group memberships
  - Password hash (optional — for password hash sync)
  - Not: local admin rights, on-prem group policies
Authentication options:
  Password Hash Sync (PHS)  — hash synced to cloud, auth in cloud
  Pass-Through Auth (PTA)   — auth forwarded to on-prem AD
  Federation (ADFS)         — full on-prem auth, token issued

9. B2C Consumer Account

For customer-facing applications — completely separate from corporate B2B. Customers sign up with social identities or email:

Supported identity providers:
  Google, Facebook, Apple, Amazon (social login)
  Local email + password (managed by your B2C tenant)
  Any OpenID Connect provider
Use case:
  Public app where customers register themselves
  Retail, banking, insurance customer portals
  NOT for employee or partner access (use B2B for that)

10. Federated Workload Identity

A modern alternative to service principal secrets — allows external workloads (GitHub Actions, Kubernetes pods) to authenticate to Azure using their own platform’s identity token, with no secrets stored anywhere:

GitHub Actions example:
  1. GitHub issues OIDC token to pipeline run
  2. Pipeline exchanges GitHub token for Azure access token
  3. Azure validates: "is this the right repo/branch/environment?"
  4. Access granted — no client secret ever created
Configuration:
  az ad app federated-credential create \
    --id <app-id> \
    --parameters '{
      "name": "github-prod-deploy",
      "issuer": "https://token.actions.githubusercontent.com",
      "subject": "repo:contoso/my-app:environment:production",
      "audiences": ["api://AzureADTokenExchange"]
    }'
GitHub Actions workflow:
  permissions:
    id-token: write    # request OIDC token
  steps:
    - uses: azure/login@v2
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
        # No client-secret needed!

Account Type Decision Tree

Need to give access to...
A person in your organisation?
  └── Work/school account in Entra ID + PIM for admin roles
A person outside your organisation?
  └── B2B Guest account (they keep their own identity)
A public-facing customer?
  └── Azure AD B2C consumer account
A VM or Azure resource?
  └── Managed Identity (system or user-assigned)
  └── Never use a service principal for Azure resource auth
An external app / CI-CD pipeline?
  └── Service Principal (with certificate, not secret)
  └── Or Federated Workload Identity (no secret at all — best practice)
Emergency admin access?
  └── Break-glass account (2 accounts, physical vault, monitored)
Hybrid on-premises users?
  └── Entra Connect sync (password hash sync recommended)

Security Best Practices Summary