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 calls an external REST API secured with the OAuth 2.0 client credentials flow. You have registered an app in Microsoft Entra ID with client ID and client secret stored in Azure Key Vault. The Logic App uses a system-assigned managed identity with Get permission on the secret. Which action should you use in the Logic App designer to authenticate to the API?
⚠ Common exam trap
It's easy for candidates to confuse 'Managed Identity' authentication (which works only for Azure resources like Azure SQL or Storage) with the need to authenticate to an external API using OAuth client credentials, leading them to incorrectly select Option B instead of the HTTP action with Active Directory OAuth.
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
✓
HTTP action with 'Active Directory OAuth' authentication type, referencing the client ID and client secret
The OAuth 2.0 client credentials flow requires a client ID and client secret to obtain an access token from Microsoft Entra ID. The HTTP action's 'Active Directory OAuth' authentication type directly supports this flow, allowing you to reference the client ID and the client secret stored in Azure Key Vault. The Logic App's system-assigned managed identity has Get permission on the secret, enabling it to retrieve the secret at runtime without exposing it in the workflow definition.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
HTTP action with 'Active Directory OAuth' authentication type, referencing the client ID and client secret
Why this is correct
This option correctly leverages the "Active Directory OAuth" authentication type within the Logic Apps HTTP action. This type is specifically designed for scenarios where a client application (like a Logic App) needs to obtain an access token from Microsoft Entra ID (formerly Azure AD) using its own identity, rather than on behalf of a user. By providing the client ID and client secret, the Logic App performs the OAuth 2.0 Client Credentials flow, allowing it to authenticate and acquire a token to call the external REST API securely.
- ✗
HTTP action with 'Managed Identity' authentication type
Why it's wrong here
Managed Identity authentication is primarily designed for Azure resources to authenticate to *other Azure services* that support Microsoft Entra ID authentication, without managing credentials directly. While powerful for intra-Azure communication, it is not suitable for authenticating to arbitrary external REST APIs that are not integrated with Microsoft Entra ID or do not recognize Managed Identity tokens. External APIs typically expect specific OAuth 2.0 flows, such as client credentials, with their own registered client IDs and secrets.
- ✗
Invoke an API with OAuth predefined connector
Why it's wrong here
Logic Apps do not feature a generic "Invoke an API with OAuth predefined connector" that automatically handles arbitrary OAuth 2.0 flows for any external API. While Logic Apps offer numerous pre-built connectors for specific services (many of which use OAuth internally), calling a generic external REST API with OAuth requires using the flexible "HTTP" action. Within the HTTP action, you then explicitly configure the desired authentication method, such as "Active Directory OAuth," to manage the token acquisition process.
- ✗
HTTP action with 'Basic' authentication and pass the secret as password
Why it's wrong here
Basic authentication involves sending a username and password (often base64 encoded) directly in the HTTP `Authorization` header. This method is fundamentally different from OAuth 2.0 Client Credentials flow, which involves obtaining a time-limited access token from an identity provider (like Microsoft Entra ID) using a client ID and secret, and then presenting that token to the API. Basic authentication does not leverage Microsoft Entra ID for token issuance and is generally considered less secure and flexible than OAuth 2.0 for modern API integrations.
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
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.