Q1.あなたは、Azure Cosmos DB for NoSQLソリューションを設計しています。
自動車修理部品の製品データを格納するContainer1という名前の新しいコンテナーを作成する予定です。
データ構造は次の表のとおりです。
データベースのデータパーティション分割ソリューションを推奨する必要があります。このソリューションでは、I/O競合を最小限に抑えるためにワークロードを分散する必要があります。
物理パーティションキーおよび論理パーティションキーとして、どの列を推奨すべきですか。
回答領域で適切な選択肢を選択してください。



回答
- 下記画像参照
-

モデル年は、提示データで5種類の値があり、ブランドや部品名よりカーディナリティが高いため、書き込みを広く分散してI/O競合やホットパーティションの発生を抑えられます。
自動車モデルを論理パーティションキーにすると、同じモデル年のデータを車種ごとに細分化でき、モデル年と自動車モデルの組み合わせも提示データでは一意になります。
Azure Cosmos DBでは、論理パーティションがパーティションキー値によって形成され、物理パーティションへの配置はサービスが自動管理します。
そのため、現在の公式用語では、利用者が物理パーティションキーを直接指定するのではなく、データと要求を均等に分散できるパーティションキーを選択すると説明されます。
Azure Cosmos DBでのパーティション分割と水平方向のスケーリング
Q2.Container1という名前のコンテナーをホストするAzure Cosmos DB for NoSQLデータベースがあります。
Container1を使用するApp1という名前の新しいアプリを開発しています。
App1がContainer1内のドキュメントを削除しようとしたときに、その操作がブロックされ、アプリにエラーが返されるようにする必要があります。
何を使用すべきですか。
A. ポストトリガー
B. ストアドプロシージャ
C. ユーザー定義関数(UDF)
D. プリトリガー
回答
- D. プリトリガー
-
プリトリガーはデータベース項目が変更される前に実行されるため、削除処理の実行前にJavaScriptで例外をスローし、操作を中止してApp1へエラーを返せます。
ポストトリガーは変更後に実行され、UDFは主にクエリ内の計算に使用されるため不適切です。
トリガーは自動的には実行されないため、App1からの削除要求でプリトリガーを明示的に指定する必要があります。
なお、問題文の「ドキュメント」は、現在のMicrosoft公式資料では主に「項目(item)」と表記されています。
Azure Cosmos DB でストアド プロシージャ、トリガー、およびユーザー定義関数を記述する方法
Q3.Azure Cosmos DBアカウントとデータベースをプロビジョニングするAzure Resource Manager(ARM)テンプレートがあります。
各アカウントは、単一のAzureリージョンにデプロイされています。
各データベースには、プロビジョニング済みスループットが構成されています。
リージョン名、データベースのスループットの種類、およびスループット値は、テンプレートパラメーターとして定義されています。
次のシナリオに基づいて、一部のAzure Cosmos DBアカウントとデータベースを変更する必要があります。
シナリオ1:読み取りリージョンを追加し、データベースのスループットを増やします。
シナリオ2:手動プロビジョニング済みデータベーススループットを自動スケーリングに変更します。
このソリューションでは、管理作業と変更にかかる時間を最小限に抑える必要があります。
各シナリオで何を使用すべきですか。
回答領域で適切な選択肢を選択してください。

回答
- 下記画像参照
-

