AZ-305 Practice Question: Design identity, governance, and monitoring solutions

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 Key Vault URL and connection string in the application configuration

  Why it's wrong here

  Embedding the Key Vault URL and connection string directly into application configuration files is a security anti-pattern because the connection string itself contains credentials or sensitive data that can be exposed in code, version control, or logs. Simply storing the URL does not solve authentication or authorization concerns, as the application still needs an identity to authenticate to Key Vault and a corresponding access policy. This approach also makes secret rotation difficult and increases the risk of secret leakage, violating the principle of separation between configuration and secrets.

• ✗

  Create a service principal and upload a certificate to the VM

  Why it's wrong here

  Creating a service principal and uploading a certificate to the VM introduces significant operational overhead and security risk because the certificate itself becomes a high-value credential that must be securely stored, provisioned, and renewed on the VM's local filesystem. Certificate lifecycle management—including expiration surveillance, rotation, and revocation—is error-prone and often leads to outages or vulnerabilities. Unlike a managed identity, this method also requires manual management of the service principal's permissions and the certificate's private key, which should be offloaded to a secure store rather than kept on the VM.

• ✓

  Assign a system-assigned managed identity to the VM

  Why this is correct

  Assigning a system-assigned managed identity to the VM is the most secure and least operationally complex approach because Azure automatically creates an identity tied to the VM's lifecycle, and you can grant that identity access to Azure Key Vault via an access policy or Azure RBAC. The application uses the Azure SDK to acquire an access token from the Azure Instance Metadata Service (IMDS) with no credentials stored in code, configuration, or on disk. This identity is automatically rotated by Azure, eliminating the need to manage or store any secrets, and it aligns with best practices for Azure workloads.

• ✗

  Use a shared access signature (SAS) token

  Why it's wrong here

  A shared access signature (SAS) token is designed for delegating limited access to Azure Storage resources—such as blobs, queues, or tables—not for authenticating to Azure Key Vault, which requires an Microsoft Entra ID token and grants access via RBAC or access policies. SAS tokens are URL-based signatures that carry permissions for a specific storage service, and using them for Key Vault would be conceptually and technically invalid. Even if a SAS token somehow obtained a secret, it would not be a manageable or secure mechanism for accessing Key Vault, as it lacks the built-in identity management and conditional access features of Entra ID.

Go deeper

Related to this question