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.

Practice

1. What is the main difference between a storage access key and a SAS token in Azure Storage?

easy

A. SAS tokens provide full access; storage access keys provide limited access.

B. Both provide full access but SAS tokens expire faster.

C. Storage access keys provide full access; SAS tokens provide limited, temporary access.

D. Storage access keys are only for blobs; SAS tokens are for all storage types.

Solution

1. Step 1: Understand storage access keys

   Storage access keys give full control over the entire storage account without restrictions.

2. Step 2: Understand SAS tokens

   SAS tokens grant limited, time-bound access to specific resources or actions within the storage account.

3. Final Answer:

   Storage access keys provide full access; SAS tokens provide limited, temporary access. -> Option C

4. Quick Check:

   Access scope = Full vs Limited [OK]

Hint: Full control = access keys; limited control = SAS tokens [OK]

Common Mistakes:

• Confusing SAS tokens as full access keys
• Thinking SAS tokens never expire
• Assuming access keys are resource-specific

2. Which of the following is the correct way to generate a SAS token for a blob container using Azure CLI?

easy

A. az storage blob generate-sas --container-name mycontainer --permissions rwl --expiry 2024-12-31T23:59:00Z --account-name mystorage

B. az storage container generate-sas --name mycontainer --permissions rwl --expiry 2024-12-31T23:59:00Z --account-name mystorage

C. az storage account generate-sas --name mycontainer --permissions rwl --expiry 2024-12-31T23:59:00Z

D. az storage generate-sas --container mycontainer --permissions rwl --expiry 2024-12-31T23:59:00Z

Solution

1. Step 1: Identify the correct Azure CLI command for container SAS

   The command to generate a SAS token for a container is az storage container generate-sas.

2. Step 2: Check parameters

   az storage container generate-sas --name mycontainer --permissions rwl --expiry 2024-12-31T23:59:00Z --account-name mystorage correctly uses container name, permissions, expiry, and account name parameters.

3. Final Answer:

   az storage container generate-sas --name mycontainer --permissions rwl --expiry 2024-12-31T23:59:00Z --account-name mystorage -> Option B

4. Quick Check:

   Correct CLI command and parameters [OK]

Hint: Use 'container generate-sas' for containers, not 'blob generate-sas' [OK]

Common Mistakes:

• Using 'az storage blob generate-sas' for containers
• Omitting required parameters like --account-name
• Using incorrect command syntax

3. Given this SAS token snippet for a blob: ?sv=2023-01-01&ss=b&srt=sco&sp=rl&se=2024-07-01T00:00:00Z&st=2024-06-01T00:00:00Z&spr=https&sig=abc123, what permissions does it grant?

medium

A. Read and List permissions on blob service

B. Read and Write permissions on blob service

C. Full control on storage account

D. Only write permission on blob service

Solution

1. Step 1: Decode the SAS token parameters

   sp=rl means permissions are Read (r) and List (l).

2. Step 2: Understand service and resource types

   ss=b means the service is Blob storage.

3. Final Answer:

   Read and List permissions on blob service -> Option A

4. Quick Check:

   sp=rl means Read+List [OK]

Hint: Check 'sp' parameter for permissions letters [OK]

Common Mistakes:

• Confusing 'rl' with read-write
• Assuming full control from SAS token
• Ignoring service type 'ss' parameter

4. You created a SAS token with --permissions rwd but users report they cannot delete blobs. What is the likely cause?

medium

A. The SAS token lacks the 'Delete' permission 'x'.

B. The SAS token expired before use.

C. The storage account keys were regenerated.

D. The SAS token was generated for the wrong resource type.

Solution

1. Step 1: Understand permissions for delete

   Delete permission is represented by 'd', so 'rwd' includes delete.

2. Step 2: Check resource type relevance

   If the SAS token is generated for a container but used on blobs, or vice versa, permissions may not apply correctly.

3. Final Answer:

   The SAS token was generated for the wrong resource type. -> Option D

4. Quick Check:

   Permissions + resource type must match [OK]

Hint: Match SAS token resource type with intended use [OK]

Common Mistakes:

• Assuming 'x' is delete permission
• Ignoring resource type mismatch
• Not checking token expiry

5. You want to allow a third-party app to upload files to a specific blob container for 2 hours without exposing your storage account keys. Which approach is best?

hard

A. Generate a SAS token scoped to the container with write permission and 2-hour expiry.

B. Create a new storage account for the app.

C. Share the storage account access keys with the app.

D. Use a SAS token with full permissions and no expiry.

Solution

1. Step 1: Avoid sharing storage account keys

   Sharing keys gives full control and is insecure for third parties.

2. Step 2: Use SAS token with limited scope and expiry

   Generating a SAS token scoped to the container with write permission and a 2-hour expiry limits access and duration.

3. Step 3: Evaluate other options

   Creating a new storage account is unnecessary overhead; SAS token with full permissions and no expiry is insecure.

4. Final Answer:

   Generate a SAS token scoped to the container with write permission and 2-hour expiry. -> Option A

5. Quick Check:

   Limited scope + expiry = SAS token best practice [OK]

Hint: Use SAS tokens for limited, timed access, not keys [OK]

Common Mistakes:

• Sharing full access keys with third parties
• Using SAS tokens without expiry
• Creating unnecessary storage accounts