Microsoft DP-420(Azure Cosmos DB Developer Specialty) 1-10

表示モード
画像位置
文字位置
STATUS FILTER

表示する理解度を選択

読み込み中...
Q1DP-420
回答
下記画像参照

モデル年は、提示データで5種類の値があり、ブランドや部品名よりカーディナリティが高いため、書き込みを広く分散してI/O競合やホットパーティションの発生を抑えられます。
自動車モデルを論理パーティションキーにすると、同じモデル年のデータを車種ごとに細分化でき、モデル年と自動車モデルの組み合わせも提示データでは一意になります。
Azure Cosmos DBでは、論理パーティションがパーティションキー値によって形成され、物理パーティションへの配置はサービスが自動管理します。
そのため、現在の公式用語では、利用者が物理パーティションキーを直接指定するのではなく、データと要求を均等に分散できるパーティションキーを選択すると説明されます。

Azure Cosmos DBでのパーティション分割と水平方向のスケーリング

Q2DP-420

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 でストアド プロシージャ、トリガー、およびユーザー定義関数を記述する方法

Q3DP-420
回答
下記画像参照

リージョンの追加または削除と、その他のプロパティ変更は同時に実行できないため、シナリオ1では読み取りリージョンの追加とRU/sの増加を2回の増分デプロイに分けます。
増分モードなら、テンプレートに含まれない既存リソースを削除しません。
手動スループットから自動スケーリングへの移行はPOST操作であり、ARMテンプレートではサポートされないため、シナリオ2ではAzure PowerShellを使用します。
画像内の緑色の解答例は、現行のMicrosoft Learnの仕様とは一致しません。

Azure Resource Manager テンプレートを使用して Azure Cosmos DB for NoSQL リソースを管理する
Azure Resource Manager のデプロイ モード

Q4DP-420

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 – ソース コネクタ

Q5DP-420

A. 各注文の注文明細を同じコンテナーに埋め込みます。
B. 注文と注文明細を別々のコンテナーに格納します。
C. 個々の注文と注文明細を、同じコンテナー内の別々の項目として格納します。項目のサイズを最小化するために正規化します。
D. 個々の注文と個々の注文明細を、同じコンテナー内の別々の項目として格納します。各項目に種類を示す属性を含めます。

回答
A. 各注文の注文明細を同じコンテナーに埋め込みます。

注文と注文明細を常に一緒に読み取る場合は、注文明細を配列として注文のJSON項目内に埋め込む非正規化設計が適しています。
注文全体を1回のポイント読み取りで取得できるため、複数項目へのクエリや複数回の読み取りが不要となり、待機時間とRU消費を抑えられます。
別コンテナーや別項目に分割すると、追加の要求や結合処理が必要です。
Azure Cosmos DB for NoSQLは現在も正式名称であり、旧称のSQL APIから変更されています。

Azure Cosmos DB for NoSQL でのデータ モデリング
Azure Cosmos DB での要求コストを最適化する

Q6DP-420

A. 一意である
B. カーディナリティが高い
C. カーディナリティが低い
D. 静的である

回答
B. カーディナリティが高い
D. 静的である

カーディナリティが高いキーは、多数の異なる値によって項目を細かい論理パーティションに分散できるため、各パーティションのサイズを小さくしやすくなります。
低カーディナリティでは、多数の項目が同じキー値に集中する可能性があります。
静的なキーは値が変化しないため、変更に伴う項目の削除と再作成を避け、メンテナンス作業を抑えられます。
Azure Cosmos DBでは、作成済み項目のパーティションキー値をその場で変更できません。

Azure Cosmos DBでのパーティション分割と水平方向のスケーリング

Q7DP-420

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 を監視する

Q8DP-420

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)

Q9DP-420

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内のデータをコピーおよび変換する

Q10DP-420
回答
下記画像参照

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

Microsoft.DocumentDB データベースアカウント/sqlデータベース/コンテナ
子リソースの名前と種類を設定する