Domain 3 of 4 · Chapter 1 of 4

Workload Identities

What a workload identity is, and the four choices

A workload is software, not a person: an application, a service, a script, or a container that has to authenticate to something. It needs its own identity, and the SC-300 selection question is always which one. In Microsoft Entra ID the workload identities[1] are exactly three things: applications, service principals, and managed identities. A user account is a fourth identity you might be tempted to misuse for a workload, and a managed service account is a fifth that lives in on-premises Active Directory, not in Entra. Knowing where each one belongs is the whole skill.

Start from one model. Every non-human identity that calls a Microsoft Entra protected resource does so as a service principal[2]: the local, per-tenant instance of an application that defines what the app can actually do in that tenant. An application object is the global template (it describes how tokens are issued and what the app can access); the service principal is the instance created from that template in each tenant. A managed identity is just a special type of service principal whose credentials Microsoft manages for you, so it carries no secret you can leak. That single sentence is the one to memorize: a managed identity is a service principal, the kind Azure rotates the certificate for. The diagram below nests these so the containment reads at a glance: a managed identity sits inside the service principal box because it is one kind of service principal, not a separate fourth thing.

The selection rule follows from where the workload runs and who, or what, it is.

Identity Use it for Avoid it for
Managed identity A workload running on an Azure resource that supports one Anything off Azure
Service principal (app registration) A workload outside Azure, or one needing API permissions and consent A stand-in for a human
User account A human signing in interactively A daemon, service, or automation
Managed service account (gMSA) An on-premises Windows service authenticating to on-prem AD Authenticating to Microsoft Entra ID

The instinct to reach for is the weakest identity that still does the job. A managed identity has no exportable credential, so it is the safest default when the workload sits on Azure. A managed service account[3] such as a group managed service account (gMSA) is a Windows construct in Active Directory Domain Services whose password Active Directory rotates; it secures on-prem Windows services and has nothing to do with Entra tokens, so an SC-300 item that offers it for an Azure-to-Azure call is a distractor.

Microsoft Entra workload identitiesApplication objectglobal template(how tokens issue)Service principalper-tenant instanceManaged identityspecial service principal,Azure-managed credentialno secret to leak
Entra workload identities nest: the application object is the global template, the service principal its per-tenant instance, a managed identity one kind of SP.

System-assigned versus user-assigned managed identities

There are two types of managed identity, and they behave identically at token time. They differ in lifecycle and sharing, and that difference is what every exam item turns on. System-assigned[4] is enabled directly on a single Azure resource: Azure creates a service principal whose lifecycle is tied to that resource, only that resource can request tokens with it, and when you delete the resource Azure deletes the identity for you. User-assigned[4] is created as a standalone Azure resource, managed separately from anything that uses it, sharable across many resources, and it lives until you delete it explicitly.

The differences that get tested

Property System-assigned User-assigned
Creation Created as part of an Azure resource Created as a standalone Azure resource
Lifecycle Shared with the resource; deleted when the resource is deleted Independent; you must delete it yourself
Sharing Cannot be shared; one resource only Can be shared across many resources
Typical use One resource needs its own identity Many resources share one identity, or permissions must exist first

Microsoft now recommends user-assigned[5] as the default for most scenarios, and three of them recur on the exam. First, pre-provisioning: a user-assigned identity and its role assignments can be created before the resource that consumes them, so a deployment that needs access during provisioning does not fail; a system-assigned identity does not exist until its resource does, so its role assignments cannot be created in advance. Second, replicated workloads: four virtual machines reaching the same storage account need eight role assignments with system-assigned identities but only two when they share one user-assigned identity, which cuts management overhead. Third, ephemeral compute: rapidly creating many resources each with its own system-assigned identity can trip the Microsoft Entra object-creation rate limit and return HTTP 429, and a deleted system-assigned identity still counts toward your directory object limit until it is fully purged after 30 days.

System-assigned still wins in two cases worth remembering, and the diagram below maps these drivers to the two outcomes. Use it for audit logging when you must record which specific resource performed an action rather than which identity, and for permissions lifecycle management when you want the identity, and therefore its access, to disappear automatically the moment the resource is deleted. A resource can also carry both a system-assigned identity and one or more user-assigned identities at once, which lets you mix a shared identity with resource-specific permissions on the same host.

