AZ-204 Develop Azure compute solutions Practice Question
You are building a serverless API using Azure Functions. The API must authenticate callers by validating a JWT access token issued by Microsoft Entra ID before executing any business logic. You want to enforce this validation across all HTTP-triggered functions without duplicating token-parsing code in each function. What should you implement?
⚠ Common exam trap
The trap here is assuming that API keys or manual JWT decoding provide the same security as platform-level token validation, when only the built-in authentication provider verifies signature and claims.
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
✓
Configure the function app's authentication settings to use the Microsoft Entra ID provider and require authentication for incoming requests.
App Service Authentication integrates with Microsoft Entra ID to validate JWTs at the platform layer before requests reach function code. It checks signature, issuer, audience, and expiration, and it rejects unauthenticated requests with 401. Because the validation is centralized, no per-function token-parsing code is needed, directly meeting the requirement for consistent authentication across all HTTP-triggered functions.
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 a function-level API key requirement by setting the authLevel property to 'function' on every HTTP trigger.
Why it's wrong here
Function-level API keys are shared secrets, not JWT tokens issued by Microsoft Entra ID. They provide no user identity, no claims, and no token lifetime or audience validation. Setting authLevel to 'function' simply requires a key in the request, which does not satisfy the requirement to validate a Microsoft Entra ID JWT access token.
- ✗
Store the JWT in Azure Key Vault and configure the function app to retrieve it via a managed identity at startup.
Why it's wrong here
Azure Key Vault stores secrets, not incoming caller tokens. The token is presented per request by the client and cannot be pre-stored in Key Vault. Retrieving a secret at startup does nothing to validate the caller's JWT on each request, so the API would remain unauthenticated and fail to enforce Microsoft Entra ID token validation.
- ✓
Configure the function app's authentication settings to use the Microsoft Entra ID provider and require authentication for incoming requests.
Why this is correct
App Service Authentication (Easy Auth) validates the token at the platform level before the request reaches your function code. It handles JWT signature validation, issuer and audience checks, and returns 401 for unauthenticated calls. This centralizes authentication and removes the need to parse tokens in every function, satisfying the requirement without duplicated logic.
- ✗
Create a custom middleware binding that decodes the JWT and checks the exp claim before each function execution.
Why it's wrong here
Manually decoding the JWT and checking the exp claim does not validate the token's signature, issuer, or audience. An attacker could forge a token with a future expiration. This approach also requires custom code in the function pipeline and does not leverage the platform's built-in token validation, leaving the API vulnerable to tampered tokens.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
Learn chapter
Azure Functions Flex Consumption Plan
Key term
Azure Functions Bindings
Azure Functions Bindings are declarative connections that link your serverless function code to Azure services or external resources, handling input and output data automatically without writing extra networking or authentication code.
Key term
Durable Functions
Durable Functions is an extension of Azure Functions that lets you write stateful workflows in code, managing complex sequences of tasks, retries, and delays automatically.
About these practice questions
One of 883 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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Microsoft exam blueprint
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.