AZ-204 Implement Azure security Practice Question
Which TWO actions should you take to secure an Azure Function app that is triggered by an HTTP request? (Choose two.)
⚠ Common exam trap
Watch out — candidates often confuse network-level security (like virtual network integration) with application-level authentication, or they mistakenly believe that CORS or shared keys provide sufficient security for HTTP-triggered functions, when in fact Microsoft Entra ID authentication is the recommended approach for identity-based access control in Azure Functions.
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
✓
Enable App Service Authentication and configure Microsoft Entra ID as the identity provider.
Enabling App Service Authentication with Microsoft Entra ID (formerly Azure AD) provides a managed identity layer that validates JWT tokens from Microsoft Entra ID before the request reaches your function code. This ensures only authenticated users or applications can invoke the HTTP-triggered function, offloading token validation and session management from your code. Option C is correct because storing secrets in Azure Key Vault and referencing them via Key Vault references (syntax @Microsoft.KeyVault(SecretUri=...)) in the function app settings prevents hardcoding credentials in configuration files or source code, aligning with the principle of least privilege and secure secret management.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use function-level authorization keys (function or admin keys) for all HTTP triggers.
Why it's wrong here
While function keys provide a basic level of authorization, they are essentially shared secrets that can be compromised if not rotated frequently or if exposed in client-side code or logs. They offer no identity context and are less secure than identity-based authentication mechanisms like Microsoft Entra ID, which provides robust authentication, authorization, and auditing capabilities. Therefore, relying solely on keys is not the most secure approach for protecting an Azure Function.
- ✓
Enable App Service Authentication and configure Microsoft Entra ID as the identity provider.
Why this is correct
Enabling App Service Authentication, often called "Easy Auth," and configuring Microsoft Entra ID as the identity provider is a robust security measure. This offloads authentication to the platform, ensuring that only requests with valid Entra ID tokens are allowed to reach the function code. It provides strong identity-based authentication and authorization, integrating with corporate directories and conditional access policies to secure access.
- ✓
Store connection strings and secrets in Azure Key Vault and reference them from the function app settings using Key Vault references.
Why this is correct
Storing sensitive data like connection strings and API keys directly in function app settings is a security risk as they are stored as plaintext. By utilizing Azure Key Vault, these secrets are encrypted at rest and in transit, with access controlled via Azure RBAC. Key Vault references in function app settings allow the function to securely retrieve these secrets at runtime without ever exposing them in configuration files or environment variables, significantly enhancing security.
- ✗
Set the function app's public access to 'Off' and use virtual network integration.
Why it's wrong here
Setting a function app's public access to 'Off' would prevent any external HTTP requests from reaching the function, effectively blocking all HTTP triggers. While virtual network integration enhances security by allowing the function to access resources within a VNet or be accessed from within a VNet, it doesn't inherently provide a mechanism for *external* HTTP triggers to securely invoke the function when public access is disabled. This action would render HTTP-triggered functions unusable from the internet.
- ✗
Enable Cross-Origin Resource Sharing (CORS) with allowed origins set to '*'.
Why it's wrong here
Enabling Cross-Origin Resource Sharing (CORS) with allowed origins set to '*' permits any domain to make requests to the function from a web browser. While CORS is a browser security mechanism to prevent cross-site scripting, it does not provide authentication or authorization for the function itself. Setting '*' is highly insecure as it removes browser-level protection and does not secure the backend API from unauthorized access; it merely controls which web pages can initiate requests.
Go deeper
Related to this question
Learn chapter
Azure Functions Development
Key term
Key Vault Secrets
Key Vault Secrets are secure containers in Microsoft Azure that store sensitive information like passwords, connection strings, and API keys, keeping them encrypted and accessible only to authorized applications and users.
Key term
Managed identity
A managed identity is an automatically managed service principal in Azure that allows your code to authenticate to any service that supports Azure AD authentication without storing credentials.
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.