Managed Identities vs Service Principals

In Azure, applications and services often need to authenticate to other Azure resources without using human credentials. Two primary mechanisms exist: Managed Identities and Service Principals. Both are Azure AD identities, but they differ in lifecycle, management overhead, and scope.

A Managed Identity is an Azure AD identity that is automatically managed by Azure and tied to a specific Azure resource (e.g., a virtual machine, App Service, or Azure Function). It cannot be created independently; it is enabled on a resource. Azure automatically rotates the credentials (certificates) every 46 days. There are two types: System-assigned and User-assigned. A system-assigned identity is tied to the lifecycle of the resource—when the resource is deleted, the identity is deleted. A user-assigned identity is a standalone resource that can be assigned to multiple Azure resources, and its lifecycle is independent.

A Service Principal is a manual identity created in Azure AD for an application, service, or automation tool. It is essentially an application instance in Azure AD with a client ID and either a client secret (password) or certificate. The lifecycle is managed by the administrator; secrets must be rotated, and certificates must be renewed. Service Principals can be used by applications running anywhere—on-premises, in other clouds, or in Azure—as long as they can communicate with Azure AD.

Managed Identity Authentication Flow:

Service Principal Authentication Flow:

Key difference: Managed Identities use a certificate that is automatically rotated by Azure, while Service Principals use a secret or certificate that must be managed manually.

Azure CLI - Managed Identity:

# Enable system-assigned managed identity on a VM
az vm identity assign --resource-group myRG --name myVM

# Create a user-assigned managed identity
az identity create --resource-group myRG --name myUserIdentity

# Assign user-assigned identity to a VM
az vm identity assign --resource-group myRG --name myVM --identities /subscriptions/.../providers/Microsoft.ManagedIdentity/userAssignedIdentities/myUserIdentity

# Get token for testing (from within the VM)
curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net' -H Metadata:true

Azure CLI - Service Principal:

# Create a service principal with a password
az ad sp create-for-rbac --name myServicePrincipal --role Contributor --scopes /subscriptions/...

# Create a service principal with a certificate
az ad sp create-for-rbac --name myServicePrincipal --certificate myCert.pem

# List service principals
az ad sp list --show-mine

# Reset credentials
az ad sp credential reset --name myServicePrincipal

PowerShell - Managed Identity:

# Enable system-assigned identity
Update-AzVM -ResourceGroupName 'myRG' -VMName 'myVM' -IdentityType SystemAssigned

# Create user-assigned identity
New-AzUserAssignedIdentity -ResourceGroupName 'myRG' -Name 'myUserIdentity'

PowerShell - Service Principal:

# Create service principal
$sp = New-AzADServicePrincipal -DisplayName 'myServicePrincipal'
# Get password from $sp.Secret (automatically generated)

Objective 1.3: "Manage Azure AD identity protection" includes understanding Managed Identities and Service Principals as part of securing identities. The exam expects you to:

Scenario 1: VM Accessing Key Vault

A common enterprise scenario is a virtual machine that needs to retrieve a database connection string from Azure Key Vault. Using a Managed Identity, the developer enables system-assigned identity on the VM, then grants that identity 'Get' and 'List' permissions on the Key Vault access policy. The application code calls the IMDS endpoint to get a token and then uses it to fetch the secret. This eliminates the need to store credentials in code or configuration files. In production, you might have hundreds of VMs, each with its own identity. Performance is excellent because IMDS is local. A common misconfiguration is forgetting to assign the RBAC role or access policy—without it, the token is valid but the request is denied. Another issue is running the code outside the VM (e.g., during development) where IMDS is not available; developers often switch to a service principal for local testing.

Scenario 2: CI/CD Pipeline Deploying to Azure

Azure DevOps pipelines often use a Service Principal to authenticate to Azure for deployments. The service principal is created with 'Contributor' role on a resource group. The pipeline uses the client ID and secret (stored as a secret variable in Azure DevOps) to log in via az login --service-principal -u <client-id> -p <secret> --tenant <tenant>. This works well but has security risks: if the secret is exposed in logs, an attacker can deploy resources. Best practice is to use a certificate instead of a secret, or use Azure AD Workload Identity Federation (which uses OpenID Connect tokens from the pipeline provider). The exam may ask about this: for non-Azure workloads, service principals are necessary.

Scenario 3: Multi-tier Application with User-assigned Identity

A microservices application running on Azure Kubernetes Service (AKS) might use a user-assigned managed identity shared across multiple pods. Each pod can request tokens for different resources (e.g., one pod accesses storage, another accesses Key Vault). The user-assigned identity is assigned to the AKS node pool or to individual pods via Azure AD Pod Identity (now replaced by Workload Identity). This allows the same identity to be used across services, simplifying RBAC management. However, if the identity is accidentally deleted, all pods lose access. The exam tests that user-assigned identities can be assigned to multiple resources, whereas system-assigned is per-resource.