What's changed: Created SC-300 Chapter 4 (Domain 3: workload identity selection/managed identities (system/user-assigned)/service principals/gMSA; enterprise apps (SSO/Application Proxy/app-role assignment/consent policies/admin consent workflow); app registrations (redirect URIs/secret-certificate-federated credentials/delegated-application permissions/app roles); Defender for Cloud Apps (cloud discovery/Cloud app catalog/OAuth app policies/CA app control/access-session policies)).
4.1Choosing workload identities and managed identities
Understand choosing the right identity for apps and Azure workloads (managed identities, service principals, user accounts, managed service accounts), and creating/assigning managed identities and using them to access other resources.
Not only people—apps and services (workloads) need identities. The access administrator selects identities that run with least privilege and no embedded keys, lowering leakage risk.
4.1.1Choosing a workload identity
For workloads running on Azure resources, prefer managed identities first—Azure manages the credentials, distributing no keys. The entity representing an app in Entra is a service principal (an instance of an app registration). Reusing a human user account for a service is an anti-pattern to avoid. On-prem AD services use group managed service accounts (gMSA), etc. For "access from an Azure resource to other resources without keys," managed identity is the rule.
4.1.2System-assigned vs user-assigned managed identities
Managed identities come in two kinds. System-assigned is tied 1:1 to a resource (e.g., a VM) and is deleted with it (for a single resource). User-assigned is created as a standalone resource and can be shared across multiple resources (for using the same identity across several VMs/functions). After creation, assign it to the resource and grant an RBAC role (e.g., Key Vault Secrets User) on the target—then code accesses without embedded keys.
Cues: "from an Azure resource to others without keys" = managed identity. "share the same identity across resources" = user-assigned managed identity. "tied to a single resource with automatic lifecycle" = system-assigned. "the entity representing an app in Entra" = service principal. Do not use human accounts for services.
Watch the mix-ups: (1) Managed identity (Azure-managed credentials, keyless) vs service principal (general app identity that may hold secrets/certs). (2) System-assigned (1:1, auto-deleted) vs user-assigned (shareable, independent lifecycle). (3) Do not repurpose user accounts for services.
4.1.3Section summary
- Prefer managed identities (keyless) for Azure workloads; the app entity is a service principal; do not use user accounts for services
- System-assigned = 1:1/auto-deleted; user-assigned = shared across resources; grant least privilege via RBAC
- On-prem services use gMSA, etc.
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. An app on an Azure VM must access Key Vault secrets without embedding credentials in code. Which is best?
Q2. You want several VMs and function apps to share the "same identity" to access resources. Which is best?
Q3. You want an identity tied to a single VM that is automatically deleted when the VM is deleted. Which is best?
Q4. Which correctly relates service principals and managed identities?
Q5. What is the best reason to avoid repurposing a human user account for a service?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.