You are developing an Azure Cosmos DB solution by using the Azure Cosmos DB SQL API. The data includes millions of documents. Each document may contain hundreds of properties. The properties of the documents do not contain distinct values for partitioning. Azure Cosmos DB must scale individual containers in the database to meet the performance needs of the application by spreading the workload evenly across all partitions over time. You need to select a partition key. Which two partition keys can you use? Each correct answer presents a complete solution. NOTE: Each correct selection is worth one point.

The question describes a scenario where no natural property exists to serve as a good partition key, which requires creating a synthetic partition key. The goal is to distribute a high volume of data and requests evenly across all partitions to prevent "hot partitions" and ensure scalability.

Appending a random suffix (A) or a hash suffix (C) to a property value are two recommended strategies for creating a synthetic key. Both methods significantly increase the cardinality (the number of unique values) of the partition key. This forces documents to be distributed randomly and evenly across the many available logical partitions, which directly addresses the requirement to spread the workload evenly.

B. a single property value that does not appear frequently in the documents: This implies other values of that property do appear frequently, leading to low cardinality and an uneven distribution, creating hot partitions.

D. a value containing the collection name: This would result in a single partition key value for all documents, placing all data into one partition and completely preventing horizontal scaling.

E. a single property value that appears frequently in the documents: This is the definition of a low-cardinality key, which is the primary cause of hot partitions and should be avoided for scalable solutions.

1. Microsoft Learn, "Partitioning and horizontal scaling in Azure Cosmos DB": Under the section "Choosing a partition key," the document explains the characteristics of a good partition key. In the sub-section "Use a hash suffix for write-heavy workloads," it explicitly states, "You can use a hash suffix to spread the workload more evenly... Another strategy is to concatenate the property value with a random suffix." This directly supports options A and C.

2. Microsoft Learn, "Create a synthetic partition key": This document addresses the exact problem in the question. Under the section "Use a partition key with a random suffix," it details how to "concatenate a property value with a random suffix" to distribute write-heavy workloads. It also provides a section on "Use a partition key with a hash suffix," explaining it as another effective technique for the same purpose. This validates both A and C as correct solutions.