SC-300 - Plan and Implement Workload Identities - Section 3.1

Plan and implement identities for applications and Azure workloads using managed identities and service principals.

Compare managed identities and service principals for authenticating Azure workloads and apps without storing credentials. Choose between system-assigned and user-assigned managed identities based on lifecycle requirements, and recognise when managed service accounts are appropriate for on-premises scenarios.

managed identitiesservice principalssystem-assigned and user-assigned identitiesmanaged identity for Azure resourcesmanaged service accounts

Practice question for this objective

Free samplePlan and Implement Workload Identitiesmedium

A platform team runs a fleet of virtual machines and Azure Functions that must all authenticate to the same storage account and Azure SQL database with one identity, so that a single role assignment grants access to every workload. They also want to provision the identity and grant its permissions before any of the compute resources exist. Which workload identity meets these requirements?

  • AA separate system-assigned managed identity enabled on each virtual machine and function, with the same role assignment repeated for every identity.
  • BA single user-assigned managed identity created first, granted the required roles, then attached to each virtual machine and function. Correct
  • CAn app registration shared across the workloads, with its client secret distributed to each virtual machine and function for authentication.
  • DA workload identity federation trust on each function and virtual machine that maps to one external service principal in another tenant.
A user-assigned managed identity has an independent lifecycle, can be created before resources exist, and can be shared across many Azure resources with a single role assignment. A user-assigned managed identity is a standalone Microsoft Entra resource that lives independently of any compute. Because it exists on its own, it can be created and granted Azure role-based access control permissions before the virtual machines or functions are deployed, and the same identity can be attached to many resources. That lets one identity and one role assignment serve the whole fleet, which a per-resource system-assigned identity cannot do, and avoids the shared secret an app registration would require.

Why A is wrong: System-assigned identities are unique per resource and cannot be shared, so the team would manage many identities and many role assignments rather than one, and none can exist before its resource.

Why B is correct: A user-assigned managed identity is a standalone object that can be created and granted roles before any compute exists, then assigned to many resources so one identity and one role assignment cover the whole fleet.

Why C is wrong: An app registration can be shared, but distributing a client secret to every workload reintroduces credential management and rotation, which managed identities are designed to remove.

Why D is wrong: Workload identity federation establishes trust for external workloads to use a service principal without secrets, but it does not provide one shared Azure identity provisioned ahead of the compute resources for an internal fleet.

See more SC-300 practice questions, answers explained.

More in this domain

Back to all Plan and Implement Workload Identities objectives, or the SC-300 cert hub.

Examworthy is not affiliated with or endorsed by Microsoft. Original, blueprint-aligned practice material only.