Explanation:
ボックス1：Cert2のみ
Cert2：リーフ証明書またはエンドエンティティ証明書は、証明書の所有者を識別します。証明書チェーンにルート証明書があり、0個以上の中間証明書があります。リーフ証明書は、他の証明書の署名には使用されません。プロビジョニングサービスに対してデバイスを一意に識別し、デバイス証明書と呼ばれることもあります。
ボックス2：Cert1のみ
Cert1：ルート証明書は、認証局（CA）を表す自己署名X.509証明書です。これは、証明書チェーンの終点、つまりトラストアンカーです。ルート証明書は、組織が自己発行することも、ルート認証局から購入することもできます。
参照：
https://docs.microsoft.com/en-us/azure/iot-dps/concepts-x509-attestation

1-Azure Security CenterforIoTを有効にする
2-デバイスセキュリティグループを選択します
3-カスタムアラートルールを作成します
参照：
https://docs.microsoft.com/bs-latn-ba/azure/asc-for-iot/how-to-security-data-access
https://docs.microsoft.com/en-us/rest/api/securitycenter/devicesecuritygroups/createorupdate

各IoTEdgeデバイスは、少なくとも2つのモジュールを実行します。$edgeAgentと$edgeHubは、IoTEdgeランタイムの一部です。IoT Edgeデバイスは、任意の数のプロセスに対して複数の追加モジュールを実行できます。展開マニフェストを使用して、インストールするモジュールと、それらが連携するように構成する方法をデバイスに指示します。
参照：
https://docs.microsoft.com/en-us/azure/iot-edge/module-composition
データの処理と管理
テストレット1
ケーススタディ
これはケーススタディです。ケーススタディは個別にタイミングが調整されていません。各ケースを完了するのに必要なだけの試験時間を使用できます。ただし、この試験には追加のケーススタディとセクションがある場合があります。提供された時間内にこの試験に含まれるすべての質問を確実に完了することができるように、時間を管理する必要があります。
ケーススタディに含まれている質問に答えるには、ケーススタディで提供されている情報を参照する必要があります。ケーススタディには、ケーススタディで説明されているシナリオに関する詳細情報を提供する展示やその他のリソースが含まれている場合があります。このケーススタディでは、各質問は他の質問から独立しています。
このケーススタディの最後に、レビュー画面が表示されます。この画面では、試験の次のセクションに進む前に、回答を確認して変更を加えることができます。新しいセクションを開始した後は、このセクションに戻ることはできません。
ケーススタディを開始するには
このケーススタディの最初の質問を表示するには、[次へ]ボタンをクリックします。質問に答える前に、左側のペインのボタンを使用して、ケーススタディの内容を調べてください。これらのボタンをクリックすると、ビジネス要件、既存の環境、問題の説明などの情報が表示されます。ケーススタディに[すべての情報]タブがある場合、表示される情報は後続のタブに表示される情報と同じであることに注意してください。質問に答える準備ができたら、[質問]ボタンをクリックして質問に戻ります。
概要
Contoso、Ltd.という会社は、建物の内部構造のさまざまなポイントで温度、湿​​度、および光のレベルを監視する建物監視システムを作成しています。
Contosoは、英国にある1つの建物でシステムをテストします。建物は25階建てです。
各フロアには15室あります。
既存の環境。開発の現状
Contosoは、温度と湿度を読み取る一連のBluetoothセンサーを製造しています。センサーは、データを中継するIoTゲートウェイデバイスに接続します。
すべてのIoTゲートウェイデバイスは、iothub1という名前のAzureIoTハブに接続します。
既存の環境。デバイスツイン
次のJSONサンプルを使用して、デバイスツインを実装する予定です。

