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 must connect to a third-party CRM system using a custom API. The API requires an API key in the header of every request. You need to securely store the API key and reference it in the Logic App. Which approach should you use?

⚠ Common exam trap

Test-takers frequently confuse 'parameter and connection reference' (Option B) as secure because it separates the value from the definition, but it still stores the key in plaintext in the connection resource, whereas Key Vault is the only option that provides encryption and access control via Azure RBAC.

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

✓

Store the API key in Azure Key Vault and reference it with a dynamic expression.

Azure Key Vault provides a secure, centralized store for secrets like API keys, and Logic Apps can reference these secrets at runtime using a dynamic expression (e.g., `@Microsoft.KeyVault(SecretUri=...)`). This avoids exposing the key in plaintext within the Logic App definition or configuration, aligning with Azure security best practices for managed identities and 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.

✗
Store the API key in the Azure Logic App's definition file.
Why it's wrong here
Storing an API key directly in the Azure Logic App's definition file (workflow.json) is a significant security risk. This file is often committed to source control and included in ARM templates, meaning the secret would be exposed in plain text within the repository, deployment history, and potentially in logs, making it easily discoverable and compromised by anyone with access.
✗
Use a parameter and a connection reference in the Logic App.
Why it's wrong here
While parameters can externalize values from the workflow definition, they still require the secret value to be supplied during deployment, typically via ARM template parameters or environment variables, which doesn't inherently secure the secret's storage location. Connection references are primarily for managed connectors and store credentials within the Azure resource, but for a custom HTTP action requiring an API key, this approach doesn't directly provide a secure, centralized mechanism for the key itself without additional secure storage.
✓
Store the API key in Azure Key Vault and reference it with a dynamic expression.
Why this is correct
Azure Key Vault is the industry-standard service for securely storing and managing secrets, keys, and certificates. By storing the API key in Key Vault, it benefits from encryption at rest, robust access policies (Azure RBAC), and auditing. Logic Apps can then securely retrieve this secret at runtime using a dynamic expression like `@keyVault('secretName')` or `@keyVault('secretUri')`, ensuring the secret is never exposed in the Logic App's definition, source control, or logs.
✗
Hardcode the API key in the HTTP action.
Why it's wrong here
Hardcoding the API key directly within the HTTP action's configuration in the Logic App designer or its underlying JSON definition is a severe security vulnerability. This embeds the secret directly into the workflow, making it visible to anyone with access to the Logic App's definition, deployment artifacts, or even potentially runtime logs. It also complicates key rotation and increases the risk of accidental exposure, violating fundamental security principles.

Go deeper

AZ-204 Practice Question: Connect to and consume Azure services and third-party services

Why each option matters

Option-by-option breakdown

Related to this question