Table storage basics in Azure - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

Understanding PartitionKey and RowKey in Azure Table Storage

In Azure Table Storage, each entity must have a PartitionKey and a RowKey. What is the primary purpose of the PartitionKey?

A It groups entities for load balancing and scalability.

B It uniquely identifies an entity within a partition.

C It stores the timestamp of the entity creation.

D It encrypts the data stored in the entity.

💡 Hint

Think about how data is organized to improve performance and scalability.

The PartitionKey groups entities into partitions, which helps Azure Table Storage distribute data across servers for load balancing and scalability. The RowKey uniquely identifies an entity within that partition.

❓ Architecture

intermediate

Choosing PartitionKey for Performance

You have a table storing customer orders. To optimize query performance for retrieving all orders by a single customer, which attribute should you use as the PartitionKey?

A OrderDate

B CustomerID

C OrderID

D ProductCategory

💡 Hint

Consider which attribute groups related data you want to query efficiently.

Using CustomerID as the PartitionKey groups all orders of a customer together, making queries for a customer's orders efficient. Other options either do not group related orders or are unique per order.

❓ security

advanced

Securing Access to Azure Table Storage

Which method provides the most secure way to grant temporary, limited access to Azure Table Storage data without sharing the storage account key?

A Use anonymous public access to the table.

B Share the storage account key with the user for direct access.

C Create a new storage account for each user.

D Use Shared Access Signature (SAS) tokens with specific permissions and expiry.

💡 Hint

Think about granting limited and time-bound access securely.

Shared Access Signature (SAS) tokens allow you to grant limited permissions to clients for a specified time without exposing the storage account key, enhancing security.

❓ Configuration

advanced

Handling Large Queries in Azure Table Storage

You need to retrieve more than 1,000 entities from an Azure Table Storage query. What is the correct approach to handle this limitation?

A Split the table into multiple tables to avoid limits.

B Increase the query limit setting to more than 1,000 entities.

C Use continuation tokens to paginate through the results.

D Use a single query without pagination; Azure handles it automatically.

💡 Hint

Consider how Azure Table Storage manages large result sets.

Azure Table Storage returns up to 1,000 entities per query. To retrieve more, you must use continuation tokens provided in the response to request the next set of results.

✅ Best Practice

expert

Designing for Scalability with Azure Table Storage

You expect a very high volume of writes to your Azure Table Storage. Which design choice will best avoid performance bottlenecks?

A Distribute writes across multiple PartitionKeys to avoid hot partitions.

B Use a single PartitionKey for all entities to simplify queries.

C Use RowKey only and leave PartitionKey empty.

D Store all data in a single entity to reduce partition overhead.

💡 Hint

Think about how Azure Table Storage handles partitions under heavy load.

Using multiple PartitionKeys distributes write load across partitions, preventing hot partitions that cause throttling and performance issues.

Practice

1. What two keys uniquely identify a record in Azure Table Storage?

easy

A. StorageKey and DataKey

B. PrimaryKey and SecondaryKey

C. PartitionKey and RowKey

D. TableKey and RecordKey

Solution

1. Step 1: Understand Azure Table Storage keys

   Azure Table Storage uses two keys to uniquely identify each record: PartitionKey and RowKey.

2. Step 2: Confirm uniqueness of keys

   PartitionKey groups records, and RowKey uniquely identifies a record within that partition.

3. Final Answer:

   PartitionKey and RowKey -> Option C

4. Quick Check:

   Unique record ID = PartitionKey + RowKey [OK]

Hint: Remember: PartitionKey groups, RowKey identifies [OK]

Common Mistakes:

• Confusing PartitionKey with PrimaryKey
• Thinking TableKey is a valid key
• Assuming only one key is needed

2. Which of the following is the correct way to create a table client in Azure SDK for Table Storage?

easy

A. TableClient = new TableServiceClient(tableName).GetTableClient(connectionString);

B. TableClient = new TableClient(tableName, connectionString);

C. TableClient = new TableServiceClient(tableName).GetClient(connectionString);

D. TableClient = new TableClient(connectionString, tableName);

Solution

1. Step 1: Review Azure Table Storage SDK syntax

   The correct constructor for TableClient requires connection string first, then table name.

2. Step 2: Match syntax to options

   TableClient = new TableClient(connectionString, tableName); matches the correct syntax: new TableClient(connectionString, tableName); others mix order or use wrong classes.

3. Final Answer:

   TableClient = new TableClient(connectionString, tableName); -> Option D

4. Quick Check:

   Constructor order: connectionString, tableName [OK]

Hint: Connection string always comes before table name [OK]

Common Mistakes:

• Swapping connection string and table name order
• Using TableServiceClient instead of TableClient
• Calling non-existent methods like GetClient

3. Given this code snippet, what will be the output?

var entity = new TableEntity("users", "user1") { { "Name", "Alice" }, { "Age", 30 } };
Console.WriteLine(entity.PartitionKey + ", " + entity.RowKey + ", " + entity["Name"]);

medium

A. user1, users, Alice

B. users, user1, Alice

C. users, user1, 30

D. user1, users, 30

Solution

1. Step 1: Identify PartitionKey and RowKey values

   PartitionKey is "users" and RowKey is "user1" as set in the constructor.

2. Step 2: Access the "Name" property value

   The "Name" property is set to "Alice", so entity["Name"] returns "Alice".

3. Final Answer:

   users, user1, Alice -> Option B

4. Quick Check:

   PartitionKey, RowKey, Name = users, user1, Alice [OK]

Hint: PartitionKey first, RowKey second, then properties [OK]

Common Mistakes:

• Mixing PartitionKey and RowKey order
• Printing Age instead of Name
• Confusing property access syntax

4. You try to insert an entity with the same PartitionKey and RowKey twice. What will happen?

medium

A. An error occurs because keys must be unique.

B. The table creates a duplicate record with a new key.

C. The second insert overwrites the first entity silently.

D. The insert is ignored without error.

Solution

1. Step 1: Understand uniqueness constraint in Table Storage

   PartitionKey and RowKey together uniquely identify an entity; duplicates are not allowed.

2. Step 2: Behavior on duplicate insert

   Trying to insert an entity with existing keys causes an error, preventing duplicates.

3. Final Answer:

   An error occurs because keys must be unique. -> Option A

4. Quick Check:

   Duplicate keys cause error, no silent overwrite [OK]

Hint: Duplicate keys cause error, not overwrite [OK]

Common Mistakes:

• Assuming silent overwrite happens
• Thinking duplicates are allowed
• Believing insert is ignored silently

5. You want to design a scalable Azure Table Storage schema for a large user database. Which approach best supports fast lookups and scalability?

hard

A. Use PartitionKey as user country and RowKey as user ID

B. Use PartitionKey as user ID and RowKey as timestamp

C. Use a single PartitionKey for all users and RowKey as user ID

D. Use random GUIDs for both PartitionKey and RowKey

Solution

1. Step 1: Understand partitioning for scalability

   PartitionKey groups data to distribute load; grouping by country balances partitions.

2. Step 2: Use RowKey for unique identification

   RowKey as user ID uniquely identifies users within each country partition.

3. Step 3: Evaluate other options

   Single partition causes bottleneck; random GUIDs reduce query efficiency; user ID as PartitionKey fragments data poorly.

4. Final Answer:

   Use PartitionKey as user country and RowKey as user ID -> Option A

5. Quick Check:

   Partition by country, RowKey unique ID = scalable [OK]

Hint: PartitionKey groups data logically for scalability [OK]

Common Mistakes:

• Using single partition for all data
• Random keys hurting query performance
• Misusing RowKey as partitioning key