Implement Azure security →mediumMultiple ChoiceObjective-mapped

AZ-204 Implement Azure security Practice Question

A background service must call Microsoft Graph without a signed-in user. Which Microsoft identity platform permission model is required? The team wants the control to be enforceable during normal operations.

⚠ Common exam trap

A common mix-up: candidates confuse delegated permissions (which require a user) with application permissions (which do not), and mistakenly choose the device code flow thinking it works without a user, when in fact it still requires interactive user authentication.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Application permissions with client credentials flow

The scenario requires an unattended background service to call Microsoft Graph without a signed-in user. Application permissions, combined with the client credentials flow (OAuth 2.0 grant type), allow the service to authenticate as itself using a client ID and client secret or certificate, obtaining an access token with pre-authorized application-level permissions. This model enforces control during normal operations because the permissions are granted directly to the application and cannot be delegated by a user, ensuring consistent access regardless of user presence.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Password hash synchronization
Why it's wrong here
Password Hash Synchronization (PHS) is a method used by Azure AD Connect to synchronize user identities, specifically their password hashes, from an on-premises Active Directory to Azure Active Directory. It is an identity synchronization mechanism, not an authentication flow or an API permission model. PHS does not provide a means for an application to acquire an access token to call Microsoft Graph, nor does it define how permissions are granted to an application.
✗
Delegated permissions only
Why it's wrong here
Delegated permissions are designed to allow an application to act on behalf of a signed-in user. When an application uses delegated permissions, it operates with the permissions granted to the user, limited by the permissions the application itself has been granted. Since the question explicitly states the background service must operate 'without a signed-in user,' delegated permissions are inappropriate because they inherently require a user context for authentication and authorization.
✗
Device code flow
Why it's wrong here
The Device Code Flow is designed for user authentication on devices with limited input capabilities, such as smart TVs or IoT devices. It requires a user to visit a separate web browser on another device, enter a code, and sign in to authorize the application. This flow explicitly involves user interaction and a signed-in user context, making it unsuitable for a background service that must operate autonomously without any user present or involved in the authentication process.
✓
Application permissions with client credentials flow
Why this is correct
For a background service operating without a signed-in user, application permissions are essential as they allow the application itself to call Microsoft Graph. The client credentials flow is the appropriate OAuth 2.0 grant type for this scenario, enabling the application to authenticate using its own client ID and secret or certificate to acquire an access token. This token represents the application's identity, allowing it to perform actions based on the administrator-consented permissions, independent of any user context.

Go deeper

AZ-204 Implement Azure security Practice Question

Why each option matters

Option-by-option breakdown

Related to this question