AZ-204 Develop Azure compute solutions Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  Using an Azure AD token obtained via DefaultAzureCredential

  Why this is correct

  Azure Functions can authenticate to other Azure services (like Key Vault, Storage, Cosmos DB) using Azure AD tokens. DefaultAzureCredential is part of the Azure Identity client library, providing a chain of credential types that attempt to authenticate in various environments (local development, Azure deployment) using the most appropriate method, such as a developer's logged-in account, environment variables, or a managed identity, ultimately acquiring an Azure AD token. This enables secure, token-based access without hardcoding secrets.

• ✓

  Using a connection string with shared access policy

  Why this is correct

  Many Azure services, such as Azure Storage, Azure Service Bus, and Azure Cosmos DB, support authentication via a connection string. This string typically contains the service endpoint and a Shared Access Key (SAK) or a Shared Access Signature (SAS) token, which grants specific permissions to access the resource. While effective, it's crucial to store connection strings securely, preferably in Azure Key Vault or application settings, to prevent exposure of the underlying keys.

• ✓

  Using a system-assigned managed identity

  Why this is correct

  A system-assigned managed identity provides an Azure Function with an automatically managed identity in Azure Active Directory. This identity can then be granted specific Azure RBAC roles to access other Azure resources, such as Azure Key Vault or Azure Storage, without needing to manage any credentials in the function's code or configuration. It simplifies authentication and enhances security by eliminating the need for developers to handle secrets.

• ✗

  Using a client certificate

  Why it's wrong here

  While client certificates are a valid authentication mechanism in some scenarios, such as mutual TLS for web apps or specific enterprise integrations, they are generally not a standard or directly supported method for an Azure Function to authenticate itself to other Azure services like Azure Storage, Service Bus, or Key Vault. Azure Functions primarily leverage Azure AD, managed identities, or connection strings for outbound authentication to Azure resources, making client certificates an uncommon and often unsupported approach in this context.

• ✗

  Using a SAS key stored in code

  Why it's wrong here

  While a Shared Access Signature (SAS) key can grant granular access to Azure Storage resources, directly embedding a SAS key within the function's code is a significant security anti-pattern. Hardcoding any secret, including a SAS key, makes it difficult to rotate, increases the risk of exposure if the code is compromised, and violates the principle of least privilege. Instead, SAS tokens should be generated on demand, retrieved securely from Key Vault, or managed via connection strings stored in application settings.