Microsoft 365 Certified: Administrator ExpertImplement and manage Microsoft Entra IDHard
A company uses Microsoft Entra ID for identity management. They have a custom line-of-business application that needs to access user profiles and group memberships in Microsoft Entra ID. The application runs as a background service and does not have a signed-in user. You need to grant the application the necessary permissions to access Microsoft Entra ID resources securely. What type of identity should you create and configure for this application?
- AA guest user account with global administrator role
- BA managed identity for Azure resources
- CA service principal with application permissions
- DA user account with delegated permissions
Show answer & explanationAnswer & explanation
Correct answer: C. A service principal with application permissions
For a background service application that needs to access Microsoft Entra ID resources without a signed-in user, a service principal with application permissions is the correct choice. Application permissions allow the application to act as itself, not on behalf of a user, and can be granted directly to the service principal.
Why the other options are wrong
- A. A guest user account is for external collaborators, and assigning a Global Administrator role is a severe security risk and inappropriate for an application.
- B. Managed identities are for applications running on Azure resources (e.g., Azure VM, App Service), not for general custom line-of-business applications that might run anywhere.
- D. Delegated permissions require a signed-in user account to act on behalf of that user, which is not suitable for a background service without a user.
Service Principal for Applications
A security identity that represents an application in a specific Microsoft Entra tenant. It defines what the application can do in that tenant, which users can access it, and what resources it can access.
- Represents the application itself, not a user.
- Used for applications that need to authenticate and access resources without a user context (e.g., background services, daemons).
- Permissions granted to a service principal are 'application permissions'.
- Each application has one application object (global) and one or more service principals (tenant-specific).
Memory trick: Service Principal: Service Power, No User Required.