Separate identity, credentials and permission
Identity answers which workload is calling. Credentials prove that identity when it requests a token. Authorization determines what the identity can do after authentication. These are separate decisions.
Fast decision rule
Supported workload hosted in Azure: prefer a managed identity. External or multi-tenant application: use an application registration and service principal. Either choice: grant only the required role at the narrowest practical scope.
Managed identity vs service principal
| Decision | Managed identity | Conventional service principal |
|---|---|---|
| Best fit | Supported Azure-hosted workload | Outside Azure, multi-tenant, CI/CD, or unsupported source |
| Credential handling | Azure manages and protects credentials | You configure certificate, secret, or federation |
| Tenant model | Primarily the Azure resource's tenant | Can represent an application in each consenting tenant |
| Lifecycle | System-assigned follows one resource; user-assigned is independent | Independent application/service-principal lifecycle |
| Authorization | Assign Azure RBAC or target data-plane permission | Assign Azure RBAC, app roles, or API permissions as required |
A managed identity is not a bypass around access control. It eliminates exposed workload credentials; it does not automatically grant access to Key Vault, Storage, SQL, or another target.
System-assigned vs user-assigned managed identity
System-assigned: one resource, one linked lifecycle
Enable it directly on a supported Azure resource such as a VM or App Service. Azure creates the identity representation in Microsoft Entra ID. Deleting the resource deletes the identity. This is useful when one workload needs its own isolated permissions.
User-assigned: reusable identity with an independent lifecycle
Create it as a separate Azure resource and attach it to one or more supported workloads. It can be provisioned before compute, preserve role assignments while compute is replaced, and provide a shared identity where the security design permits it. Shared use can simplify deployment but may reduce workload-level attribution, so choose deliberately.
Service principal: tenant-local application identity
An application object describes the application globally in its home tenant. A service principal is the application's local representation in a specific tenant. Automation can authenticate as that service principal with a certificate, client secret, or workload identity federation, depending on the architecture.
If a secret is unavoidable, keep it out of source code, restrict access, set an expiry, monitor usage and rotate it. Prefer certificates over secrets where appropriate, and prefer federation when a supported external platform can exchange a trusted token without storing a long-lived secret.
Worked scenario: App Service reads a private blob container
- Enable identity: attach a managed identity to the App Service.
- Grant data access: assign an appropriate Storage data role at the container or storage-account scope; a management-plane Contributor role alone may not grant blob data access.
- Acquire a token: use Azure Identity/DefaultAzureCredential so production can use the managed identity without an embedded secret.
- Protect the network path: separately configure storage firewall, private endpoint, DNS and application routing if public access is restricted.
- Observe: log sign-ins, role changes and failed requests without exposing tokens.
The identity solves authentication. Azure RBAC solves authorization. Storage networking solves reachability. Treating them as one setting causes slow troubleshooting.
Token acquired, but access is denied: troubleshoot in this order
- Selected identity: confirm the application used the expected system- or user-assigned identity.
- Token audience: request a token for the target service, not Azure Resource Manager by mistake.
- Tenant: verify issuer and tenant match the resource and trust design.
- Role and scope: inspect the exact role definition, assignment principal, subscription/resource group/resource scope, and inherited assignments.
- Control plane vs data plane: choose a data role when the operation reads or writes service data.
- Propagation and token cache: allow for role-assignment propagation and refresh the token before retesting.
- Network controls: a valid identity does not bypass firewalls, private endpoints, DNS, routes, or TLS requirements.
AZ-104 practice checks
An Azure VM needs to read a Key Vault secret without storing a password. What should you choose?
Best answer: enable a managed identity on the VM and grant only the required Key Vault data permission. The identity and permission are separate steps.
A GitHub-hosted build workflow deploys Azure resources. Must it store a client secret?
Best answer: not necessarily. A service principal with workload identity federation can exchange the workflow's trusted OIDC token, avoiding a long-lived secret.
Three replaceable App Service instances must keep the same access identity after redeployment. Which managed identity fits?
Best answer: a user-assigned managed identity, because its lifecycle is independent and it can be attached to multiple supported resources.
Common exam and implementation mistakes
- Calling every service principal a managed identity.
- Embedding a client secret when managed identity or federation is available.
- Assuming identity creation grants permissions.
- Assigning a broad Owner or Contributor role instead of a narrow data role.
- Confusing client ID with principal/object ID.
- Ignoring system-assigned identity deletion when replacing a resource.
- Sharing one user-assigned identity without considering least privilege and attribution.
- Troubleshooting RBAC when a firewall or private DNS path is blocking access.
Frequently asked questions
Is a managed identity a service principal?
A managed identity is represented in Microsoft Entra ID by a special type of service principal, but Azure manages its credentials. A conventional application service principal normally authenticates with a certificate, client secret, or federated credential that you configure.
When should I use a managed identity instead of a service principal?
For a supported workload hosted in Azure, use a managed identity when possible because the application does not store or rotate a client secret. Use a service principal when the workload is outside Azure, multi-tenant, or the source service does not support managed identity.
What is the difference between system-assigned and user-assigned managed identities?
A system-assigned identity belongs to one Azure resource and is deleted with that resource. A user-assigned identity is a separate Azure resource, can be attached to multiple supported resources, and has an independent lifecycle.
Does creating an identity grant access to Azure resources?
No. Authentication establishes which workload is calling. You must separately authorize the identity, commonly with an Azure RBAC role at the narrowest appropriate scope or with the target service's data-plane permissions.
Why does a managed identity receive 403 Forbidden after getting a token?
A successful token proves authentication, not authorization. Check the token audience, tenant, selected identity, role assignment, assignment scope, target service firewall, and propagation time.
Official Microsoft references
Confirm the current exam scope in the official AZ-104 study guide. Review Microsoft Learn guidance for securing service accounts, managed identities, Azure role assignments, and secretless authentication.