リージョンの追加または削除と、その他のプロパティ変更は同時に実行できないため、シナリオ1では読み取りリージョンの追加とRU/sの増加を2回の増分デプロイに分けます。
増分モードなら、テンプレートに含まれない既存リソースを削除しません。
手動スループットから自動スケーリングへの移行はPOST操作であり、ARMテンプレートではサポートされないため、シナリオ2ではAzure PowerShellを使用します。
画像内の緑色の解答例は、現行のMicrosoft Learnの仕様とは一致しません。
Azure Resource Manager テンプレートを使用して Azure Cosmos DB for NoSQL リソースを管理する
Azure Resource Manager のデプロイ モード
Q4.Azure Cosmos DB for NoSQLアカウントからデータを取り込むように、Apache Kafkaインスタンスを構成する必要があります。
telemetryという名前のコンテナーのデータを、iotという名前のKafkaトピックに追加する必要があります。
このソリューションでは、データをコンパクトなバイナリ形式で格納する必要があります。
ソリューションに含めるべき構成項目を3つ選択してください。
正しい各回答は、ソリューションの一部を示します。
A. “connector.class”: “com.azure.cosmos.kafka.connect.source.CosmosDBSourceConnector”
B. “key.converter”: “org.apache.kafka.connect.json.JsonConverter”
C. “key.converter”: “io.confluent.connect.avro.AvroConverter”
D. “connect.cosmos.containers.topicmap”: “iot#telemetry”
E. “connect.cosmos.containers.topicmap”: “iot”
F. “connector.class”: “com.azure.cosmos.kafka.connect.source.CosmosDBSinkConnector”
回答
- A. “connector.class”: “com.azure.cosmos.kafka.connect.source.CosmosDBSourceConnector”
C. “key.converter”: “io.confluent.connect.avro.AvroConverter”
D. “connect.cosmos.containers.topicmap”: “iot#telemetry” -
Cosmos DBからKafkaへデータを送信するため、CosmosDBSourceConnectorを使用します。
Sinkコネクターは反対に、KafkaからCosmos DBへデータを書き込む場合に使用します。
コンパクトなバイナリ形式にはAVROを選択するため、AvroConverterが必要です。
また、topicmapは「Kafkaトピック名#Cosmos DBコンテナー名」の形式なので、iot#telemetryと設定します。
実際の構成では、データ本体に対するvalue.converterやスキーマレジストリの設定も確認が必要です。
選択肢にあるサービス名とコネクタークラス名は、現在のMicrosoft Learnでも使用されています。
Azure Cosmos DB用Kafka Connect
Kafka Connect for Azure Cosmos DB – ソース コネクタ
Q5.注文および各注文の注文明細を格納するAzure Cosmos DB for NoSQLアカウントをデプロイする予定です。
単一の注文とその注文明細を読み取る際のパフォーマンスを最大化し、コストを最小化するアカウント設計を推奨する必要があります。
何を推奨すべきですか。
A. 各注文の注文明細を同じコンテナーに埋め込みます。
B. 注文と注文明細を別々のコンテナーに格納します。
C. 個々の注文と注文明細を、同じコンテナー内の別々の項目として格納します。項目のサイズを最小化するために正規化します。
D. 個々の注文と個々の注文明細を、同じコンテナー内の別々の項目として格納します。各項目に種類を示す属性を含めます。
回答
- A. 各注文の注文明細を同じコンテナーに埋め込みます。
-
注文と注文明細を常に一緒に読み取る場合は、注文明細を配列として注文のJSON項目内に埋め込む非正規化設計が適しています。
注文全体を1回のポイント読み取りで取得できるため、複数項目へのクエリや複数回の読み取りが不要となり、待機時間とRU消費を抑えられます。
別コンテナーや別項目に分割すると、追加の要求や結合処理が必要です。
Azure Cosmos DB for NoSQLは現在も正式名称であり、旧称のSQL APIから変更されています。
Azure Cosmos DB for NoSQL でのデータ モデリング
Azure Cosmos DB での要求コストを最適化する
Q6.Azure Cosmos DBデータベースがあります。
製品データと製品カテゴリーデータを格納し、主に読み取り要求を処理するcontainer1という名前の新しいコンテナーを作成する予定です。
container1のパーティションキーを構成する必要があります。
ソリューションは、次の要件を満たす必要があります。
パーティションのサイズを最小限に抑える。
メンテナンス作業を最小限に抑える。
どの2つの特性を優先すべきですか。
正しい各回答は、ソリューションの一部を示します。
A. 一意である
B. カーディナリティが高い
C. カーディナリティが低い
D. 静的である
回答
- B. カーディナリティが高い
D. 静的である -
カーディナリティが高いキーは、多数の異なる値によって項目を細かい論理パーティションに分散できるため、各パーティションのサイズを小さくしやすくなります。
低カーディナリティでは、多数の項目が同じキー値に集中する可能性があります。
静的なキーは値が変化しないため、変更に伴う項目の削除と再作成を避け、メンテナンス作業を抑えられます。
Azure Cosmos DBでは、作成済み項目のパーティションキー値をその場で変更できません。
Azure Cosmos DBでのパーティション分割と水平方向のスケーリング
Q7.Azure Cosmos DB for NoSQLアカウントがあります。
すべてのログ情報をLog Analyticsワークスペースへ送信するように診断設定を構成しました。
アカウント内のリソースに対して、プロビジョニングされた1秒あたりの要求ユニット数(RU/s)がいつ変更されたかを特定する必要があります。
次のクエリを作成しました。
AzureDiagnostics
| where Category == “ControlPlaneRequests”
クエリに何を追加すべきですか。
A. | where OperationName startswith “RegionAddComplete”
B. | where OperationName startswith “SqlContainersCreate”
C. | where OperationName startswith “MongoCollectionsThroughputUpdate”
D. | where OperationName startswith “SqlContainersThroughputUpdate”
回答
- D. | where OperationName startswith “SqlContainersThroughputUpdate”
-
Azure Cosmos DB for NoSQLコンテナーのスループット変更は、OperationNameが「SqlContainersThroughputUpdate」で始まるコントロールプレーン操作として記録されます。
したがって、Dを追加するとRU/sが変更された日時を抽出できます。RegionAddCompleteはリージョン追加、SqlContainersCreateはコンテナー作成、MongoCollectionsThroughputUpdateはMongoDB用APIのコレクションに対するスループット変更です。
AzureDiagnosticsは現在「レガシ」モードの共通テーブルであり、新しい構成ではリソース固有テーブルも選択できますが、問題のクエリではAzureDiagnosticsを使用します。
Azure Cosmos DB コントロール プレーン操作を監査する方法
Azure Cosmos DB を監視する
Q8.注:このセクションには、同じシナリオと問題を使用する1つ以上の問題セットが含まれています。
各問題では、問題に対する固有のソリューションが提示されます。そのソリューションが提示された目標を満たすかどうかを判断する必要があります。セット内の複数のソリューションが問題を解決する場合があります。また、どのソリューションも問題を解決しない場合があります。
このセクションの問題に回答した後は、その問題に戻ることができません。そのため、これらの問題はレビュー画面には表示されません。
Azure Cosmos DB for NoSQLデータベースがあります。このデータベースは、次の形式でデータを格納するfamiliesという名前のコンテナーをホストしています。
フィールドの意味:parentsは親、familyNameは姓、givenNameは名、childrenは子ども、genderは性別、femaleは女性、gradeは学年、petsはペット、typeは種類、dogは犬、catは猫、addressは住所、stateは州、countyは郡、cityは市、creationDateは作成日時、isRegisteredは登録済みかどうか、falseは偽を表します。
次のデータを返す必要があります。
家族のID
子どもの姓
ペットの種類が猫である場合、そのペットの名前
ソリューション:次のクエリを実行します。
このソリューションは目標を満たしますか。


