AZ-204 Implement Azure security Practice Question
You are designing an ASP.NET Core web API that authenticates users via Microsoft Entra ID. The application needs to authorize access to resources based on custom roles (e.g., 'Admin', 'Editor') that are not defined in Microsoft Entra ID app roles or groups. The role mappings are dynamic and stored in an application database. How should you implement authorization in the API?
⚠ Common exam trap
Watch out — candidates often assume Entra ID app roles or groups are the only way to implement role-based authorization, overlooking the flexibility of the OnTokenValidated event to inject custom claims from external sources.
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
✓
Use the OnTokenValidated event in OpenID Connect middleware to query the database and add custom role claims to the identity.
It uses the OnTokenValidated event in OpenID Connect middleware to enrich the user's identity with custom role claims from the application database after token validation. This approach allows dynamic role mappings stored externally to be injected into the ClaimsPrincipal, which can then be evaluated by the standard [Authorize] attribute with role policies. It avoids modifying Entra ID configuration and keeps role management flexible within the application.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Define the roles as Microsoft Entra ID app roles and assign them to users. This is the standard way to handle roles.
Why it's wrong here
Defining roles as Microsoft Entra ID app roles is suitable for static, pre-defined roles managed by an administrator within the Entra ID tenant. However, this approach is fundamentally incompatible with the scenario's requirement for dynamic, application-specific roles stored in a database. App roles are configured in the application manifest and assigned to users or groups, meaning they would not reflect real-time changes or roles managed exclusively by the application's internal data store, and thus would not appear in the token as needed.
- ✓
Use the OnTokenValidated event in OpenID Connect middleware to query the database and add custom role claims to the identity.
Why this is correct
The OnTokenValidated event in the OpenID Connect middleware is the correct extension point for this scenario. This event fires after the identity token has been successfully validated but before the ClaimsPrincipal is fully constructed and attached to the HttpContext. Within this event, the application can query its internal database using the authenticated user's identifier, retrieve their dynamic roles, and then add these roles as custom claims to the user's ClaimsIdentity. This approach seamlessly integrates dynamic roles into the standard claims-based authorization model.
- ✗
Store the roles in the Microsoft Entra ID token by customizing the token issuance in Microsoft Entra ID.
Why it's wrong here
Storing roles directly in the Microsoft Entra ID token by customizing its issuance is not feasible for dynamic, application-specific roles. Token customization in Microsoft Entra ID, such as through application manifest modifications or custom claims providers, is a static configuration applied at the tenant level. It cannot be dynamically altered by an application on a per-request or per-user basis to reflect roles managed in an external database, making it unsuitable for roles that change frequently or are application-specific.
- ✗
Use the [Authorize] attribute with a custom authorization filter that checks the database on every request without modifying the claims.
Why it's wrong here
Using a custom authorization filter that queries the database on every request without modifying claims is technically possible but highly inefficient and deviates from best practices. This method would introduce significant performance overhead due to repeated database lookups for every authorized endpoint call, rather than performing a single lookup during token validation. Furthermore, it bypasses the robust and declarative claims-based authorization model, making it harder to define and manage authorization policies consistently across the application.
Go deeper
Related to this question
About these practice questions
Courseiva writes every AZ-204 question from scratch — 881 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-204 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-204 exam.