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 call a third-party REST API secured with OAuth 2.0 Client Credentials flow. The client ID and client secret are stored in Azure Key Vault. You need to securely obtain an access token and include it in requests to the API. Which approach should you use in the Logic App?
⚠ Common exam trap
Many candidates think a custom connector (Option B) is the correct way to handle OAuth 2.0, but they overlook that storing the secret in the connector definition is not secure and that managed identities with Key Vault provide a more robust and auditable solution.
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 a system-assigned managed identity for the Logic App, grant it access to Key Vault, use the 'Get secret' action to retrieve the client secret into a variable, then use the HTTP action with 'Active Directory OAuth' authentication referencing that variable for the secret.
It securely retrieves the client secret from Azure Key Vault at runtime using a managed identity, avoiding any hardcoded secrets. The Logic App's system-assigned managed identity is granted access to Key Vault, then the 'Get secret' action fetches the secret into a variable, which is passed to the HTTP action's 'Active Directory OAuth' authentication. This approach follows the principle of least privilege and eliminates secret exposure in connection definitions or source code.
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 HTTP action with 'Active Directory OAuth' authentication and hardcode the client secret in the connection parameters.
Why it's wrong here
Hardcoding client secrets directly within the HTTP action's connection parameters is a severe security vulnerability. This exposes the secret in plaintext within the Logic App's definition, making it visible to anyone with access to the workflow code or configuration. Such a practice violates fundamental security principles, complicates secret rotation, and makes auditing difficult, significantly increasing the risk of unauthorized access.
- ✗
Create an Azure API connection (custom connector) with the OAuth 2.0 settings and store the secret in the connector's definition.
Why it's wrong here
While Azure custom connectors provide a mechanism to encapsulate API calls, storing the OAuth 2.0 client secret directly within the connector's definition means it is managed outside of Azure Key Vault. This approach bypasses Key Vault's centralized secret management, robust access control policies, and comprehensive auditing capabilities. Consequently, secret rotation and lifecycle management become more complex and less secure compared to leveraging Key Vault for sensitive credentials.
- ✓
Enable a system-assigned managed identity for the Logic App, grant it access to Key Vault, use the 'Get secret' action to retrieve the client secret into a variable, then use the HTTP action with 'Active Directory OAuth' authentication referencing that variable for the secret.
Why this is correct
This approach uses managed identity to securely access Key Vault, and the secret is passed at runtime without being exposed in the workflow definition. The HTTP action's OAuth authentication can use a variable for the client secret.
- ✗
Store the client secret in an Azure App Service application setting and reference it in the Logic App via a connector.
Why it's wrong here
Logic Apps do not possess a native, direct mechanism to retrieve application settings from an Azure App Service. Even if an indirect method were contrived, storing sensitive client secrets in App Service application settings, while encrypted at rest, lacks the dedicated security features of Azure Key Vault. Key Vault offers superior granular access control, secret versioning, and audit logging, making App Service settings an inferior and less secure choice for managing Logic App credentials.
Go deeper
Related to this question
Learn chapter
Azure Functions Development
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.
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.
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.