How should the developer design the DynamoDB table to meet these requirements?
For the primary key of the table, specify the unique identifier as the partition key and specify the email address as the sort key.
For the primary key of the table, specify the unique identifier as the partition key. Create a local secondary index (LSI) based on the email address.
For the primary key of the table, specify the email address as the partition key and specify the unique identifier as the sort key.
For the primary key of the table, specify the unique identifier as the partition key. Create a global secondary index (GSI) based on the email address.
Explanations:
This option uses the unique identifier as the partition key and email address as the sort key. However, DynamoDB only allows the primary key to be either a partition key or a partition key and sort key for a single access pattern. To query by email, an additional index is needed.
A local secondary index (LSI) can only be created on attributes with the same partition key as the base table. In this case, while the unique identifier is the partition key, querying by email would require a GSI, not an LSI.
This option uses the email address as the partition key, which conflicts with the requirement of querying by unique identifier. The partition key must be chosen for scalability and efficient access, and using email would not meet both access patterns.
This option correctly uses the unique identifier as the partition key and creates a global secondary index (GSI) on the email address. This allows for efficient queries based on both the unique identifier and the email address.
I plan that the answer is:
For the primary key of the table, specify the unique identifier as the partition key. Create a global secondary index (GSI) based on the email address.