AZ-400 exam questions on authentication and secrets management keep returning to one question: how does a pipeline prove its identity to Azure resources? The old answer was simple — store a client secret somewhere, retrieve it at runtime. The problem: any secret stored in an external system can be exposed. This post covers three approaches that eliminate that risk: Managed Identity, Workload Identity Federation (OIDC), and Azure Key Vault.
Employee Badge vs Machine Tag — Service Principal and Managed Identity
Every new hire gets a badge with an expiration date — when it expires, they request a renewal. The office printer, by contrast, never needs a renewal request; the building's infrastructure handles its credentials automatically. Service Principal is the employee badge. Managed Identity is the machine tag issued and managed by the platform itself.
A Service Principal is a non-interactive identity in Microsoft Entra ID. It works in any environment — an Azure VM, an on-premises server, a GitHub Actions runner, or an external CI/CD tool. The drawback: client secrets expire (max two years), and a missed renewal causes pipelines to fail silently at midnight.
Managed Identity is a Service Principal created, managed, and rotated by Azure. No credentials exist anywhere in code or pipeline config. Two types matter for the exam:
is bound to one Azure resource. Its lifecycle matches the resource — created and deleted together. Right for a single VM or App Service.
is an independent Azure resource assignable to multiple VMs, App Service instances, and AKS pods simultaneously. When a VM is replaced during scale-out, the same identity carries over. Exam keyword: → user-assigned.
| Scenario | Choose | |----------|--------| | Non-Azure environment, needs Azure access | Service Principal | | Single Azure-hosted resource | System-assigned Managed Identity | | Multiple resources sharing one identity | User-assigned Managed Identity |
!Service Principal versus Managed Identity
A Vault With No Key — Workload Identity Federation and OIDC
Picture a bank vault that opens not with a physical key, but with real-time biometric verification and live security-team approval. The key itself does not exist — only identity verification remains. That is Workload Identity Federation: instead of a client secret, the pipeline uses a short-lived OIDC token issued and verified in real time.
When GitHub Actions or Azure Pipelines runs, the platform issues a signed OIDC token — a JWT carrying repository, branch, org, and workflow context. The pipeline submits it to Azure's Secure Token Service. Azure verifies the issuer and subject claims against the pre-configured . On success, Azure issues an Access Token. No client secret exists anywhere in this exchange.
GitHub Actions setup: Create an App registration in Microsoft Entra ID. Add a Federated Identity Credential — Issuer: , Subject: . Assign the required Azure RBAC role to the Service Principal. Store only Client ID, Tenant ID, and Subscription ID in GitHub Secrets — no secret values. Pass those three values to the action in your workflow.
For Azure Pipelines, choosing Workload Identity Federation when creating a Service Connection handles the Federated Identity Credential registration automatically.
The most common OIDC failure: Subject claim mismatch — running from a feature branch when Subject specifies .
Three Compartments — Key Vault Secret, Key, and Certificate
A safe-deposit facility keeps banknotes, sealed documents, and stamps in separate sections — different security needs, different compartments. Azure Key Vault does the same, and identifying the right compartment is a frequent exam question.
stores arbitrary strings: connection strings, API keys, passwords, OAuth tokens. Most commonly used by pipelines.
manages RSA or EC asymmetric key material for cryptographic operations. HSM-protected keys never leave Key Vault. Use when the requirement involves encryption or signing.
manages X.509 TLS/SSL certificates including auto-renewal. Use for TLS, mTLS, or signing certificates.
Access Control Models
is Key Vault's own per-identity permission system (Get, List, Set, Delete, etc.), independent of Azure RBAC.
is the default for new Key Vaults since 2023. It integrates with Microsoft Entra ID and uses the same IAM interface as every other Azure resource. Key roles: (read-only Secret access for pipelines), (read + write), (full management).
For ARM template deployments to reference Key Vault Secrets, must be on. New Key Vaults have it off by default — forgetting this causes immediate deployment failure.
The Warehouse Master Log — Pipeline Secrets Integration
A logistics warehouse tracks inventory in one master log — every manager reads the same source, and updates propagate instantly. Pipeline secrets work the same way. When each pipeline maintains its own copy of a secret, updates get missed and versions diverge. A Variable Group linked to Key Vault is that master log.
When an Azure Pipelines Variable Group is linked to Key Vault, the YAML contains only the group name — no secret values. At runtime, secrets are fetched dynamically. Multiple pipelines in the same project share one Variable Group; when a secret rotates in Key Vault, every pipeline picks it up on the next run with no config changes.
In GitHub Actions, isolates secrets by deployment target. Environment Secrets are accessible only when that environment is active. Combined with protection rules — required reviewers, wait timers, IP restrictions — it creates a production deployment gate.
An Azure Pipelines authenticates to external systems. Permission levels: Reader → User → Creator → Administrator. User is enough to run a pipeline. Administrator is needed to edit, delete, or share the connection.
Exam Key Takeaways
'Authenticate to Azure without a client secret' -- Workload Identity Federation (OIDC) 'Multiple Azure resources sharing the same identity' -- User-assigned Managed Identity 'Single Azure resource accesses Key Vault without credentials' -- System-assigned Managed Identity 'GitHub Actions deploys to Azure, secretless' -- Workload Identity Federation 'Most common OIDC failure cause' -- Subject claim mismatch with actual branch 'Store connection string or API key in Key Vault' -- Secret 'Store encryption or signing key material in Key Vault' -- Key 'Store TLS/mTLS certificate in Key Vault' -- Certificate 'ARM deployment fails to read Key Vault Secret' -- Enable for template deployment is off 'Share Key Vault Secrets across multiple pipelines' -- Variable Group linked to Key Vault 'Standard Azure permission model for Key Vault' -- Azure RBAC 'Minimum permission for a pipeline run to use a Service Connection' -- User