AZ-204 Implement Azure security Practice Question
You are developing an ASP.NET Core web API that uses Microsoft Entra ID for authentication via Microsoft.Identity.Web. The application needs to authorize actions based on custom roles such as "Editor" and "Reviewer". These roles are not defined in Microsoft Entra ID app roles or directory roles; instead, they are stored in an application database and can be assigned dynamically by administrators. You need to implement authorization with minimal impact on performance and without modifying the application's authentication flow. Which approach should you use?
⚠ Common exam trap
It's easy for candidates to confuse custom middleware with authorization filters, assuming both run at the same point in the pipeline, but middleware modifies the principal before authorization runs, while filters run after authentication and can cause redundant database calls if not designed carefully.
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 a custom middleware to modify the User principal after authentication, adding role claims from the database
It allows you to add role claims from the application database to the User principal after authentication via custom middleware, without altering the authentication flow. This approach leverages the existing Microsoft.Identity.Web authentication pipeline and caches the role claims in the principal, minimizing performance impact by avoiding repeated database lookups on every request.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Add custom claims to the token via Microsoft Entra ID custom claims policies
Why it's wrong here
Microsoft Entra ID custom claims policies are designed to add claims based on static attributes stored within the directory or linked systems. They are evaluated during token issuance and lack the capability to dynamically query an external application database at runtime to fetch user-specific roles. This approach cannot integrate with application-specific role data that resides outside of Microsoft Entra ID.
- ✗
Implement a custom authorization filter that reads the user's roles from the database on each request and caches them
Why it's wrong here
An authorization filter executes after authentication and targets specific action methods or controllers. While it can retrieve and cache roles from the database, these roles are typically added to the `HttpContext.User` principal for that specific request's scope. This approach doesn't globally enrich the `ClaimsPrincipal` early in the request pipeline, meaning other authorization mechanisms might not consistently see these dynamically added roles without explicit handling in every location.
- ✗
Use Microsoft Entra ID app roles and assign them to users or groups
Why it's wrong here
Microsoft Entra ID application roles (App Roles) are predefined, static roles declared in the application's manifest within Entra ID. Users or groups are then manually assigned to these roles within the Entra ID portal or via Graph API. This mechanism is suitable for managing fixed roles centrally but cannot dynamically retrieve and assign roles based on data stored in an external application database at the time of user authentication or authorization.
- ✓
Use a custom middleware to modify the User principal after authentication, adding role claims from the database
Why this is correct
A custom middleware positioned after authentication middleware but before authorization middleware is ideal for this scenario. It can access the authenticated `ClaimsPrincipal`, query the application database for dynamic roles (with caching for performance), and then add these roles as `ClaimTypes.Role` claims to the principal. This ensures the `ClaimsPrincipal` is fully enriched with application-specific roles early in the request pipeline, making them consistently available for all subsequent authorization checks, including `[Authorize]` attributes and policy-based authorization, without modifying the core authentication process.
Go deeper
Related to this question
About these practice questions
One of 881 original AZ-204 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.