AZ-204 Develop Azure compute solutions Practice Question
You are building a serverless API using Azure Functions. The API must be secured with OAuth 2.0 and must support both user authentication and application permissions. You need to configure the function app appropriately. Which TWO steps should you take?
⚠ Common exam trap
Many exam-takers think enabling EasyAuth (Option E) alone is sufficient for OAuth 2.0 support, but it only handles token validation and does not configure the required scopes and app roles in the app registration.
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
✓
Expose scopes and app roles in the Microsoft Entra ID app registration.
Option D is correct because the function app must first be registered in Microsoft Entra ID (Azure AD) to obtain an application identity, which is required for OAuth 2.0 tokens to be issued and validated for the API. Option A is correct because exposing scopes (delegated permissions for user authentication) and app roles (application permissions for client credentials/daemon scenarios) in that app registration is exactly how you declare the permissions the API supports for both user and application access. Option B is incorrect because Microsoft Entra ID v1.0 endpoints lack support for some modern OAuth 2.0 features and dynamic consent needed here; v2.0 endpoints are recommended. Option C is incorrect because the portal Authentication blade configures platform-level auth settings, not the OAuth 2.0 scope/role definitions required for both user and application permissions. Option E is incorrect because EasyAuth handles authentication at the App Service layer but does not by itself define the scopes and app roles needed to support both user authentication and application permissions.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Expose scopes and app roles in the Microsoft Entra ID app registration.
Why this is correct
Exposing scopes and app roles within the Microsoft Entra ID application registration is a critical step for defining the permissions available for your API. Scopes represent delegated permissions, allowing client applications to request specific access on behalf of a user, while app roles define application permissions for daemon clients or assignable roles for users within the application itself. This granular definition ensures that only authorized clients and users can perform specific actions against your serverless API, enforcing the principle of least privilege.
- ✗
Use Microsoft Entra ID v1.0 endpoints.
Why it's wrong here
Using Microsoft Entra ID v1.0 endpoints is an outdated practice for new application development. The Microsoft identity platform v2.0 endpoints offer enhanced capabilities, including support for personal Microsoft accounts, incremental consent, and adherence to modern OpenID Connect and OAuth 2.0 standards. Relying on v1.0 endpoints would lead to a less flexible and potentially less secure authentication implementation, as v1.0 is considered deprecated and lacks the full feature set of the current platform.
- ✗
Configure authentication via the 'Authentication' blade in the portal.
Why it's wrong here
Configuring authentication via the 'Authentication' blade in the Azure portal primarily enables Azure App Service's built-in authentication/authorization (EasyAuth) for the function app itself. While EasyAuth can integrate with Microsoft Entra ID, this step focuses on securing access *to* the function app's endpoint for users or applications. It does not directly involve defining custom OAuth 2.0 scopes or app roles that *other client applications* would use to call *your API* with specific permissions, which is central to a custom OAuth configuration for an API.
- ✓
Register the function app in Microsoft Entra ID.
Why this is correct
Registering the function app in Microsoft Entra ID is the foundational step for securing it with OAuth 2.0. This process creates an application identity within your tenant, providing essential credentials such as the `Application (client) ID` and `Tenant ID`. These identifiers are indispensable for any client application to initiate an OAuth 2.0 flow, allowing Entra ID to recognize and authenticate the function app as a protected resource and issue tokens for authorized access.
- ✗
Enable Azure App Service built-in authentication (EasyAuth).
Why it's wrong here
Enabling Azure App Service built-in authentication, also known as EasyAuth, provides a convenient, low-code solution for securing web apps and APIs by offloading authentication to the platform. However, while useful for securing the function app's access, it's not the primary mechanism for *defining* and *exposing* custom OAuth 2.0 permissions (scopes and app roles) that external client applications would use to call the API. EasyAuth primarily *consumes* identity, rather than *defining* the API's specific authorization contract for external consumers.
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
Certificate-Based Authentication in Azure
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 883-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.