Workload Identities: Managed Identities & Service Principals

What are workload identities?

Types of workload identities

Not every workload needs the same type of identity. Here’s the decision framework:

Identity Type	Best For	Credentials
Managed identity	Azure resources talking to other Azure resources	None — Azure handles it automatically
Service principal	Non-Azure apps, multi-tenant apps, CI/CD pipelines	Certificate or client secret
User account	Never recommended for workloads (but sometimes inherited)	Password — risky for automation
Managed service account	On-premises services (Active Directory)	Password managed by AD automatically

Feature	Managed Identity	Service Principal	User Account
Credential management	Automatic (Azure)	Manual (you rotate)	Manual (you rotate)
Works outside Azure	No	Yes	Yes
Can be shared across resources	User-assigned: Yes	Yes	Yes (bad practice)
Appears in Entra ID	As enterprise app	As enterprise app	As user object
Supports Conditional Access	Limited	Yes	Yes
Risk of credential leak	None	Medium	High
Exam recommendation	Preferred for Azure	When managed identity isn't possible	Never for workloads

💡 Exam tip: The golden rule

The SC-300 exam strongly favours managed identities whenever the workload runs on Azure. If a question asks about an Azure VM, Azure Function, or App Service accessing a Key Vault or Storage Account, the answer is almost always “use a managed identity.” Service principals are the fallback for non-Azure scenarios or multi-tenant apps.

Managed service accounts — the on-prem option

Managed service accounts (MSAs) and group managed service accounts (gMSAs) are Active Directory objects for on-premises services. They’re NOT Entra ID objects — they live in on-prem AD only.

Type	Scope	Managed By
Managed service account (MSA)	Single server	AD auto-rotates the password
Group managed service account (gMSA)	Multiple servers (clustered services)	AD auto-rotates, all servers in the group use it

When the exam mentions managed service accounts: It’s testing whether you know these are on-premises AD identities, not cloud identities. If the workload runs in Azure → managed identity. If the workload is an on-prem Windows service → gMSA. Don’t confuse the two.

Managed identities — deep dive

A managed identity is a special type of service principal that Azure manages for you. You never see or handle its credentials — Azure rotates them automatically behind the scenes.

System-assigned vs user-assigned

Feature	System-Assigned	User-Assigned
Created with	The Azure resource (e.g., VM)	Independently as a standalone resource
Lifecycle	Tied to the resource — deleted when resource is deleted	Independent — persists until you delete it
Sharing	One identity per resource	One identity across multiple resources
Use case	Single resource needs access to one or two services	Multiple resources need the same permissions
Management overhead	Lower — automatic cleanup	Higher — you manage the lifecycle

ℹ️ Scenario: Ravi chooses the right identity

💻 Ravi Patel at NovaTech Solutions is deploying a new patient-data API on Azure App Service. The API needs to:

1. Read secrets from Azure Key Vault
2. Write logs to Azure Storage

Ravi considers his options:

• User account? No — passwords would be in config files, violating compliance.
• Service principal with a secret? Possible, but he’d need to rotate the secret every 6 months and store it somewhere secure (chicken-and-egg problem).
• Managed identity? Yes — Azure handles credentials automatically, no secrets in code, no rotation headaches.

Ravi enables a system-assigned managed identity on the App Service because only this one API needs access. He then assigns the Key Vault Secrets User role and the Storage Blob Data Contributor role to the managed identity.

Result: Zero credentials in code. Zero rotation burden. Full audit trail in Entra ID.

Creating and assigning managed identities

Enable a system-assigned managed identity:

1. Go to the Azure resource (e.g., App Service) → Identity blade
2. Under System assigned, toggle Status to On
3. Click Save — Azure creates the identity and shows you the Object ID

Create a user-assigned managed identity:

1. Go to Entra admin center → Managed identities (or Azure portal → search “Managed identities”)
2. Click Create → choose subscription, resource group, region, and name
3. After creation, go to the Azure resource → Identity → User assigned tab
4. Click Add → select the managed identity

Grant access to a target resource (RBAC):

1. Go to the target resource (e.g., Key Vault)
2. Access control (IAM) → Add role assignment
3. Select the role (e.g., Key Vault Secrets User)
4. Under Members, choose Managed identity → select your identity
5. Save

ℹ️ Scenario: Priya uses user-assigned for shared access

🔐 Priya Sharma at Meridian Health has 12 Azure Functions that all need to read from the same Storage Account containing medical imaging data. Instead of enabling 12 separate system-assigned identities and granting each one access, Priya:

1. Creates one user-assigned managed identity called mi-imaging-reader
2. Assigns the Storage Blob Data Reader role to mi-imaging-reader on the Storage Account
3. Attaches mi-imaging-reader to all 12 Azure Functions

Result: One identity, one role assignment, 12 functions. When a new function is added, Priya just attaches the same identity — no new role assignments needed.

Using a managed identity in code

When your app runs on an Azure resource with a managed identity enabled, it can request tokens from the Azure Instance Metadata Service (IMDS) without any credentials:

