説明

ボックス1: はい
"path": "/*" は includePaths 内にあります。
ルート パスを含めると、インデックスを作成する必要のないパスを選択的に除外できます。これは、Azure Cosmos DB がモデルに追加される可能性のある新しいプロパティを事前にインデックス化できるため、推奨される方法です。
ボックス2: いいえ
"path": "/firstName/?" は excludePaths にあります。
ボックス3: はい
"path": "/address/city/?" は includePaths にあります
参考: https://docs.microsoft.com/en-us/azure/cosmos-db/index-policy

DefaultTimeToLive が -1 の場合、Time to Live 設定はオン (既定値なし) になります。コンテナーの Time to Live が存在し、値が「-1」に設定されている場合、それは無限大に等しく、アイテムは既定で期限切れになりません。
アイテムの有効期限:
このプロパティは、DefaultTimeToLive が存在し、親コンテナーに対して null に設定されていない場合にのみ適用されます。
存在する場合、親コンテナの DefaultTimeToLive 値を上書きします。
参考: https://docs.microsoft.com/en-us/azure/cosmos-db/sql/time-to-live

説明

ボックス1: いいえ
アラートは、DB キーが使用されたときではなく、再生成されたときにトリガーされます。
注: az cosmosdb keys regenerate コマンドは、Azure Cosmos DB データベース アカウントのアクセス キーを再生成します。
ボックス2: いいえ
SMS アクションのみが実行されます。
Emailreceivers が空なので、電子メールアクションは実行されません。
ボックス3: はい
はい、DB キーが再生成されるとアラートがトリガーされます。
参考: https://docs.microsoft.com/en-us/cli/azure/cosmosdb/keys

説明
代わりに、Azure Monitor アラートを構成して関数をトリガーします。
Azure ポータルの Azure Cosmos DB ペインまたは Azure Monitor サービスからアラートを設定できます。
参考: https://docs.microsoft.com/en-us/azure/cosmos-db/create-alerts
トピック 1、Litware 社
ケーススタディ
これはケース スタディです。ケース スタディは個別に時間制限がありません。各ケースを完了するのに必要なだけの試験時間を使用できます。ただし、この試験には追加のケース スタディとセクションが含まれる場合があります。与えられた時間内にこの試験に含まれるすべての質問を完了できるように、時間を管理する必要があります。
ケース スタディに含まれる質問に答えるには、ケース スタディで提供される情報を参照する必要があります。ケース スタディには、ケース スタディで説明されているシナリオに関する詳細情報を提供する展示物やその他のリソースが含まれている場合があります。各質問は、このケース スタディ内の他の質問とは独立しています。
このケース スタディの最後に、確認画面が表示されます。この画面では、試験の次のセクションに進む前に回答を確認し、変更を加えることができます。新しいセクションを開始した後は、このセクションに戻ることはできません。
ケーススタディを始めるには
このケース スタディの最初の質問を表示するには、[次へ] ボタンをクリックします。質問に答える前に、左側のペインのボタンを使用してケース スタディの内容を調べてください。これらのボタンをクリックすると、ビジネス要件、既存の環境、問題の説明などの情報が表示されます。ケース スタディに [すべての情報] タブがある場合、表示される情報は後続のタブに表示される情報と同じであることに注意してください。質問に回答する準備ができたら、[質問] ボタンをクリックして質問に戻ります。
概要
Litware, Inc. は、米国を拠点とする食料品小売業者です。Litware はシアトルに本社と主要データセンターを構えています。同社は米国全土に 50 の小売店を持ち、オンラインでの展開も開始しています。各店舗はインターネットに直接接続されています。
既存の環境。クラウドおよびデータ サービス環境。
Litware には、次の表に示すリソースを含む Azure サブスクリプションがあります。

productdb 内の各コンテナは、手動スループット用に設定されています。
con-product コンテナーには、会社の製品カタログ データが保存されます。con-product 内の各ドキュメントには、con-productvendor 値が含まれます。con-product 内のデータを対象とするほとんどのクエリは、次の形式になります。
SELECT * FROM con-product p WHERE p.con-productVendor - 'name'
con-productVendor コンテナー内のデータを対象とするほとんどのクエリは、SELECT * FROM con-productVendor pv ORDER BY pv.creditRating, pv.yearFounded という形式になります。既存の環境。現在の問題。
Litware は次の問題を特定しています。
con-productVendor コンテナ内の製品カテゴリの更新は、con-product コンテナ内のドキュメントに自動的に反映されません。
con-product でのアプリケーションの更新により、HTTP ステータス コード 429「要求が多すぎます」が頻繁に発生します。429 ステータス コードは、更新中の過剰な要求単位 (RU) の消費に関連していることがわかります。
要件。計画された変更
Litware は、iotdb というデータベースを含む account2 という新しい Azure Cosmos DB Core (SQL) API アカウントを実装する予定です。iotdb データベースには、con-iot1 と con-iot2 という 2 つのコンテナーが含まれます。
Litware は以下の変更を予定しています。
テレメトリ データを account2 に保存します。
複数の読み取り/書き込み領域をサポートするように account1 を構成します。
積積コンテナの参照整合性を実装します。
Azure Functions を使用して、製品の更新に関する通知をさまざまな受信者に送信します。
すべての場所から実行され、account1 のデータを照会する App1 という名前のアプリを開発します。
小売店から実行され、account2 のデータを照会する App2 という名前のアプリを開発します。account2 にアクセスする場合、App2 は単一の DNS エンドポイントに制限する必要があります。
要件。ビジネス要件
Litware では、次のビジネス要件を特定しています。
要件に対して複数のソリューションがある場合は、追加コストがかからない限り、最高のパフォーマンスを提供するソリューションを選択します。
IoT 関連の処理に対する Azure Cosmos DB のコストが予測可能であることを確認します。
小売店でのファイアウォールの変更回数を最小限に抑えます。
要件。製品カタログの要件
Litware は、製品カタログに対して次の要件を特定しています。
製品カタログ データに対してカスタム競合解決ポリシーを実装します。
積分コンテナの更新中に発生するエラーの頻度を最小限に抑えます。
マルチリージョン書き込みが設定されると、account1 のデータに対する App1 クエリのパフォーマンスが最大化されます。
con-product コンテナー内のドキュメントが更新されるたびに、2 つの Azure 関数の実行をトリガーします。