Storage access keys and SAS tokens in Azure - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding SAS Token Permissions

You create a Shared Access Signature (SAS) token for an Azure Storage blob with the following permissions: read and list. What actions can a user perform with this SAS token?

A The user can read blob content and list blobs in the container but cannot upload or delete blobs.

B The user can upload new blobs and delete existing blobs but cannot read blob content.

C The user can read, upload, delete, and list blobs in the container.

D The user can only list blobs but cannot read or modify blob content.

💡 Hint

Think about what 'read' and 'list' permissions allow in Azure Storage.

'Read' permission allows reading blob content. 'List' permission allows listing blobs in a container. Uploading or deleting requires 'write' or 'delete' permissions, which are not granted here.

❓ Configuration

intermediate

SAS Token Expiry Configuration

You want to create a SAS token that expires exactly 2 hours after creation. Which of the following ISO 8601 datetime strings correctly sets the expiry time if the token is created at 2024-06-01T10:00:00Z?

A 2024-06-01T10:02:00Z

B 2024-06-01T12:00:00Z

C 2024-06-01T08:00:00Z

D 2024-06-01T14:00:00Z

💡 Hint

Remember that the expiry time must be 2 hours after the creation time.

The token created at 10:00:00Z expires at 12:00:00Z, which is exactly 2 hours later. Other options are either earlier or too far in the future.

❓ Architecture

advanced

Choosing Between Storage Access Keys and SAS Tokens

Your company wants to allow a third-party app to upload files to a specific container in your Azure Storage account without giving full access to the storage account. Which approach is best?

A Share the storage account access keys with the third-party app.

B Give the third-party app the Azure subscription owner role.

C Create a SAS token scoped to the specific container with write permission and limited expiry time.

D Create a new storage account and share its access keys with the third-party app.

💡 Hint

Think about least privilege and limiting access scope.

Sharing storage account keys gives full access, which is risky. SAS tokens can limit access to specific containers and permissions with expiry. Creating a new storage account or giving owner role is excessive and insecure.

❓ security

advanced

Security Risks of Using Storage Account Access Keys

What is the main security risk of distributing your Azure Storage account access keys to multiple applications?

A Access keys only allow read access, limiting application functionality.

B Access keys expire too quickly, causing service interruptions.

C Access keys automatically rotate, causing authentication failures.

D Access keys provide full control over the storage account, so if leaked, attackers can access or delete all data.

💡 Hint

Consider the scope of permissions granted by access keys.

Storage account access keys grant full control over all resources in the account. If leaked, attackers can read, write, or delete any data. This is why SAS tokens with limited scope are preferred.

❓ service_behavior

expert

Effect of Revoking a SAS Token

You generate a SAS token with read and write permissions for a blob container. Later, you regenerate the storage account access keys. What happens to the SAS token?

A The SAS token immediately becomes invalid and cannot be used anymore.

B The SAS token's permissions are reduced to read-only automatically.

C The SAS token remains valid until its expiry time, unaffected by key regeneration.

D The SAS token is valid only if the storage account is in read-only mode.

💡 Hint

Think about how SAS tokens are signed and what regenerating keys means.

SAS tokens are signed using the storage account access keys. Regenerating keys invalidates all SAS tokens signed with the old keys immediately.