AZ-305 Design data storage solutions 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.

• ✗

  Managed identity

  Why it's wrong here

  A managed identity is an Microsoft Entra ID identity automatically assigned to an Azure resource (e.g., a VM, App Service, or Function) for authenticating to Azure services such as Blob Storage. It is not a credential that can be shared externally—it represents the resource itself, not an external user, and cannot generate a scoped, expiring URL for a specific blob. Therefore, using a managed identity would not satisfy the need to grant temporary, anonymous or user-specific access to a particular blob.

• ✗

  Azure role-based access control (RBAC)

  Why it's wrong here

  Azure RBAC grants permissions to security principals (users, groups, or service principals) using role assignments that remain in effect until changed—they do not have a built-in expiration for a single operation. While you could assign a user the Storage Blob Data Reader role at blob scope, the assignment is persistent and cannot be embedded in a URL or automatically expire to meet a temporary shared access requirement. The proper use of RBAC would require adding and later manually removing the assignment, which is exactly the kind of time-limited, granular delegation SAS is designed to avoid.

• ✗

  Storage account access key

  Why it's wrong here

  The storage account access key is the root-level credential for the entire storage account, granting full administrative control over all blobs, tables, queues, and files, and it has no built-in expiration or resource-level scope. Providing the account key would expose the whole account to the external party, not just the specific blob, and unlike a SAS, it cannot be distributed as a temporary, granular URL. Because the key is not time-limited and is not scoped to a single blob, it fails the core requirement.

• ✓

  Shared access signature (SAS)

  Why this is correct

  A shared access signature (SAS) is a signed URI that contains query parameters (e.g., 'sp' for permissions, 'se' for expiry, 'sr' for resource type) and can be scoped precisely to a single blob while the signature is validated by Azure Storage. You can specify read permissions and a short expiration window, and optionally use a user delegation SAS signed with Microsoft Entra ID credentials to avoid using an account key. This is the standard Azure mechanism for granting temporary, delegated access to a specific blob without exposing the account key or requiring a persistent role assignment.

Go deeper

Related to this question