AZ-500 Secure compute, storage, and databases 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 connection string in the web.config file with encryption.

  Why it's wrong here

  Storing a connection string in web.config with encryption (e.g., DPAPI or RSA protected configuration) still places the secret inside the app's deployment artifacts, and the decryption key is typically accessible to the app pool account or recoverable from the server's profile. In Azure App Service, anyone with access to the filesystem or the SCM (Kudu) site could potentially decrypt the value, and key rotation requires redeploying or manually editing files. Encrypting at rest this way does not remove the secret from the codebase, so it fails to meet cloud security best practices.

• ✓

  Store the connection string in Azure Key Vault and use a Key Vault reference in the App Service application settings.

  Why this is correct

  Using an Azure Key Vault reference in an App Service application setting, written as `@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/...)`, removes the connection string from the App Service configuration entirely. App Service authenticates to Key Vault with the app's managed identity, retrieves the secret at runtime, and injects it as an environment variable, so the secret is never stored in plaintext on the platform. This enables central secret governance, granular access policies, full audit logging, and rotation without redeploying the application, making it the most secure and operationally efficient option.

• ✗

  Store the connection string in Azure App Configuration with encryption.

  Why it's wrong here

  Azure App Configuration is a centralized service for feature flags and application configuration values, not a dedicated secret store. While it encrypts data at rest, storing a connection string there still exposes the plaintext value to any principal with App Configuration read permissions, and it lacks Key Vault's capabilities such as versioned secrets, per-secret access policies, and straightforward rotation workflows. The correct pattern is to put the connection string in Key Vault and optionally use a Key Vault reference from App Configuration, rather than embedding the secret itself in App Configuration, even when encryption is applied.

• ✗

  Store the connection string in an App Service application setting without encryption.

  Why it's wrong here

  Adding a connection string to an App Service application setting without any encryption is insecure because the setting is stored as plaintext in the resource's configuration and can be viewed by anyone with read access to the application settings via the Azure portal, Azure CLI, PowerShell, or REST APIs. The value is also visible to users who can access the environment variables or the SCM (Kudu) endpoint of the app, and there is no built-in access logging or rotation mechanism for individual settings. Exposing a live credential this way violates least privilege and significantly increases the risk of unauthorized database access.

Go deeper

Related to this question