AZ-204 Develop for Azure storage 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.

• ✓

  Enable managed identity for the Web App and use DefaultAzureCredential in the application code.

  Why this is correct

  Enabling a system-assigned or user-assigned managed identity for the Azure Web App allows the app to authenticate to Azure Storage without any credentials in code or configuration. The DefaultAzureCredential class from the Azure Identity library automatically detects the managed identity when running in Azure and uses it to obtain a token. You then grant the managed identity the appropriate role (e.g., Storage Blob Data Contributor) on the storage account. This approach is secure, requires no secret management, and is the recommended practice for Azure-hosted applications.

• ✗

  Use the storage account's primary key and store it in the Web App's application settings.

  Why it's wrong here

  Storing the storage account primary key in application settings is a common but less secure practice. The key is a shared secret that grants full access to the storage account, and if the app's configuration is compromised, the key is exposed. It also requires manual rotation. The scenario explicitly asks to avoid storing credentials in code or configuration. Managed identity with DefaultAzureCredential eliminates the need to store any secret, providing better security and manageability. Therefore, using the primary key does not meet the requirement.

• ✗

  Generate a shared access signature (SAS) token and include it in the application configuration.

  Why it's wrong here

  A SAS token is a time-limited credential that grants specific permissions on storage resources. While it is more granular than the account key, it still needs to be stored in configuration and managed for expiration and rotation. The scenario requires avoiding credentials in configuration, and a SAS token is a credential. Managed identity with DefaultAzureCredential avoids storing any credential altogether. SAS tokens are useful for granting limited access to external clients, but they are not the best choice for an Azure-hosted app that can use managed identity.

• ✗

  Create a service principal and store its client secret in Azure Key Vault, then retrieve it at runtime.

  Why it's wrong here

  Using a service principal with a client secret stored in Key Vault is a valid approach, but it still requires managing a secret and adding code to retrieve it from Key Vault. This adds complexity and potential for secret leakage. The Azure Identity library provides DefaultAzureCredential, which can automatically use managed identity when running in Azure, eliminating the need for secrets entirely. For an Azure Web App, managed identity is the most secure and simplest method. Storing secrets in Key Vault is better than hardcoding, but it is not the most streamlined solution for this scenario.

Go deeper

Related to this question