9.1 Selecting Identities for Apps & Azure Workloads
Key Takeaways
- Workload identities represent applications, services, and automation—not people—and Domain 3 of SC-300 (about 20–25%) centers on choosing, securing, and governing them.
- Prefer Azure managed identities for Azure-hosted workloads that call Azure resources; they eliminate developer-managed secrets for that path.
- Use service principals (enterprise application identities) when non-Azure hosts, multi-tenant apps, or scenarios outside managed-identity support require an application identity in Microsoft Entra ID.
- Never use interactive user accounts for unattended jobs, scripts, or daemons—this is the exam’s default security stance because user credentials, MFA, and lifecycle do not fit non-interactive automation.
- On-premises or hybrid Windows services may still use managed service accounts (gMSA/sMSA) or group Managed Service Accounts where Active Directory is the authority; map those carefully when hybrid apps also need cloud tokens.
Why workload identity selection matters on SC-300
Domain 3 of the Microsoft Identity and Access Administrator Associate exam (SC-300)—Plan and implement workload identities—is weighted about 20–25%. After you can manage people (users, guests, MFA, Conditional Access), the exam shifts to non-human identities: apps, Azure resources, scripts, and services that need to call APIs and Azure data planes without a person at the keyboard.
A workload identity is any identity used by software rather than by an interactive human. In Microsoft Entra ID and Azure, the main options you must choose among are:
| Identity type | What it is | Typical host |
|---|---|---|
| System-assigned managed identity | Entra identity lifecycle-bound to one Azure resource | Single Azure resource (VM, Function, App Service, etc.) |
| User-assigned managed identity | Standalone Azure resource that multiple Azure resources can share | Multiple Azure resources, same identity |
| Service principal | Security principal for an application (enterprise app instance) in a tenant | Any host that can obtain tokens (Azure, on-premises, other cloud, CI/CD) |
| User account | Human directory object (member or guest) | Interactive people—not recommended for unattended workloads |
| Managed service account (sMSA / gMSA) | AD DS service account with managed password | On-premises Windows services / IIS app pools |
Decision framework: pick the right identity
SC-300 stems rarely say “create a secret.” They describe where the code runs, what it must access, and who manages credentials, then ask which identity pattern is correct.
Walk this path for every design question:
- Is the workload hosted on Azure and does it need to call Azure Resource Manager or Azure data-plane APIs that support Entra authentication?
- Can a managed identity attach to that host type (VM, VMSS, App Service, Functions, AKS workload identity patterns, Logic Apps, Azure Container Apps, and many others—feature support grows, but the exam idea is “Azure resource → managed identity first”)?
- If not on Azure, or the client is a multi-tenant SaaS app, a developer-registered API, or a pipeline outside Azure, you need a service principal (application + credentials or federated identity credentials).
- If the workload is a Windows service on domain-joined servers with no cloud token path yet, gMSA may still be the on-premises answer—but do not invent a cloud user for that role.
- Never default to “create a user named
svc-batchwith a password and disable MFA.”
| Scenario cue | Prefer |
|---|---|
| Azure Function reads a Storage account and Key Vault in the same tenant | Managed identity + Azure RBAC / Key Vault access policies or RBAC |
| GitHub Actions deploys to Azure from outside Azure | Service principal or workload identity federation (federated credential on the app) |
| Multi-tenant SaaS app signs in customers’ tenants | App registration + service principal per customer tenant |
| Nightly PowerShell on a jump box running as a named employee | Redesign—use managed identity, SP, or automation account identity; not the employee |
| IIS app pool on-premises talking only to SQL on-premises | gMSA (on-premises), not an Entra user |
| Same identity needed on five App Services | User-assigned managed identity shared across apps |
Managed identities: first choice for Azure workloads
Azure managed identities are Entra service principals under the covers, but Azure manages credential rotation for you. Your code requests an access token from the Instance Metadata Service (IMDS) or the resource’s managed-identity endpoint; no client secret is stored in config or Key Vault for that identity’s own authentication.
Security and operations benefits the exam expects you to articulate:
- No developer-managed secret for the workload-to-Azure authentication path.
- Lifecycle coupling (system-assigned): delete the resource, the identity goes away.
- Least privilege via Azure RBAC role assignments (and Entra app roles / Graph permissions when applicable).
- Auditability in sign-in logs for service principals / managed identities (workload identity sign-ins).
Limits to remember at design time:
- Managed identities are for Azure-hosted (or supported Azure-managed) workloads—not for arbitrary laptops.
- Not every external SaaS API accepts managed-identity tokens; many third-party APIs still need their own keys (store those secrets in Key Vault and have the managed identity read Key Vault).
- Cross-tenant access usually means service principals / multi-tenant apps, not a simple system-assigned MI in one subscription.
Service principals: when managed identity is not enough
A service principal is the local representation of an application object in a specific Microsoft Entra tenant—the enterprise application identity instance that can be granted roles and can authenticate.
You use service principals when:
- Code runs outside Azure (on-premises job servers, other clouds, build agents).
- You need an application registration with API permissions, app roles, or multi-tenant consent.
- CI/CD systems authenticate with a client secret, certificate, or federated identity credential (preferred modern pattern for GitHub/Azure DevOps).
- You must assign Entra directory roles or Graph application permissions to an automation identity (managed identities can also receive some of these, but exam scenarios often still phrase non-Azure automation as “service principal”).
Tradeoff versus managed identity: you (or your pipeline) must manage credentials unless you use federation. Certificate credentials are preferred over long-lived client secrets; secrets expire, leak into repos, and show up in breach dumps. Section 9.3 deepens lifecycle and credentials.
User accounts: the wrong default for unattended work
Exam stance (hard rule): do not use interactive user accounts for unattended workloads, daemons, scheduled tasks that call APIs, or “service users” that share a password among scripts.
Why this fails security and operations:
| Problem | Why it hurts |
|---|---|
| MFA / passwordless | Human authentication methods conflict with non-interactive token acquisition |
| Credential sharing | Passwords get embedded in scripts, Task Scheduler, and chat threads |
| Lifecycle | Employee leaves; “service user” is disabled; production breaks or stays orphaned |
| Conditional Access | Policies aimed at people (device compliance, risk, location) block or mis-fire on robots |
| Licensing & audit | Confuses human access reviews with machine access; weak accountability |
| Privilege creep | Users often get broad group membership “so the job works” |
If a stem says “the finance script runs every night as alex@contoso.com and MFA blocks it,” the fix is not “exclude Alex from MFA forever.” The fix is migrate the script to a managed identity or service principal with least-privilege RBAC, then leave Alex under strong CA.
Break-glass and emergency human accounts are still people identities for portal recovery—they are not a pattern for app-to-Azure authentication.
Managed service accounts (on-premises context)
SC-300 is cloud-identity heavy, but hybrid realism still appears:
- sMSA (standalone Managed Service Account) — domain account for one computer, password managed by AD.
- gMSA (group Managed Service Account) — password managed by AD, usable by multiple hosts (for example a server farm).
Use these when the resource and client are on-premises AD and Windows supports gMSA for the service. When that same app later calls Microsoft Graph or Azure, introduce a cloud workload identity (MI or SP) for the cloud leg rather than stuffing a user’s password into the service.
| Environment | Identity pattern |
|---|---|
| Azure resource → Azure resource (Entra auth) | Managed identity |
| Non-Azure / multi-tenant / CI pipeline → Azure or Graph | Service principal (cert or federation preferred) |
| On-premises Windows service → on-premises resources | gMSA / sMSA |
| Human interactive sign-in | User account + strong auth |
| Legacy “svc_” user for nightly batch to Azure | Refactor to MI/SP |
Security tradeoffs summary
| Option | Secret management | Blast radius control | SC-300 preference |
|---|---|---|---|
| System-assigned MI | Azure-managed | Per resource | Default for single Azure workload |
| User-assigned MI | Azure-managed | Shared; plan reuse carefully | Shared identity across several Azure resources |
| SP + certificate | You rotate certs | App-scoped; monitor expiry | Non-Azure / app model |
| SP + client secret | Highest leak risk | Same, plus secret sprawl | Avoid long-lived secrets |
| SP + federated credential | No long-lived secret in pipeline | Issuer/subject constrained | Preferred for CI/CD |
| User account | Password/MFA friction | Human lifecycle | Do not use for unattended |
| gMSA | AD-managed password | Host/service scoped | On-premises Windows services |
Putting selection into exam answers
When you open a Domain 3 item, underline the host and the resource:
- “App Service in Azure reads Blob Storage” → managed identity + **Storage Blob Data *** role.
- “On-premises console app calls Microsoft Graph” → app registration / service principal with application permissions and admin consent (not a user delegated path for pure daemon).
- “Five functions share one identity for a common Key Vault” → user-assigned managed identity.
- “Scheduled task as the CFO’s account” → wrong; redesign identity.
An Azure App Service must read blobs from Azure Storage and secrets from Azure Key Vault in the same tenant without storing a client secret in application settings. Which identity approach best matches SC-300 guidance?
A nightly automation job runs on an on-premises Windows server and must deploy resources to Azure via Microsoft Entra authentication. Why is running the job as an ordinary employee user account a poor design?
Four Azure Functions and two App Services must present the same identity when calling a shared set of Azure resources. Which managed-identity shape fits best?
Which scenario is the best fit for a group Managed Service Account (gMSA) rather than an Azure managed identity?