Connect to and consume Azure services and third-party services →mediumMultiple ChoiceObjective-mapped
AZ-204 Practice Question: Connect to and consume Azure services and third-party services
You are building an Azure Logic App that needs to call a third-party REST API. The API requires an API key to be passed in the 'X-API-Key' header. You have stored the API key as a secret in Azure Key Vault. The Logic App uses a managed identity that has read access to the Key Vault secret. You want to retrieve the API key securely at runtime and include it in the HTTP request. Which approach should you use?
⚠ Common exam trap
Watch out — candidates often confuse managed identity authentication on the HTTP action (which sends an Entra ID token) with using a managed identity to authenticate to Key Vault, leading them to select option D, which is technically incorrect for an API key scenario.
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 the 'Get secret' action from the Azure Key Vault connector, configured to authenticate with a managed identity. Then pass the output to the 'HTTP' action's header as 'X-API-Key'.
It uses the Azure Key Vault connector's 'Get secret' action with managed identity authentication to securely retrieve the API key at runtime. The output is then passed directly into the HTTP action's 'X-API-Key' header, ensuring the secret is never exposed in the Logic App definition or logs. This approach follows the principle of least privilege and avoids hardcoding secrets.
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 the 'Get secret' action from the Azure Key Vault connector, configured to authenticate with a managed identity. Then pass the output to the 'HTTP' action's header as 'X-API-Key'.
Why this is correct
This is the correct and most secure approach for handling API keys in Azure Logic Apps. Azure Key Vault is a dedicated service for securely storing secrets, and a Logic App's managed identity provides an automatically managed identity in Microsoft Entra ID. By granting the Logic App's managed identity 'Get' permissions on the specific secret in Key Vault, the 'Get secret' action can retrieve the API key at runtime. This dynamically retrieved value is then passed into the 'HTTP' action's header (e.g., 'X-API-Key'), ensuring the sensitive key is never hardcoded or exposed within the Logic App's definition or deployment artifacts.
- ✗
Create an API connection for the external API, providing the API key in the connection parameters. Then use that connection in the Logic App.
Why it's wrong here
API connections in Logic Apps are primarily designed for pre-built connectors to well-known services or custom connectors that define specific authentication mechanisms like OAuth 2.0 or API Key *as part of the connector definition*. For a generic third-party API expecting a custom header like 'X-API-Key' without a pre-existing connector or a custom connector specifically built for it, creating a generic API connection to inject an arbitrary API key into a custom header is not a standard or supported pattern. The 'HTTP' action provides direct control over headers, making it more suitable for such scenarios.
- ✗
Store the API key directly in the Logic App definition's 'constants' section and reference it in the HTTP action.
Why it's wrong here
Storing sensitive information like API keys directly within the Logic App definition, even in a 'constants' section, is a significant security vulnerability and violates best practices. This practice exposes the secret to anyone with access to the Logic App's definition, potentially through source control, deployment artifacts, or the Azure portal. It compromises the principle of least privilege and secure secret management, making the secret susceptible to compromise and difficult to rotate without redeploying the entire Logic App. Azure Key Vault is the dedicated service for securely managing such credentials.
- ✗
Use the 'HTTP' action with 'Managed Identity' authentication type, and configure the external API to accept Microsoft Entra ID tokens.
Why it's wrong here
While using a managed identity for authentication is a secure practice, it is only applicable when the target service is configured to accept Microsoft Entra ID (formerly Azure Active Directory) tokens. The question explicitly states the external API expects an 'API key' (typically a static string passed in a header or query parameter), not an OAuth 2.0 token issued by Microsoft Entra ID. Configuring the 'HTTP' action with 'Managed Identity' authentication would attempt to acquire and present an AAD token, which the third-party API would not understand or validate, leading to an authentication failure.
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
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.