AZ-204 Implement Azure security 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.

• ✗

  Store the Service Bus connection string in the function app settings

  Why it's wrong here

  Storing the Service Bus connection string directly in the function app settings is a significant security vulnerability. This method embeds sensitive credentials directly into the application configuration, making them susceptible to exposure if the application settings are ever compromised or improperly accessed. It completely bypasses best practices for secure secret management and rotation, increasing the risk of unauthorized access to the Service Bus namespace.

• ✗

  Create a Key Vault reference to the connection string

  Why it's wrong here

  While Azure Key Vault is a robust solution for securely storing secrets, creating a Key Vault reference to a connection string still involves managing a secret, albeit in a more secure location. The function app would still need permissions to access Key Vault, which ideally would be granted via a Managed Identity. However, the connection string itself remains a secret that requires lifecycle management, rotation, and careful access control within Key Vault, which is less ideal than direct authentication.

• ✓

  Enable system-assigned managed identity on the function app and assign the 'Azure Service Bus Data Receiver' role to the identity

  Why this is correct

  Enabling a system-assigned managed identity on the function app and assigning the 'Azure Service Bus Data Receiver' role is the most secure and recommended approach. This method allows the Azure Function to authenticate directly with Azure Active Directory (Azure AD) and subsequently authorize against Azure Service Bus without needing any connection strings, keys, or secrets stored within the function app or Key Vault. Azure automatically manages the identity's lifecycle, eliminating the burden of credential management and rotation for developers.

• ✗

  Use the Service Bus SDK with a SharedAccessSignatureToken

  Why it's wrong here

  Using the Service Bus SDK with a SharedAccessSignatureToken (SAS token) requires generating, storing, and managing a secret. Although SAS tokens offer granular control over permissions and have an expiry, they are still credentials that must be securely handled, rotated before expiration, and protected from unauthorized disclosure. This approach introduces operational overhead and potential security risks if the tokens are compromised or not managed diligently, unlike the secret-less authentication provided by Managed Identities.

Go deeper

Related to this question