DP-201 Designing an Azure Data Solution Practice Questions

Explanation:
We have to choose the partition key which will be used as part of the queries and that which has all the values in place. Hence, we can use the Customer Category as the partition key.
The Microsoft documentation mentions the following:
Choosing a partition key
The following is a good guidance for choosing a partition key: • A single logical partition has an upper limit of 10 GB of storage. • Azure Cosmos containers have a minimum throughput of 400 request units per second (RU/s).
When throughput is provisioned on a database, minimum RUs per container is 100 request units per second (RU/s). Requests to the same partition key can't exceed the throughput that's allocated to a partition. If requests exceed the allocated throughput, requests are rate-limited. So, it's important to pick a partition key that doesn't result in "hot spots" within your application. • Choose a partition key that has a wide range of values and access patterns that are evenly spread across logical partitions. This helps spread the data and the activity in your container across the set of logical partitions, so that resources for data storage and throughput can be distributed across the logical partitions. • Choose a partition key that spreads the workload evenly across all partitions and evenly over time. Your choice of partition key should balance the need for efficient partition queries and transactions against the goal of distributing items across multiple partitions to achieve scalability. • Candidates for partition keys might include properties that appear frequently as a filter in your queries. Queries can be efficiently routed by including the partition key in the filter predicate.
Since this is the ideal candidate for the partition key, all other options are incorrect -- Reference:
https://docs.microsoft.com/en-us/azure/cosmos-db/partitioning-overview

Explanation:
Since we have all of the values of the Customer ID and each value is unique, we can use this as the Item ID of the container.
The Microsoft documentation mentions the following: In addition to a partition key that determines the item's logical partition, each item in a container has an item ID (unique within a logical partition). Combining the partition key and the item ID creates the item's index, which uniquely identifies the item.
Since this is the ideal candidate for the Item ID, all other options are incorrect -- Reference:
https://docs.microsoft.com/en-us/azure/cosmos-db/partitioning-overview

C

Explanation:
You can use Transparent Data Encryption to encrypt the data at rest The Microsoft documentation mentions the following:
Encryption
Azure SQL Data Warehouse Transparent Data Encryption (TDE) helps protect against the threat of malicious activity by encrypting and decrypting your data at rest. When you encrypt your database, associated backups and transaction log files are encrypted without requiring any changes to your applications. TDE encrypts the storage of an entire database by using a symmetric key called the database encryption key.
In SQL Database, the database encryption key is protected by a built-in server certificate. The built-in server certificate is unique for each SQL Database server. Microsoft automatically rotates these certificates at least every 90 days. The encryption algorithm used by SQL Data Warehouse is AES-256. For a general description of TDE, see Transparent Data Encryption.
You can encrypt your database using the Azure portal or T-SQL.
Since this is clearly mentioned in the Microsoft documentation, all other options are incorrect -- Reference:
https://docs.microsoft.com/en-us/azure/sql-data-warehouse/sql-data-warehouse-overview- manage-security

Explanation:
To authenticate, you can use personal access tokens.
The Microsoft documentation mentions the following:
Authentication To authenticate and access Databricks REST APIs, you use personal access tokens. Tokens are similar to passwords; you should treat them with care. Tokens expire and can be revoked.
Requirements
Token-based authentication is enabled by default for all Azure Databricks accounts launched after January 2018. If it is disabled, your administrator must enable it before you can perform the tasks described in this article. See Enable Token-based Authentication.
Since this is clearly mentioned in the Microsoft documentation, all other options are incorrect -- Reference:
https://docs.microsoft.com/en-us/azure/databricks/dev-tools/api/latest/authentication

Explanation:
You can authenticate to Azure Data Lake from Azure Databricks using Azure AD credentials The Microsoft documentation mentions the following: Authenticate to Azure Data Lake Storage using Azure Active Directory Credentials You can authenticate automatically to Azure Data Lake Storage Gen1 and Azure Data Lake Storage Gen2 from Azure Databricks clusters using the same Azure Active Directory (Azure AD) identity that you use to log into Azure Databricks. When you enable your cluster for Azure Data Lake Storage credential passthrough, commands that you run on that cluster can read and write data in Azure Data Lake Storage without requiring you to configure service principal credentials for access to storage.
Since this is clearly mentioned in the Microsoft documentation, all other options are incorrect -- Reference:
https://docs.microsoft.com/en-us/azure/databricks/data/data-sources/azure/adls-passthrough