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

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Azure App Configuration to store the secret and the Azure Identity SDK to obtain the token

  Why it's wrong here

  Azure App Configuration is designed for managing application settings and feature flags, not for the secure storage of sensitive secrets like API client secrets. While it can store strings, it lacks the robust security features, access policies, and auditing capabilities inherent to dedicated secret management services. Furthermore, while the Azure Identity SDK can obtain tokens, it typically relies on a secure credential source or managed identity, not a secret directly retrieved from App Configuration for client credentials flow.

• ✗

  Managed identity to access the downstream API directly

  Why it's wrong here

  Managed identities provide an Azure AD identity for Azure resources, enabling them to authenticate to services that support Azure AD authentication without managing credentials. However, this approach is incorrect because the *downstream API* might not be an Azure AD-protected resource or may not support Azure AD authentication directly via a managed identity. The question implies a custom API calling a downstream API, often requiring a client secret for the client credentials flow, which a managed identity alone doesn't directly provide for external, non-Azure AD integrated APIs.

• ✓

  Azure Key Vault to store the secret and MSAL to obtain the token

  Why this is correct

  Azure Key Vault is the recommended and secure service for storing cryptographic keys, certificates, and sensitive secrets like API client secrets. It provides robust access control, auditing, and encryption at rest and in transit, ensuring the secret's confidentiality. The Microsoft Authentication Library (MSAL) is the appropriate SDK for acquiring tokens from Microsoft identity platform, including implementing the client credentials flow where an application uses its own identity (client ID and secret retrieved from Key Vault) to obtain an access token for a downstream API.

• ✗

  Azure Certificate Manager to store the secret and the HttpClient to obtain the token

  Why it's wrong here

  The option refers to "Azure Certificate Manager," which is not a recognized Azure service for storing secrets. While Azure Key Vault does manage certificates, a dedicated "Certificate Manager" service for general secret storage does not exist. Furthermore, directly using `HttpClient` to obtain an access token would require manually implementing the complex OAuth 2.0 client credentials flow, including token caching and refresh logic, which is error-prone and less secure than leveraging a robust authentication library like MSAL.