A multi-tenant corporate wellness application tracks daily employee physical activity logs… — Microsoft Azure Developer (AZ-204)

A multi-tenant corporate wellness application tracks daily employee physical activity logs in an Azure Cosmos DB API for NoSQL container. The application's workload profile is as follows:
- The platform supports $5,000$ corporate clients (tenants), each with up to $20,000$ employees.
- Users write multiple activity log entries throughout the day.
- A background process performs transactional batch operations using `TransactionalBatch` to update an employee's daily activity summary item and append new activity log items. These operations must succeed or fail together.
- You must ensure the container scales to handle write ingestion without reaching the 20 GB logical partition limit or creating hot partitions.

Which two actions should you perform to implement a partitioning strategy that meets these requirements? (Select two.)

Create a synthetic partition key by concatenating the employee ID and the current date (e.g., employeeId_YYYYMMDD) to use as the container's partition key.Answer
Ensure all items updated or created within a single TransactionalBatch use the same concatenated employee ID and date value as their partition key.Answer
C
Configure tenantId as the partition key of the container to allow transactional batches across all employees of a tenant.
D
Configure activityId (a unique GUID) as the partition key of the container to maximize write distribution across physical partitions.

Answer

Create a synthetic partition key combining the employee ID and the current date (e.g., employeeId_YYYYMMDD) to use as the container's partition key, and ensure all items updated or created within a single TransactionalBatch share this partition key value.

To execute operations in a TransactionalBatch, all participating items must share the same logical partition key. A synthetic partition key combining the employee ID and the current date (e.g., employeeId_YYYYMMDD) satisfies this requirement by grouping a single employee's logs for that day in one partition. This avoids hot partitions since writes are distributed across different employees and days, and keeps logical partition sizes well under the 20 GB limit.

Step-by-Step Solution

Analyze transactional requirements for the database operations.

Identified that a TransactionalBatch is required, meaning all items involved in a single daily transaction (the employee's summary and log items) must share the same partition key.

Cosmos DB transactions are scoped to a single logical partition key.

Determine the constraints for partition key size and throughput distribution.

Ruled out partition keys with low cardinality (like tenantId) or unbound growth (like employeeId alone over years) to prevent hitting the 20 GB logical partition limit or causing hot partitions.

A single tenant with 20,000 active employees will exceed the 20 GB limit, and highly active employees would eventually exceed it if their historical logs are stored in the same partition.

Select a synthetic partition key strategy combining employee identity and a time boundary.

Formulated a synthetic key (employeeId_YYYYMMDD) that groups all of an employee's activities for a single day together, satisfying the transactional boundary while distributing data across many logical partitions over time.

This strategy keeps the logical partitions small and balanced, well under the 20 GB limit, while still supporting the daily transactional batch writes.

Key Concept

Selecting and configuring synthetic partition keys in Azure Cosmos DB to satisfy transactional boundaries while avoiding size limits and hot partitions.

Estimated Time:1m 30s

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics

More questions from this topic