One maintenance trap sits underneath all of this. Deleting a managed identity does not delete its role assignments; an orphaned assignment shows as "Identity not found" in the portal and keeps consuming your per-subscription role-assignment limit until you remove it by hand. A user-assigned identity with no resources attached also keeps existing, and its bill of zero does not clean it up, so you delete it deliberately.

Pre-provision accessReplicated workloads, fewer rolesEphemeral compute(avoid HTTP 429)Audit the specific resourceDelete identity with resourceUser-assignedstandalone, sharableSystem-assigneddies with the resource
The tested selection drivers and which managed-identity type they point to; both types are credential-free and behave identically at token time.

Create one, assign it, and use it to reach another resource

The end-to-end flow is three moves: create the identity, grant it a role on the target, and let the resource fetch its own token. The mechanism behind the third move is the part candidates underestimate, so walk it once and it stays.

Create and assign

A system-assigned identity is enabled on the resource itself. With the Azure CLI, az vm identity assign --resource-group rg --name myVm turns it on for a VM and returns the principal ID. A user-assigned identity is created first, then attached:

az identity create --resource-group rg --name myUami
az vm identity assign --resource-group rg --name myVm \
  --identities /subscriptions/<sub>/resourceGroups/rg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myUami

Either way the identity is useless until you grant it access. Authorization is plain Azure RBAC[6]: assign a role such as Storage Blob Data Reader to the identity's principal at the scope of the target, granting the least privilege the task needs and no more. Creating the identity and granting the role are two separate steps; doing the first without the second is the most common reason a managed-identity call returns 403.

Use it to call another resource

The diagram below shows what happens at runtime. Code on the resource asks the local Azure Instance Metadata Service[7] (IMDS) identity endpoint for a token, IMDS uses the identity's certificate (which Azure injected, never you) to request a Microsoft Entra access token, and the code then presents that token to the target service. No secret is ever stored on the host, which is the entire point.

The token endpoint is reachable only from inside the resource at http://169.254.169.254/metadata/identity/oauth2/token, and the request must carry the header Metadata: true. The resource parameter names the audience you want a token for, for example https://storage.azure.com/ for Azure Storage. A raw request looks like this:

curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fstorage.azure.com%2F' \
  -H Metadata:true

The 169.254.169.254 address is the link-local IMDS endpoint, not a public service: it answers only to code running on that VM, which is what makes it safe to query without a credential. In practice you do not hand-roll this call; the Azure SDK's DefaultAzureCredential or the Microsoft Authentication Library (MSAL) does it for you and caches the token. Microsoft Entra ID returns a standard JSON Web Token (JWT) access token your code sends on to any service that supports Entra authentication.

Code on resource(VM, App Service)IMDS endpoint169.254.169.254Microsoft Entra IDissues JWT tokenTarget serviceStorage, Key Vault1. Ask for token2. Cert request3. Return token4. Present token to target
A managed identity fetches its own Microsoft Entra token from the local IMDS endpoint, then presents it to the target service; no secret is stored on the host.

Exam-pattern recognition and traps

SC-300 workload-identity items read as short scenarios that hinge on one distinction. Train yourself to spot which distinction the stem is testing before you read the options.

"Which identity should you use"

When the stem describes software on an Azure resource calling another Azure service and asks for the most secure or recommended identity with no credential to manage, the answer is a managed identity, and a system-assigned one is correct when only that single resource needs access. If the workload runs outside Azure (GitHub Actions, another cloud, a Kubernetes cluster off Azure), a managed identity is impossible and the answer is an app registration, ideally with workload identity federation[1] so there is still no secret to store; app registrations are covered in App Registrations. A user account as the answer for any automated workload is wrong by design, and a service account password in code is the option the question wants you to reject.

"System-assigned or user-assigned"

