Managed identity
Answer: A managed identity gives a supported Azure resource a Microsoft Entra service principal whose credentials are managed by Azure, avoiding application secrets in code or configuration.
Administrator playbook
Decide, verify, and document
Use the curated answer as a starting point, then prove the outcome against the target tenant or device.
What it means
- System-assigned identity lifecycle follows one Azure resource
- User-assigned identities are reusable Azure resources
- The identity still appears in Entra as a service principal and must receive resource access
What to check next
- Choose system-assigned versus user-assigned based on lifecycle and reuse
- Grant only the required Azure role or application permission
- Confirm the application requests tokens for the intended resource
Verify success
- Confirm the object type and identifier in the authoritative tenant.
- Compare the portal value with Microsoft Graph or the local device state.
- Use IDs—not display names—when proving that two references point to the same object.
Escalate when
- Two portals or APIs return conflicting identifiers for the same expected object.
- The issue crosses tenant or cloud boundaries.
- A production authorization decision depends on the object relationship.
Copyable admin briefAnswer, next checks, source, and review date
Inspect Microsoft Graph context
Get-MgContext | Select-Object ClientId,TenantId,Account,AuthType,ScopesRead-only. Useful when a term or identifier is being interpreted in the wrong tenant.
Evidence to preserve
- Credential owner
- Azure
- Directory object
- Service principal
- Types
- System-assigned and user-assigned
- Tenant ID and cloud
- Object type and object ID
- User, app, or device context
- Where the value was observed