DP-420 Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB Questions and Answers

Box 1: Serverless capacity mode

Azure Cosmos DB serverless best fits scenarios where you expect intermittent and unpredictable traffic with long idle times. Because provisioning capacity in such situations isn't required and may be cost-prohibitive, Azure Cosmos DB serverless should be considered in the following use-cases:

Getting started with Azure Cosmos DB

Running applications with bursty, intermittent traffic that is hard to forecast, or low (<10%) average-to-peak traffic ratio

Developing, testing, prototyping and running in production new applications where the traffic pattern is unknown

Integrating with serverless compute services like Azure Functions

Box 2: Provisioned throughput capacity mode and autoscale throughput

The use cases of autoscale include:

Variable or unpredictable workloads: When your workloads have variable or unpredictable spikes in usage, autoscale helps by automatically scaling up and down based on usage. Examples include retail websites that have different traffic patterns depending on seasonality; IOT workloads that have spikes at various times during the day; line of business applications that see peak usage a few times a month or year, and more. With autoscale, you no longer need to manually provision for peak or average capacity.

Box 1: CompanyID

After you create a container with a unique key policy, the creation of a new or an update of an existing item resulting in a duplicate within a logical partition is prevented, as specified by the unique key constraint. The partition key combined with the unique key guarantees the uniqueness of an item within the scope of the container.

For example, consider an Azure Cosmos container with Email address as the unique key constraint and CompanyID as the partition key. When you configure the user's email address with a unique key, each item has a unique email address within a given CompanyID. Two items can't be created with duplicate email addresses and with the same partition key value.

Box 2: emailAddress

Box 1 = The current backup policy provides protection for: 2 Hours Azure Cosmos DB automatically takes backups of your data at regular intervals. The backup interval and the retention period can be configured from the Azure portal. You can also choose between two backup modes: periodic backup mode and continuous backup mode. Periodic backup mode is the default mode for all existing accounts and it takes a full backup of your database every 4 hours by default. Continuous backup mode is a new mode that allows you to restore to any point of time within either 7 or 30 days1.

For your scenario, based on the exhibit, you have configured a backup for an Azure Cosmos DB for NoSQL account using the periodic backup mode with a backup interval of 1 hour and a retention period of 2 hours. This means that Azure Cosmos DB will take a full backup of your database every hour and keep only the latest two backups. Therefore, the current backup policy provides protection for 2 hours.

Box 2: In case of emergency, you must (answer choice) to restore the backup = create a support ticket

Azure Cosmos DB automatically takes backups of your data at regular intervals. You can configure the backup interval and the retention period from the Azure portal. You can also choose between two backup modes: periodic backup mode and continuous backup mode. Periodic backup mode is the default mode for all existing accounts and it takes a full backup of your database every 4 hours by default. Continuous backup mode is a new mode that allows you to restore to any point of time within either 7 or 30 days1.

For your scenario, based on the exhibit, you have configured a backup for an Azure Cosmos DB for NoSQL account using the periodic backup mode with a backup interval of 1 hour and a retention period of 2 hours. This means that Azure Cosmos DB will take a full backup of your database every hour and keep only the latest two backups. In case of emergency, you must create a support ticket to restore the backup. This is the answer to your question.

To restore data from a periodic backup, you need to create a support request with Azure Cosmos DB team and provide the following information:

The name of your Azure Cosmos DB account

The name of the database or container that you want to restore

The date and time (in UTC) that you want to restore from

The name of the target Azure Cosmos DB account where you want to restore the data

The name of the target resource group where you want to restore the data

The Azure Cosmos DB team will then initiate the restore process and notify you when it is completed2.

Box 1: country

The country field is filterable.

Note: filterable: Indicates whether to enable the field to be referenced in $filter queries. Filterable differs from searchable in how strings are handled. Fields of type Edm.String or Collection(Edm.String) that are filterable do not undergo lexical analysis, so comparisons are for exact matches only.

Box 2: name

The name field is not Retrievable.

Retrievable: Indicates whether the field can be returned in a search result. Set this attribute to false if you want to use a field (for example, margin) as a filter, sorting, or scoring mechanism but do not want the field to be visible to the end user.

Note: searchable: Indicates whether the field is full-text searchable and can be referenced in search queries.

IS_NUMBER returns a Boolean value indicating if the type of the specified expression is a number.

"1234" is a string, not a number.

Scenario: Develop an app named App2 that will run from the retail stores and query the data in account2. App2 must be limited to a single DNS endpoint when accessing account2.

By using Azure Private Link, you can connect to an Azure Cosmos account via a private endpoint. The private endpoint is a set of private IP addresses in a subnet within your virtual network.

When you're using Private Link with an Azure Cosmos account through a direct mode connection, you can use only the TCP protocol. The HTTP protocol is not currently supported.

App1 queries the con-product and con-productVendor containers.

Note: Request unit is a performance currency abstracting the system resources such as CPU, IOPS, and memory that are required to perform the database operations supported by Azure Cosmos DB.

Scenario:

Develop an app named App1 that will run from all locations and query the data in account1.

Once multi-region writes are configured, maximize the performance of App1 queries against the data in account1.

Whenever there are multiple solutions for a requirement, select the solution that provides the best performance, as long as there are no additional costs associated.

leaseCollectionPrefix: when set, the value is added as a prefix to the leases created in the Lease collection for this Function. Using a prefix allows two separate Azure Functions to share the same Lease collection by using different prefixes.

Scenario: Use Azure Functions to send notifications about product updates to different recipients.

Trigger the execution of two Azure functions following every update to any document in the con-product container.

Box 1: Yes

Non-relational data increases write costs, but can decrease read costs.

Box 2: Yes

Non-relational data increases write costs, but can decrease read costs.

Box 3: No

Non-relational data increases write costs, but can decrease read costs.

The partition key is what will determine how data is routed in the various partitions by Cosmos DB and needs to make sense in the context of your specific scenario. The IoT Device ID is generally the "natural" partition key for IoT applications.

Scenario: The iotdb database will contain two containers named con-iot1 and con-iot2.

Ensure that Azure Cosmos DB costs for IoT-related processing are predictable.

Bounded staleness is frequently chosen by globally distributed applications that expect low write latencies but require total global order guarantee. Bounded staleness is great for applications featuring group collaboration and sharing, stock ticker, publish-subscribe/queueing etc.

Scenario: Application updates in con-product frequently cause HTTP status code 429 "Too many requests". You discover that the 429 status code relates to excessive request unit (RU) consumption during the updates.