The tell is in the lifecycle words. "Multiple resources need the same permissions," "reduce the number of role assignments," "permissions must exist before the resource is deployed," "resources are recycled frequently but access should stay consistent": all point to user-assigned. "The identity should be deleted with the resource," "each resource needs its own identity," "log which specific resource acted": all point to system-assigned. A scenario that creates many resources fast and worries about hitting a limit is steering you to user-assigned to avoid the HTTP 429 object-creation rate limit.

The traps to pre-arm against

First, a deleted managed identity leaves its role assignments behind as "Identity not found," so a question about cleanup wants you to remove the orphaned assignments, not just the identity. Second, changing a managed identity's group or role membership does not take effect immediately because the token is cached for roughly 24 hours; the fix the exam rewards is assigning the role directly to a user-assigned identity rather than juggling Microsoft Entra group membership. Third, when a resource has more than one user-assigned identity, a token request that omits the client_id is ambiguous and fails; you must name which identity you want. Fourth, workload identity federation has a limit of 20 federated identity credentials when a managed identity is used as the credential on an Entra application, a number a precise item may probe. Each of these is a single fact that decides the whole question.

Choosing a workload identity

PropertySystem-assigned managed identityUser-assigned managed identityService principal (app registration)Managed service account (gMSA)
What it isService principal tied to one Azure resourceStandalone Azure resource you attach to resourcesInstance of an app registration in a tenantWindows account in on-prem Active Directory
Where the workload runsOn the Azure resourceOn the Azure resource(s)Anywhere, including outside AzureOn-premises Windows servers
Credential managementAzure issues and rotates, none for youAzure issues and rotates, none for youYou manage secret/certificate or use federationActive Directory rotates the password
LifecycleDeleted with the resourceIndependent, delete it yourselfIndependent, delete it yourselfManaged in AD DS
Shared across resourcesNo, one resource onlyYes, many resourcesYes, many clientsYes, across domain hosts
Authenticates toMicrosoft Entra IDMicrosoft Entra IDMicrosoft Entra IDOn-prem AD (Kerberos)

Decision tree

Identity for a human?User account+ MFA, never a daemonYesRuns on an Azure resource?No (workload)Shared by manyresources?Yes, managed identitySystem-assigned MIdies with the resourceNo, one resourceUser-assigned MIpre-create, share, reuseYes, or pre-provisionOn-prem to AD?use gMSA, else app regNo, off AzureApp registrationfederation, else secretOff Azure, not on-premAlways: grant least-privilege RBAC on the target, and prefer credential-free over a stored secretmanaged identity and workload identity federation store no secret
Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

A managed identity is a service principal Azure manages the credentials for

In Microsoft Entra ID the workload identities are applications, service principals, and managed identities. A managed identity is a special type of service principal whose certificate Azure issues, stores, and rotates, so there is no secret for you to handle or leak. Your code obtains a Microsoft Entra access token for the identity and presents it to any service that supports Entra authentication, and managed identities cost nothing extra.

Use the weakest identity that does the job for a workload

Pick a workload identity from where the code runs and what it is. Use a managed identity when the workload runs on an Azure resource that supports one, because nothing can be stolen. Use an app registration with a service principal when the workload runs outside Azure or needs API permissions and consent. Reserve a user account for a human and a group managed service account (gMSA) for on-premises Windows services authenticating to on-prem Active Directory.

Trap Using a user account with a stored password to run an unattended service or daemon; user accounts are for humans, and a workload should use a managed identity or service principal instead.

1 question tests this
A gMSA authenticates to on-prem AD, not to Microsoft Entra

A group managed service account (gMSA) is a Windows account in Active Directory Domain Services whose password Active Directory creates and rotates automatically. It secures on-premises Windows services that authenticate over Kerberos to on-prem AD. It issues no Microsoft Entra token, so it is never the right choice for an Azure resource calling another Azure service.

Trap Choosing a managed service account for an Azure-to-Azure call; a gMSA only works against on-prem Active Directory, so a managed identity is the Azure answer.

System-assigned managed identity lives and dies with its resource

A system-assigned managed identity is enabled directly on one Azure resource, and Azure creates a service principal tied to that resource's lifecycle. Only that resource can request tokens with it, and when you delete the resource Azure deletes the identity automatically. It can never be shared with another resource, so each resource that needs one gets its own.

5 questions test this
User-assigned managed identity is standalone and sharable