A. はい
B. いいえ
回答
- A. はい
-
最初のJOINによってchildren配列の各要素が展開され、c.familyNameから子どもの姓を取得できます。
続く複数値サブクエリは、各子どものpets配列をtypeがcatである要素だけに絞り込み、そのgivenNameをpetNameとして返します。
したがって、f.id、子どもの姓、猫の名前という要求された項目を取得できるため、目標を満たします。
現在の公式資料でも、配列内の自己結合とJOIN前に配列を絞り込む複数値サブクエリがサポートされています。
Azure Cosmos DB for NoSQLは現行名称で、旧資料のSQL APIに相当します。
サブクエリ – Cosmos DB のクエリ言語 (Azure と Fabric)
自己結合 – Cosmos DB のクエリ言語 (Azure と Fabric)
Q9.Azure Cosmos DB for NoSQLアカウントにdb1という名前のデータベースがあります。
REST APIを介して公開されているサードパーティ製アプリケーションがあります。
アプリケーションからdb1内のコンテナーへ、毎週データを移行する必要があります。
どのツールを使用すべきですか。
A. Azure Migrate
B. Azure Data Factory
C. Database Migration Assistant
回答
- B. Azure Data Factory
-
Azure Data Factoryのコピーアクティビティでは、RESTコネクターをソースとしてREST APIからデータを取得し、Azure Cosmos DB for NoSQLコネクターをシンクとしてコンテナーへ書き込めます。
また、スケジュールトリガーで繰り返し間隔を設定できるため、パイプラインを毎週自動実行できます。
Azure Migrateは主にサーバーなどのAzure移行に使用し、Database Migration AssistantはSQL Server系の評価や移行を目的とするため、定期的なRESTデータ連携には適しません。
Azure Cosmos DB for NoSQLは現行名称で、旧資料ではSQL APIと表記されています。
Azure Data Factoryを使用して REST エンドポイントとの間でデータをコピーおよび変換する
Azure Data Factoryを使用してNoSQLのAzure Cosmos DB内のデータをコピーおよび変換する
Q10.次のAzure Resource Manager(ARM)テンプレートがあります。
コード内のconsistentは一貫性のあるインデックス作成、ascendingは昇順、descendingは降順を表します。
このテンプレートを増分モードでデプロイする予定です。
次の各記述について、正しい場合は「はい」を選択してください。それ以外の場合は「いいえ」を選択してください。


回答
- 下記画像参照
-

テンプレートにはコンテナーの子リソースだけが定義されているため、存在しないacct01アカウントやmydbデータベースは自動作成されません。
親リソースが既に存在する場合、増分デプロイによって未作成のmycontainerは作成されます。
既存コンテナーのパーティションキーは/nameから/companyidへ直接変更できず、別のパーティションキーを使用するには新しいコンテナーへのデータ移行が必要です。Microsoft.DocumentDBは旧製品名ではなく、現在もAzure Cosmos DBで使用される正式なリソースプロバイダー名前空間です。
apiVersionの2021-01-15は古い版ですが、リソース定義として公開されています。
Microsoft.DocumentDB データベースアカウント/sqlデータベース/コンテナ
子リソースの名前と種類を設定する
