SC-300 - Plan and Implement Workload Identities (25% of the exam) - 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.

Exam traps in Plan and Implement Workload Identities

Answers that look right on this material and are not. Each one is a distractor from a different question in the SC-300 bank for this domain.

  • A separate system-assigned managed identity enabled on each resource, with the database role granted individually to each generated identity.

    Why it is wrong: System-assigned managed identities are tempting because they also avoid stored secrets, but each is bound to a single resource and cannot be shared, forcing two separate role assignments rather than one.

  • A system-assigned managed identity for the on-premises server, enabled from the Microsoft Entra admin centre against the server object.

    Why it is wrong: Managed identities are available only for resources hosted in Azure, so a system-assigned managed identity cannot be enabled for an on-premises server and is not an option here.

  • A user-assigned managed identity created in a resource group, then attached to the virtual machine so the application can request tokens for Key Vault.

    Why it is wrong: A user-assigned managed identity has an independent lifecycle and is not deleted with the virtual machine, so it leaves a standalone object to clean up, which the requirement forbids.

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