A user-assigned managed identity is created as its own Azure resource and managed separately from anything that consumes it. The same identity can be attached to many resources, and its lifecycle is independent, so it survives until you delete it explicitly even when no resource uses it. Microsoft recommends user-assigned as the default managed-identity type for most scenarios.

Trap Assuming a user-assigned identity disappears when its last resource is deleted; it is a standalone resource you must delete yourself.

1 question tests this
Pre-create a user-assigned identity when access is needed during deployment

A user-assigned identity and its role assignments can be created before the resource that consumes them, so a deployment that needs access while provisioning succeeds. A system-assigned identity does not exist until its resource exists, so its role assignments cannot be granted in advance, and a deployment that needs access during creation can fail. This pre-provisioning ability is a common reason to choose user-assigned.

Trap Relying on a system-assigned identity for access that must exist before the resource is deployed; the identity is created with the resource, so the role assignment cannot be made in time.

Share one user-assigned identity to collapse role assignments

When several resources do the same job and need the same permissions, attaching one shared user-assigned identity means a role is assigned once instead of per resource. Microsoft's example: four virtual machines reaching two storage accounts need eight role assignments with system-assigned identities but only two with a shared user-assigned identity. Fewer distinct identities and assignments cuts management overhead.

1 question tests this
User-assigned avoids the Entra object-creation rate limit on bursty deploys

Creating many resources quickly, each with its own system-assigned identity, can exceed the Microsoft Entra object-creation rate limit and fail with HTTP 429. A single pre-created user-assigned identity needs only one service principal, so it sidesteps the limit. This makes user-assigned the recommendation for ephemeral or rapidly recycled compute.

Trap Giving every node in a rapidly scaling fleet its own system-assigned identity; the burst of Entra object creations can hit the rate limit and return HTTP 429.

A deleted system-assigned identity still counts toward limits for 30 days

Deleting a resource removes its system-assigned identity, but the identity keeps counting toward your Microsoft Entra directory object limit until it is fully purged after 30 days. Rapidly creating and deleting resources with system-assigned identities can therefore push you toward that limit even though the identities look gone. A shared user-assigned identity avoids the churn.

Choose system-assigned when you must audit the specific resource

Use a system-assigned identity when the requirement is to log which specific resource carried out an action rather than which identity, since a shared user-assigned identity cannot tell two resources apart in the logs. Also choose system-assigned when permissions should be removed automatically as the resource is deleted. These two cases are where system-assigned beats the otherwise-recommended user-assigned.

A resource can carry both a system-assigned and user-assigned identity

Resources that support managed identities can have a system-assigned identity and one or more user-assigned identities at the same time. This lets you apply shared permissions through a user-assigned identity while keeping resource-specific permissions on the system-assigned one. The code chooses which identity to use when it requests a token.

Creating a managed identity grants nothing until you assign an RBAC role

A managed identity has no access until you assign it an Azure RBAC role at the scope of the target, for example Storage Blob Data Reader on a storage account. Creating or enabling the identity and granting the role are two separate steps. Skipping the role assignment is the most common cause of a managed-identity call returning 403 Forbidden.

Trap Enabling a managed identity and expecting it to reach the target without a role assignment; with no RBAC role at the target scope the call returns 403.

5 questions test this
Code fetches a managed-identity token from the local IMDS endpoint

Code on an Azure resource gets a Microsoft Entra token by calling the Azure Instance Metadata Service at http://169.254.169.254/metadata/identity/oauth2/token with the header Metadata: true and a resource parameter naming the target audience. The endpoint is link-local and answers only from inside that resource, so no credential leaves the host. Microsoft Entra ID returns a JWT access token, and the SDK's DefaultAzureCredential or MSAL normally makes this call for you.

2 questions test this
Name the client ID when a resource has multiple user-assigned identities

When a resource carries more than one user-assigned identity, a token request must include the client_id (or resource/object ID) of the identity you want, because Azure cannot otherwise tell which one to use. A request that omits it on a multi-identity resource is ambiguous and fails. A single-identity resource needs no client_id.

Trap Omitting client_id when requesting a token on a resource with several user-assigned identities; the request is ambiguous and fails until you specify which identity.