# Python example using Azure SDK
from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient

credential = DefaultAzureCredential()
client = SecretClient(vault_url="https://my-vault.vault.azure.net", credential=credential)
secret = client.get_secret("api-key")

The DefaultAzureCredential class automatically detects the managed identity — no connection strings, no passwords, no environment variables with secrets.

💡 Exam tip: DefaultAzureCredential chain

DefaultAzureCredential tries multiple authentication methods in order: environment variables → managed identity → Visual Studio → Azure CLI → interactive browser. On an Azure resource, it picks up the managed identity automatically. This is the recommended approach in Microsoft documentation and likely appears in exam scenarios.

Service principals — when managed identity isn’t enough

A service principal is the local representation of an application in your tenant. When you register an app in Entra ID or consent to a third-party app, a service principal is created automatically.

When you need a service principal instead of a managed identity:

• Your workload runs outside Azure (on-premises server, AWS, GCP)
• You need a multi-tenant application identity
• Your CI/CD pipeline (GitHub Actions, Azure DevOps) needs to deploy Azure resources
• You need workload identity federation (trust a token from an external identity provider without secrets)

ℹ️ Scenario: Ravi sets up CI/CD with workload identity federation

💻 Ravi needs GitHub Actions to deploy code to Azure. Instead of storing a client secret in GitHub:

1. He creates an app registration in Entra ID
2. Adds a federated credential that trusts tokens from GitHub’s OIDC provider
3. Configures the GitHub Actions workflow to request a token and exchange it for an Azure access token

Result: No secrets stored in GitHub. The federation trust means GitHub proves its identity via OIDC, and Entra ID issues a short-lived token. This is Microsoft’s recommended approach for CI/CD pipelines.

Workload identity security

Workload identities are increasingly targeted by attackers because they often have broad permissions and are less monitored than user identities.

Best practices:

• Use managed identities wherever possible (zero credential risk)
• Apply least-privilege RBAC — don’t give a managed identity Contributor when Reader suffices
• Set short expiry on service principal secrets and certificates (Microsoft recommends certificates over secrets)
• Use Conditional Access for workload identities (requires Workload Identities Premium licence) to restrict sign-ins by location or risk
• Monitor with Entra ID Protection — it can detect anomalous sign-in behaviour for service principals

🎬 Video walkthrough

🎬 Video coming soon

Workload Identities — SC-300 Module 16

Workload Identities — SC-300 Module 16

~12 min

Flashcards

Question

What is a managed identity in Entra ID?

Click or press Enter to reveal answer

Answer

A type of service principal that Azure manages automatically. It provides an identity for Azure resources to authenticate to other services without storing credentials in code. Azure handles credential creation and rotation.

Click to flip back

Question

What is the difference between system-assigned and user-assigned managed identities?

Click or press Enter to reveal answer

Answer

System-assigned: created with and tied to a single Azure resource — deleted when the resource is deleted. User-assigned: created as a standalone resource, can be shared across multiple Azure resources, and has an independent lifecycle.

Click to flip back

Question

When should you use a service principal instead of a managed identity?

Click or press Enter to reveal answer

Answer

When the workload runs outside Azure (on-premises, AWS, GCP), when you need multi-tenant app identity, for CI/CD pipelines, or when you need workload identity federation with an external identity provider.

Click to flip back

Question

What is workload identity federation?

Click or press Enter to reveal answer

Answer

A method that lets an external identity provider (like GitHub or Google Cloud) exchange its token for an Entra ID access token — eliminating the need to store secrets. It uses an OIDC trust relationship configured as a federated credential on an app registration.

Click to flip back

Knowledge Check

Knowledge Check

Ravi at NovaTech is deploying an Azure Function that needs to read secrets from Azure Key Vault. The function runs entirely in Azure. What identity type should Ravi use?

ACreate a user account with a strong password and store it in the Function's app settingsBCreate a service principal with a client secret stored in Key VaultCEnable a managed identity on the Azure Function and grant it Key Vault accessDUse the Function App's publish profile credentials to authenticate to Key Vault

Check Answer

Knowledge Check

Priya has 8 Azure Web Apps that all need read access to the same Azure SQL Database. She wants to minimise the number of role assignments. What should she do?

AEnable system-assigned managed identity on each Web App and create 8 role assignmentsBCreate one user-assigned managed identity, assign it to all 8 Web Apps, and create one role assignmentCCreate one service principal with a shared secret across all 8 Web AppsDUse a single user account with SQL authentication for all Web Apps

Check Answer

Knowledge Check

Ravi needs GitHub Actions to deploy infrastructure to Azure. His security team prohibits storing any long-lived secrets in GitHub. What should Ravi configure?

AA managed identity attached to the GitHub runnerBA service principal with workload identity federation using GitHub's OIDC providerCA service principal with a client certificate uploaded to GitHub SecretsDA user account with a personal access token stored as a GitHub Secret

Check Answer

---

Next up: Enterprise Apps: SSO, App Proxy & Integration — how to connect SaaS applications and on-premises apps to Entra ID for single sign-on and secure remote access.