既存の環境。Azure Stream Analytics
各部屋には、単一のIoTゲートウェイデバイスに送信される読み取り値を生成する3〜5個のセンサーがあります。IoTゲートウェイデバイスは、すべての読み取り値を10〜の間隔でiothub1に転送します
60秒。
ゲートウェイパターンを使用して、各IoTゲートウェイデバイスが独自のIoTHubデバイスIDを持つようにすることを計画します。
次のクエリを作成しますが、GROUPBY句がありません。
選択する
AVG（温度）、
System.TimeStamp（）AS AsaTime
から
Iothub
センサーの平均温度測定値を計算するために30秒の期間を使用することを計画しています。
センサーによって報告された状態と、StreamAnalyticsジョブによって発行された対応するアラートとの間の遅延を最小限に抑えることを計画しています。
既存の環境。デバイスメッセージ
IoTゲートウェイデバイスは、温度が指定されたしきい値を超えるたびに、次のJSONデータを含むメッセージを送信します。

levelpropertyは、criticalepという名前のAzureServiceBusキューエンドポイントにメッセージをルーティングするために使用されます。
既存の環境。問題
IoTゲートウェイデバイスとiothub1の間の接続の問題を発見しました。これにより、IoTデバイスの接続とメッセージが失われます。
要件。計画された変更
Contosoは、次の変更を行う予定です。
* Stream Analyticsを使用して、データを処理および表示します。
* Azure TimeSeriesInsightsを使用してデータを視覚化します。
*デバイスのステータスと必要な設定を同期するシステムを実装します。
*メッセージエンリッチメントを使用してメッセージに追加情報を追加します。
*条件が指定されたしきい値を超えた場合にアラートを送信する通知システムを作成します。
*断続的な接続の問題とメッセージの損失の原因を特定するシステムを実装します。
要件。技術要件
Contosoは、次の技術要件を満たす必要があります。
*可能な限り、IoTHubの組み込み機能を使用してください。
*可能な限り、ハードウェアとソフトウェアのコストを最小限に抑えます。
*デバイスを大規模にプロビジョニングするための管理作業を最小限に抑えます。
*iothub1との間のメッセージフローをトレースするシステムを実装します。
*計画された変更を実装するために必要なカスタムコーディングの量を最小限に抑えます。
*追加のサービスを実装するときに、読み取り操作が悪影響を受けるのを防ぎます。

Explanation:
登録グループを通じてプロビジョニングされたすべてのデバイスのプロビジョニングを解除するには、次の手順に従います。
登録グループを無効にして、署名証明書を禁止します。
その登録グループにプロビジョニングされたデバイスのリストを使用して、それぞれのIoTハブのIDレジストリから各デバイスを無効にするか削除します。
それぞれのIoTハブからすべてのデバイスを無効化または削除した後、オプションで登録グループを削除できます。ただし、登録グループを削除し、1つ以上のデバイスの証明書チェーンの上位にある署名証明書に対して有効な登録グループがある場合、それらのデバイスは再登録できることに注意してください。
参照：
https://docs.microsoft.com/en-us/azure/iot-dps/how-to-unprovision-devices

説明
場合によっては、デバイスツインのタグまたはプロパティに値が設定されたエンリッチメントを適用すると、値が文字列値としてスタンプされます。たとえば、エンリッチメント値が$ twin.tags.fieldに設定されている場合、メッセージには、ツインからのそのフィールドの値ではなく、文字列「$twin.tags.field」がスタンプされます。
これは、次の場合に発生します。
（C）IoT Hubは標準層にありますが、メッセージを送信するデバイスにはデバイスツインがありません。
（E）IoT Hubは標準層にありますが、エンリッチメントの価値に使用されるデバイスツインパスが存在しません。たとえば、エンリッチメント値が$ twin.tags.locationに設定されていて、デバイスツインにタグの下にlocationプロパティがない場合、メッセージには文字列「$twin.tags.location」がスタンプされます。
IoTハブは基本層にあります。基本的な層のIoTハブは、デバイスツインをサポートしていません。
参照：
https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-message-enrichments-overview