2 questions test this
Managed-identity tokens are cached, so role changes take hours

A managed identity's token is cached by the Azure infrastructure for roughly 24 hours, and group or role-membership claims live inside that token, so changing a managed identity's group or role membership can take hours to take effect and cannot be forced to refresh sooner. To make permission changes apply quickly, assign the role directly to a user-assigned identity instead of adding or removing it from a Microsoft Entra group.

Trap Removing a managed identity from an Entra group to revoke access immediately; the cached token keeps the old claims for hours, so assign permissions directly to the identity when changes must be instant.

Deleting a managed identity leaves its role assignments behind

Role assignments are not removed automatically when a managed identity is deleted; the orphaned assignment shows as Identity not found in the portal and keeps consuming the per-subscription role-assignment limit until you delete it by hand. Cleanup of a managed identity therefore means removing both the identity and its dangling role assignments.

Trap Deleting a managed identity and assuming its role assignments went with it; they remain as Identity not found and still count against the role-assignment limit.

4 questions test this
External workloads use an app registration, not a managed identity

A managed identity only works on an Azure resource, so a workload running outside Azure (GitHub Actions, another cloud, or Kubernetes off Azure) cannot use one. Such a workload authenticates as a service principal from an app registration, and workload identity federation lets it exchange an external token for a Microsoft Entra token with no stored secret. A client secret or certificate is the fallback when federation is not available.

Trap Trying to assign a managed identity to compute that runs outside Azure; managed identities only attach to Azure resources, so an app registration with federation is the credential-free choice.

3 questions test this
Managed identity as a federated credential is capped at 20 per app

A managed identity can act as a federated identity credential (FIC) on a Microsoft Entra application through workload identity federation, which keeps the app credential-free. There is a limit of 20 federated identity credentials when managed identities are used as the FIC on a single Entra application. Beyond that you split across applications.

Virtual Machine Contributor plus Managed Identity Operator to wire an identity to a VM

Enabling a system-assigned identity on a VM (or attaching any identity) needs Virtual Machine Contributor on the VM, with no extra directory role. Attaching a user-assigned identity additionally needs Managed Identity Operator on that identity (it holds the assign/action permission). Creating a user-assigned identity needs Managed Identity Contributor.

Trap thinking Virtual Machine Contributor alone is enough to attach a user-assigned identity

5 questions test this
Key Vault data-plane access needs Key Vault Secrets User and the right permission model

To let a managed identity read secrets, grant the least-privileged data-plane role Key Vault Secrets User (RBAC model) or, under the Vault access policy model, an access policy with Get (and List). RBAC roles such as Key Vault Secrets User only take effect when the vault uses the Azure RBAC permission model; on a vault using access policies they grant nothing and reads return Forbidden.

Trap assigning Owner or Contributor (management-plane) and expecting it to grant data-plane secret reads, or mixing an RBAC role with the access-policy model

6 questions test this
Deleting a user-assigned identity leaves a stale reference on each resource

Deleting a user-assigned managed identity does not remove it from the resources it was assigned to; the stale reference remains on every VM and must be cleaned up manually (for example with az vm identity remove). After deletion the identity can no longer obtain tokens, so dependent code stops authenticating.

Trap expecting the reference to be removed automatically from assigned VMs when the identity is deleted

3 questions test this
Each federated identity credential matches one exact subject; add more or use flexible FIC

Subject matching for a federated identity credential is exact, so one credential trusts exactly one subject (for example repo:org/repo:environment:Production). To trust an additional branch or environment, add another credential; when you hit the 20-credential-per-identity limit, use a flexible federated identity credential whose claims-matching expression covers many subjects with a single credential.

Trap trying to wildcard or list multiple branches inside one ordinary credential's subject value

3 questions test this

Also tested in

References

  1. What are workload identities?
  2. Application and service principal objects in Microsoft Entra ID
  3. Group Managed Service Accounts overview
  4. Managed identities for Azure resources overview
  5. Managed identity best practice recommendations
  6. What is Azure role-based access control (Azure RBAC)?
  7. How managed identities for Azure resources work with Azure virtual machines