AZ-204 Develop Azure compute solutions Practice Question
You are building a serverless API using Azure Functions. The API must authenticate requests using Microsoft Entra ID. You need to restrict access to users from a specific Microsoft Entra tenant only. What should you configure in the function app?
⚠ Common exam trap
Many candidates confuse 'Client ID' (which identifies the app) or 'Allowed Token Audiences' (which validates the audience) with tenant restriction, but only the Issuer URL enforces which tenant's tokens are accepted.
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
✓
Set the 'Issuer URL' to the specific tenant's endpoint.
Setting the 'Issuer URL' to the specific tenant's endpoint (e.g., https://login.microsoftonline.com/{tenant-id}/v2.0) tells Azure Functions to validate that the token was issued by that exact tenant. This restricts access to users from that tenant only, as tokens from other tenants will fail issuer validation.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Set the 'Allowed Token Audiences' to the application ID.
Why it's wrong here
Setting the 'Allowed Token Audiences' to the application ID validates the 'aud' claim within the JWT, ensuring the token is intended for your specific application. However, this validation does not restrict which Microsoft Entra ID tenant issued the token. An attacker could potentially issue a token from a different tenant that also targets the same application ID, and it would still pass the audience validation, failing to achieve tenant-specific restriction.
- ✗
Enable 'Require Authentication' and set the action to 'Login with Microsoft Entra ID'.
Why it's wrong here
Enabling 'Require Authentication' and setting the action to 'Login with Microsoft Entra ID' configures the Azure Function's Easy Auth feature to enforce authentication using Microsoft Entra ID. This ensures that only authenticated users can access the API. However, by default, this setting accepts tokens issued by *any* Microsoft Entra ID tenant where your application is registered, meaning it does not inherently restrict access to users from a *specific* tenant.
- ✗
Set the 'Client ID' to the application ID.
Why it's wrong here
Setting the 'Client ID' to the application ID correctly identifies your application within the authentication flow. The Client ID (also known as Application ID) is used by identity providers to know which application is requesting a token or which application a token is intended for. While essential for the authentication process, it identifies the target application, not the specific Microsoft Entra ID tenant that issued the token, making it insufficient for tenant restriction.
- ✓
Set the 'Issuer URL' to the specific tenant's endpoint.
Why this is correct
Setting the 'Issuer URL' to the specific tenant's endpoint is the correct method for restricting access to a single Microsoft Entra ID tenant. The 'iss' (issuer) claim in a JWT identifies the security token service (STS) that issued the token. By configuring the Azure Function's authentication settings to validate against a specific tenant's issuer URL (e.g., `https://login.microsoftonline.com/<tenant-id>/v2.0`), the function will only accept tokens originating from that precise tenant, effectively enforcing tenant-specific access control.
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 Development
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
This AZ-204 question is part of Courseiva's 881-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.