Managed Identity Assignment and Resource Access (SC-300)
Why Is Managed Identity Assignment and Resource Access Important?
In modern cloud environments, applications and services constantly need to authenticate to other resources such as Azure Key Vault, Azure SQL Database, Azure Storage, and more. Traditionally, this required storing credentials (passwords, connection strings, certificates) in code or configuration files, which introduced significant security risks including credential leakage, secret sprawl, and difficulty in credential rotation.
Managed identities solve this problem by providing an automatically managed identity in Azure Active Directory (now Microsoft Entra ID) for Azure resources. This eliminates the need for developers to manage credentials at all. Understanding how to assign managed identities and configure resource access is critical for:
• Security posture: Reducing the attack surface by eliminating stored credentials
• Compliance: Meeting organizational and regulatory requirements for secret management
• Operational efficiency: Simplifying identity lifecycle management
• Zero Trust strategy: Implementing least-privilege access for workload identities
What Are Managed Identities?
A managed identity is a special type of service principal in Microsoft Entra ID that is automatically managed by Azure. There are two types:
1. System-Assigned Managed Identity
• Created as part of an Azure resource (e.g., a Virtual Machine, App Service, Azure Function)
• Shares the lifecycle of the resource — when the resource is deleted, the identity is automatically deleted
• Cannot be shared across multiple resources
• Has a 1:1 relationship with the Azure resource
• The identity is tied directly to the resource and is enabled/disabled on the resource itself
2. User-Assigned Managed Identity
• Created as a standalone Azure resource in a resource group
• Has an independent lifecycle — it persists even if the resources using it are deleted
• Can be assigned to one or more Azure resources simultaneously
• Ideal for scenarios where multiple resources need the same permissions
• Must be explicitly created, assigned, and deleted
How Managed Identity Assignment and Resource Access Works
The process follows these key steps:
Step 1: Create or Enable the Managed Identity
For System-Assigned:
Navigate to the Azure resource (e.g., a VM or App Service) → Identity blade → System assigned tab → Toggle Status to On → Save. Azure automatically registers a service principal in Microsoft Entra ID with the same name as the resource.
For User-Assigned:
Create the identity as a standalone resource: Go to the Azure Portal → Search for "Managed Identities" → Create → Specify subscription, resource group, region, and name. Then assign it to one or more resources by navigating to the target resource → Identity blade → User assigned tab → Add → Select the managed identity.
Step 2: Grant the Managed Identity Access to Target Resources (Role Assignment)
Once a managed identity exists, it has no permissions by default. You must assign appropriate roles using Azure Role-Based Access Control (RBAC) or configure access policies depending on the target resource:
• Azure RBAC: Navigate to the target resource (e.g., Storage Account) → Access Control (IAM) → Add role assignment → Select the role (e.g., Storage Blob Data Reader) → Assign access to "Managed identity" → Select the specific identity → Save
• Key Vault Access Policies: Navigate to Key Vault → Access policies → Add access policy → Select permissions (e.g., Get, List for Secrets) → Select the managed identity as the principal → Save
• Key Vault RBAC model: If the Key Vault uses Azure RBAC permission model, assign roles like "Key Vault Secrets User" via IAM
Step 3: Application Uses the Managed Identity to Authenticate
The application code requests a token from the Azure Instance Metadata Service (IMDS) endpoint or the managed identity endpoint. The Azure platform handles token acquisition behind the scenes. The application then presents this token to the target resource for authentication.
When using Azure SDKs with DefaultAzureCredential, managed identity is automatically detected and used when the application runs on an Azure resource with a managed identity assigned.
Step 4: Token Validation and Access
The target resource validates the token with Microsoft Entra ID, checks the role assignments or access policies, and grants or denies access accordingly.
Key Scenarios and Considerations
• Azure Virtual Machines: Both system-assigned and user-assigned managed identities are supported. A VM can have one system-assigned identity and multiple user-assigned identities simultaneously.
• Azure App Service / Functions: Commonly used to access Key Vault secrets, Storage accounts, and databases without storing connection strings.
• Azure Logic Apps, Data Factory, Automation Accounts: All support managed identities for secure resource access.
• Cross-tenant access: Managed identities cannot be used across tenants. They exist only in the home tenant of the subscription.
• Azure Kubernetes Service (AKS): Supports workload identity federation and managed identities for pod-level access to Azure resources.
Comparison: System-Assigned vs. User-Assigned
| Feature | System-Assigned | User-Assigned |
• Creation: System-assigned is enabled on the resource; User-assigned is created as an independent resource
• Lifecycle: System-assigned is tied to the resource; User-assigned is independent
• Sharing: System-assigned cannot be shared; User-assigned can be shared across multiple resources
• Use case: System-assigned is best for single-resource workloads; User-assigned is best for multiple resources needing the same identity/permissions
• Management overhead: System-assigned is lower (automatic cleanup); User-assigned requires explicit management
Best Practices
• Follow the principle of least privilege — assign only the minimum permissions required
• Use user-assigned managed identities when multiple resources need the same access, to simplify management
• Use system-assigned managed identities for isolated workloads where the identity should not outlive the resource
• Regularly review role assignments using Microsoft Entra ID access reviews or Azure RBAC reports
• Prefer managed identities over service principals with client secrets or certificates whenever possible
• Use Azure Policy to enforce the use of managed identities across your organization
Common Target Resources and Roles
• Azure Key Vault: Key Vault Secrets User, Key Vault Crypto User, Key Vault Certificates Officer
• Azure Storage: Storage Blob Data Reader, Storage Blob Data Contributor, Storage Queue Data Contributor
• Azure SQL Database: Configure the managed identity as an Azure AD admin or create a contained database user mapped to the identity
• Azure Service Bus / Event Hubs: Azure Service Bus Data Sender, Azure Event Hubs Data Receiver
• Azure Resource Manager: Reader, Contributor (for managing Azure resources programmatically)
Exam Tips: Answering Questions on Managed Identity Assignment and Resource Access1. Know the differences between system-assigned and user-assigned identities cold. Exam questions frequently test whether you understand lifecycle behavior (system-assigned is deleted with the resource; user-assigned persists), sharing capabilities (only user-assigned can be shared), and when to choose one over the other.
2. Understand that managed identities have NO permissions by default. Creating or enabling a managed identity does not grant it access to anything. You must explicitly configure RBAC role assignments or access policies. If a question describes a scenario where a managed identity cannot access a resource, the likely answer involves adding the correct role assignment.
3. Remember the two-step process: (1) Enable/assign the managed identity on the source resource, and (2) Grant the identity the appropriate role on the target resource. Many questions present scenarios where one of these steps is missing.
4. Pay attention to the specific Azure RBAC roles mentioned. The exam may test whether you know the difference between control plane roles (e.g., Contributor, Reader) and data plane roles (e.g., Storage Blob Data Contributor, Key Vault Secrets User). Managed identities accessing data typically need
data plane roles, not just control plane roles.
5. For Key Vault questions, determine the permission model. If the question mentions "access policies," you configure permissions through Key Vault access policies. If it mentions "Azure RBAC" as the permission model, you assign roles via IAM. The approach differs, and the exam may test this distinction.
6. Watch for cross-tenant scenarios. Managed identities do NOT work across tenants. If a question involves accessing resources in a different tenant, managed identity is likely not the correct answer — consider using a service principal with federated credentials or a multi-tenant application instead.
7. Look for the simplest and most secure solution. When a question asks for the approach that minimizes administrative effort or improves security, managed identities are almost always preferred over service principals with secrets or certificates. The exam favors answers that reduce credential management overhead.
8. Understand DefaultAzureCredential behavior. Questions may reference how applications authenticate. DefaultAzureCredential in Azure SDKs automatically attempts managed identity authentication when running on Azure. If a question mentions an application running on an Azure resource that fails to authenticate, consider whether the managed identity is enabled and has the correct RBAC assignment.
9. Know which Azure services support managed identities. Almost all major Azure compute services support managed identities (VMs, App Service, Functions, Logic Apps, AKS, Container Instances, Data Factory, etc.). If a question mentions a service that supports managed identities, prefer that approach over alternatives.
10. Be careful with "Managed Identity" vs. "Service Principal" terminology. A managed identity IS a type of service principal, but it is automatically managed by Azure. If the question asks about reducing management overhead or eliminating secrets, managed identity is the answer. If the question requires fine-grained control, certificate-based authentication, or multi-tenant scenarios, a regular service principal might be more appropriate.
11. Remember lifecycle implications for cleanup. If a question mentions decommissioning resources and ensuring no orphaned identities remain, system-assigned managed identities are preferred because they are automatically cleaned up. User-assigned identities require manual deletion.
12. Practice scenario-based reasoning. The SC-300 exam often presents a scenario (e.g., "An application running on an Azure VM needs to read secrets from Key Vault without storing credentials") and asks you to select the correct sequence of steps or configuration. Break the scenario down: What is the source resource? What managed identity type is needed? What target resource needs to be accessed? What role or access policy is required?
