Skip to Content

AZ-500: How Can You Grant an Application Read-Only Storage Access That Expires in 90 Days?

Why Is a Shared Access Signature (SAS) the Best Way to Grant Temporary Storage Access?

Learn the best method to grant an application temporary, read-only access to Azure Storage that automatically expires after 90 days. Understand why a Shared Access Signature (SAS) is the ideal solution for time-bound, permission-scoped access over shared keys or RBAC roles.

Question

You need to grant access for an application to Azure Storage. You need to set access to read and ensure that access is automatically revoked 90 days from today. Which option should you choose?

A. Shared Key
B. Certificate
C. Azure AD user account
D. Shared Access Signature (SAS)

Answer

D. Shared Access Signature (SAS)

Explanation

The correct answer is D. Shared Access Signature (SAS). A SAS is the only option that natively supports all the requirements: granting specific permissions (read), for a defined time period (90 days), with automatic revocation.

SAS tokens offer a variety of controls to limit time and scope of access, where shared keys off the equivalent of root access forever.

Why Shared Access Signature (SAS) is Correct

A Shared Access Signature is a signed URI that provides delegated access to a specific storage resource. It is purpose-built for scenarios like this, where temporary, limited access needs to be granted to a client or application without exposing the primary account keys.

A SAS token is constructed with several parameters that enforce strict boundaries on access:

  • Time Limitation: The core of a SAS is its start and expiry time (st and se parameters). You can generate a SAS that becomes valid immediately and automatically expires exactly 90 days from now. Once the expiry time is reached, the token is permanently invalid, effectively revoking access automatically.
  • Permission Scoping: You define the specific permissions the token will grant. In this case, you would set the signedPermissions (sp) parameter to r for “read” access only. This prevents the application from writing or deleting data.
  • Resource Scoping: Access can be scoped to a specific blob, a container, or the entire storage account, adhering to the principle of least privilege.

The resulting SAS token is a single string that the application can easily use to construct requests, making it simple to integrate.

Why Other Options Are Incorrect

A. Shared Key: This is the equivalent of a root password for your storage account. It provides full administrative access (read, write, delete, manage permissions) to all services in the account and never expires. Distributing it would be a major security violation.

B. Certificate: A certificate is a credential type, often used to authenticate a service principal (an application identity). While you could grant that service principal an RBAC role, the role assignment itself would not expire automatically after 90 days. The certificate itself is not the access control mechanism for storage.

C. Azure AD user account: Assigning an RBAC role (like “Storage Blob Data Reader”) to an Azure AD user account provides the correct read-only permission, but the role assignment is persistent. It would not be automatically revoked after 90 days and would require manual intervention. Furthermore, using a user account for an application is not a best practice; managed identities or service principals are preferred.

Microsoft Certified Azure Security Engineer Associate AZ-500 certification exam assessment practice question and answer (Q&A) dump including multiple choice questions (MCQ) and objective type questions, with detail explanation and reference available free, helpful to pass the Microsoft Certified Azure Security Engineer Associate AZ-500 exam and earn Microsoft Certified Azure Security Engineer Associate AZ-500 certification.