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.

• ✗

  Use Microsoft Entra ID authentication with storage account access keys.

  Why it's wrong here

  Using Microsoft Entra ID authentication with storage account access keys is contradictory: the access key is a shared secret that grants full account-level access, bypassing Microsoft Entra ID identity and conditional access. Access keys cannot be scoped to individual VMs or users, require periodic rotation, and any leak compromises the entire storage account. Microsoft Entra ID authentication is supported for Blob and Queue storage, but combining it with keys still means you are relying on a shared secret, so it does not meet keyless secure access.

• ✓

  Enable Azure Storage firewall, deny access from all networks, and add a private endpoint. Then assign a managed identity to the VMs and grant it the necessary RBAC role.

  Why this is correct

  This is the correct keyless design. Enabling the storage firewall to deny all public network traffic ensures the account is unreachable from the internet, while adding a private endpoint places the storage account on a private IP within your VNet, so traffic never traverses the public endpoint. Assigning a managed identity to the VMs and granting the appropriate RBAC role (e.g., Storage Blob Data Reader) provides identity-based, least-privilege access without any account key or SAS token, and access is further verified against the virtual network rules.

• ✗

  Configure a storage account key and distribute it to the applications.

  Why it's wrong here

  Distributing a storage account key to applications embeds a shared secret that grants complete account-wide access to all blob, queue, table, and file services. Unlike managed identity, there is no way to restrict a key to specific containers, operations, or source IPs, and rotating the key forces an application redeployment. Any compromise of the key (e.g., logging, source code, or developer laptop) exposes all customer data, making it a high-risk anti-pattern for sensitive data.

• ✗

  Generate a SAS token with IP restrictions and embed it in the application code.

  Why it's wrong here

  Generating a SAS token with IP restrictions and embedding it in application code is flawed because the SAS token is still a shared secret that can be copied from the code or a memory dump, and IP restrictions only check the caller's public IP—anyone within that IP range (or a spoofed address on a NAT) can reuse it. SAS tokens also have lifetime and permission constraints that must be generated, stored, and renewed, adding operational complexity, and they do not support individual identity or RBAC. This approach still depends on a bearer secret rather than an identity, so it falls short of zero-trust requirements.

Go deeper

Related to this question