A Shared Access Signature (SAS) is the correct solution because it provides delegated, granular access to specific Azure Storage resources. A SAS token can be configured to grant specific permissions (e.g., read-only) to a single blob for a defined time interval (start and expiry time). This allows vendors to access only the intended data for a limited duration without exposing the storage account keys or making the blobs publicly accessible, thereby adhering to the principle of least privilege.

B. Share the connection string of the access key. Sharing a connection string grants full, non-expiring administrative permissions to the entire storage account, which is an excessive and insecure practice. C. Configure private link connections. Private Link provides secure network connectivity to the storage account endpoint but does not handle authorization or grant access to specific blobs. D. Configure encryption by using customer-managed keys (CMKs). CMK is a mechanism for data encryption at rest. It controls how data is encrypted on the disk and has no function in managing or granting access to users. ---

1. Microsoft Documentation, "Grant limited access to Azure Storage resources using shared access signatures (SAS)": "A shared access signature (SAS) provides secure delegated access to resources in your storage account. With a SAS, you have granular control over how a client can access your data. For example: What resources the client may access... What permissions they have to those resources... How long the SAS is valid." This directly supports the use of SAS for time-limited, specific access.

2. Microsoft Documentation, "Authorize access to data in Azure Storage": This document contrasts authorization methods. Under the "Shared Key (storage account key)" section, it warns: "Anyone who has the shared key can access all data in the storage account... Using the shared key is similar to having root access to your storage account." This confirms why option B is incorrect.

3. Microsoft Documentation, "Customer-managed keys for Azure Storage encryption": "Data in Azure Storage is encrypted and decrypted transparently using 256-bit AES encryption... You can use your own encryption keys... This feature is known as Customer-managed keys (CMK)." This reference clarifies that CMK is for encryption at rest, not access control, making option D incorrect.

4. Microsoft Documentation, "Use private endpoints for Azure Storage": "A private endpoint for Azure Storage allows clients on a virtual network (VNet) to securely access data over a Private Link... Access to the storage account must still be authorized." This shows that Private Link (option C) is for network security, not authorization.