The scenario describes an application that runs as a service without user interaction, often referred to as a daemon or background service. For such applications to access a protected API like Microsoft Graph, they must use application permissions. These permissions are granted directly to the application's identity (its service principal) by an administrator. The application authenticates using its own credentials (like a client secret or certificate) and receives an access token that is not associated with any user. This is the correct model for non-interactive, server-to-server scenarios.

B. delegated permissions: These are incorrect because they require a signed-in user to be present. The application would be acting on behalf of that user, and the scenario explicitly states the app runs "without user interaction."

C. a custom role-based access control (RBAC) role: This is incorrect. Microsoft Entra RBAC roles grant permissions to manage Microsoft Entra resources, but the primary mechanism for an app to be authorized for an API call is through API permissions.

D. a built-in role-based access control (RBAC) role: This is incorrect for the same reason as custom RBAC roles. While a service principal can be assigned a role, the authorization to call the Microsoft Graph API is governed by the granted API permissions.

1. Microsoft Entra ID documentation

"Permission types": "Application permissions are used by apps that run without a signed-in user present; for example

apps that run as background services or daemons. Application permissions can only be consented to by an administrator."

Source: Microsoft Learn

Permissions and consent in the Microsoft identity platform

Section: "Permission types".

2. Microsoft Graph documentation

"Permissions overview": "For scenarios without a signed-in user

the app can be granted application permissions... Application permissions are also known as app-only access. The app is authorized to call the API based on the permissions that have been granted directly to the app by an administrator."

Source: Microsoft Learn

Microsoft Graph permissions overview

Section: "Permission types".

3. Microsoft Entra ID documentation

"Microsoft identity platform and the OAuth 2.0 client credentials flow": This document details the authentication flow for service-to-service calls. "In the client credentials flow

permissions are granted directly to the application itself. When the app presents a token to a resource

the resource enforces that the app itself has authorization to perform an action since there is no user involved in the authentication."

Source: Microsoft Learn

Microsoft identity platform and the OAuth 2.0 client credentials flow

Section: "Protocol diagram".