## Azure Sentinel と Azure Security Center の基盤として共有されるログデータ
Azure Sentinel と Azure Security Center で基盤として共有されているログ データ プラットフォームは何ですか。
1. 診断設定
2. Azure Monitor ログ
3. アクティビティ ログ
### Explanation
Ans: "2. Azure Monitor ログ"
Sentinel や Security Center を含む Azure のいくつかのサービスでは、基になる ログ データ プラットフォームとして Azure Monitor ログを使用します。
"1": 診断設定は、プラットフォームのメトリックとプラットフォームのログを Azure Monitor Log Analytics、ストレージ アカウント、または Event Hubs に送信するために使用されます。
"3": アクティビティ ログは、Azure プラットフォームのログであり、サブスクリプションレベルのイベントの分析情報が提供されます。
---
## geo 冗長構成をとる場合に別のリージョンに明示的にコピーする必要があるリソース
geo 冗長構成をとる場合に、別のリージョンに明示的にコピーする必要がありますか?
1. Azure DNS と Azure AD
2. Azure App Service、Azure 関数アプリ、Redis Cache、キュー
3. Azure DNS、Azure AD、Azure Storage
### Explanation
Ans: "2. Azure App Service、Azure 関数アプリ、Redis Cache、キュー"
これらのコンポーネントは、明示的にコピーするか、別のリージョンにレプリケートする必要があります。
"3": Azure DNS と Azure AD はどちらも既定でマルチリージョンなので、コピーする必要はありません。 Azure Storage は、コピーするのではなく、複数のリージョンに存在するように構成します。
---
## Azure Storage の geo冗長
次の文章を完成させてください。Azure Storage でリージョン規模の障害が発生した場合、データの損失は...
1. すべてのデータがセカンダリ リージョンに自動的にコピーされるため、発生しない。
2. データが非同期的にコピーされるため、短時間について発生する可能性がある。
3. 短時間発生する可能性があるが、マスターからデータを復元できる
### Explanation
Ans: "2. データが非同期的にコピーされるため、短時間について発生する可能性がある。"
RA-GRS では、データがプライマリからセカンダリに非同期的にコピーされるため、データが失われる可能性があります。
"1": 適切な構成では、データはコピーされますが、この操作は非同期的に行われるため、データが失われる可能性があります。
---
## スタンバイリージョンに明示的にコピーする必要があるリソース
リージョン規模の障害が発生した場合に、SQL データベースへの書き込みアクセスを自動的にフェールオーバーする必要があります。 カスタム コードを記述したくはありません。 何をする必要がありますか?
1. アクティブ geo レプリケーションを使用する
2. 自動フェールオーバー グループを使用する
3. 複数書き込みリージョンを使用する
### Explanation
Ans: "2. 自動フェールオーバー グループを使用する"
自動フェールオーバー グループを使用することにより、セカンダリ リージョンのレプリカに自動的にフェールオーバーするようにプライマリ データベースを構成できます。
---
## リージョン規模の障害発生時に完全にデータを保護するには ?
リージョン規模の障害時に、完了したトランザクションが 1 つも失われないようにする必要があります。 何をする必要がありますか?
1. 1 つの書き込みリージョンで Azure Cosmos DB を使用する。
2. アクティブ geo レプリケーションで Azure SQL Database を使用する。
3. 自動フェールオーバー グループで Azure SQL Database を使用する。
### Explanation
Ans: "1. 1 つの書き込みリージョンで Azure Cosmos DB を使用する。"
Azure Cosmos DB では同期レプリケーションが使用されており、トランザクションはレプリカのクォーラムにレプリケートされたときにのみ完了します。
---
## 自動スケーリングとは ?
自動スケーリングについての最も適切な説明はどれですか?
1. 自動スケーリングは、スケールアップ/スケールダウン ソリューションです。 需要が多い期間中はより強力なハードウェアにアプリケーションを移行し、需要が少なくなったら性能の低いハードウェアに戻します。
2. 自動スケーリングでは、管理者がシステム上のワークロードを積極的に監視する必要があります。 ワークロードが増えて応答時間が低下し始めた場合、管理者は自動スケーリングをトリガーし、システムのスループットを増やすことができます。
3. 自動スケーリングは、スケールアウト/スケールイン ソリューションです。 システムは、指定されたリソースのメトリックで使用量の増加が示されるとスケールアウトし、これらのメトリックが低下するとスケールインできます。
4. 自動スケーリングは、数分間継続するアクティビティの突然の急増を処理するのに理想的なソリューションです。
5. スケールインとスケールアウトでは、自動スケーリングより優れた可用性が提供されます。
### Explanation
Ans: "3. 自動スケーリングは、スケールアウト/スケールイン ソリューションです。 システムは、指定されたリソースのメトリックで使用量の増加が示されるとスケールアウトし、これらのメトリックが低下するとスケールインできます。"
"4": 自動スケーリングでは、リソースを追加するのに時間がかかります。 システムが追加リソースを起動する前に、アクティビティの急激な増加が終わってしまう可能性があります。
---
## 自動スケーリングとワークロードの関係
自動スケーリングを使用すると、システムはワークロードの増加を処理するために必要なリソースを予測できます。
1. 正しい
2. 正しくない
### Explanation
Ans: "2. 正しくない"
---
## 自動スケーリングをいつ使うのか ?
次のシナリオのうち、自動スケーリングに適している候補はどれですか?
1. アプリケーションへのアクセスを必要とするユーザーの数が、定期的なスケジュールに従って変化します。 たとえば、金曜日には他の曜日よりシステムを使用するユーザーが増えます。
2. 要求が急増して、システムが停止する可能性があります。 ワークロードは指数関数的に増加しており、このアクティビティの急増には理由がないように見えます。
3. 時間の経過と共に、サービスの人気が高くなっており、増加するトラフィックを処理する必要があります。
4. 組織はキャンペーンを実施しており、次の 2 週間は Web サイトへのトラフィックが増加すると予想されます。 キャンペーンの開始時に、予想される需要を処理するのに十分なリソースを使用できることを確認します。
### Explanation
Ans: "1. アプリケーションへのアクセスを必要とするユーザーの数が、定期的なスケジュールに従って変化します。 たとえば、金曜日には他の曜日よりシステムを使用するユーザーが増えます。"
スケジュールに従って実行するように自動スケーリングを構成することもできます。
"2": アクティビティの急増は、システムを過負荷にしようとするサービス拒否攻撃が原因であると考えられます。 自動スケーリングでは、問題は解決されません。 これらの要求がシステムをホストするサーバーに到達する前に、セキュリティ インフラストラクチャを使用して要求をフィルター処理します。
"3": このシナリオでは、おそらく手動スケーリングの方がより適切なオプションです。 需要は、長期間にわたって増え続けています。
"4": キャンペーンが開始する前にシステムを手動でスケーリングし、アクティビティを監視して、キャンペーンが終了したら元に戻します。
---
## 自動スケーリングルールに関する質問1
4 つの自動スケーリング ルールで自動スケーリング条件を定義しました。 1 番目のルールでは、CPU 使用率が 70% に達するとスケールアウトします。 2 番目のルールでは、CPU 使用率が 50% を下回ると元にスケールインします。 3 番目のルールでは、メモリの占有率が 75% を超えるとスケールアウトします。 4 番目のルールでは、メモリの占有率が 50% 未満になると元にスケールインします。 システムがスケールアウトするのは次のどのときですか?
1. CPU 使用率が 70% に達したとき、または、メモリの占有率が 75% を超えたとき
2. CPU 使用率が 70% に達したとき、かつ、メモリの占有率が 75% を超えたとき
3. 1 つの自動スケーリング条件で、これを行うことはできません。 1 つの自動スケーリング条件に含めることができるのは、同じメトリックを使用する自動スケーリング ルールだけです
### Explanation
Ans: "1. CPU 使用率が 70% に達したとき、または、メモリの占有率が 75% を超えたとき"
スケールアウトするかどうかを決定するときは、スケールアウト ルールの いずれか が満たされた場合に自動スケーリング アクションが実行されます。
スケールインのときは、スケールイン ルールの すべてが満たされた場合にのみ、自動スケーリング アクションが実行されます。
---
## 自動スケーリング動作2
自動スケーリング ルールでは、ディスク キューの長さが 10 を超えるとインスタンスの数を増やすスケールアウト アクションが定義されています。 システムは 2 分前にスケールアウトしましたが、ディスク キューの長さはまだ 10 を超えています。 システムが再びスケールアウトするのは次のどのときですか?
1. 自動スケーリング ルールではすぐに別の自動スケーリング アクションがトリガーされ、ディスク キューの長さが 10 未満になるか、最大数のインスタンスが作成されるまで、それが続けられます。
2. 自動スケーリング ルールは、システムがスケールインして戻るまで、再び実行されることはありません。
3. 自動スケーリング ルールでは、ルールに対する "クール ダウン" 期間が経過するまで、再度アクションがトリガーされることはありません。 その時点でディスク キューの長さがまだ 10 を超えている場合は、アクションが実行されます。
### Explanation
Ans: "3. 自動スケーリング ルールでは、ルールに対する "クール ダウン" 期間が経過するまで、再度アクションがトリガーされることはありません。 その時点でディスク キューの長さがまだ 10 を超えている場合は、アクションが実行されます。"
---
## Cosmos DB の RU
正誤問題:同じデータに対する特定のデータベース操作に使用される RU の数は、時間の経過と共に変わります。
1. 正
2. 誤り
### Explanation
Ans: "2. 誤り"
Azure Cosmos DB では、特定のデータセットに対する特定のデータベース操作の RU の数が確実に決定的になります。
---
## Cosmos DB の RU数は何に基づいて変化するのか ?
ドキュメントの書き込みに使用する要求ユニット数に影響するのは、次のうちどれですか?
1. ドキュメントのサイズ
2. アイテム プロパティの数
3. インデックス作成ポリシー
4. 上記のすべて
### Explanation
Ans: "4. 上記のすべて"
要求ユニットをプロビジョニングするとき、3 つのオプション (ドキュメントのサイズ、アイテム プロパティの数、インデックス作成ポリシー) のすべてが考慮されます。
---
## RU の性質
Azure Cosmos DB の要求ユニット (RU) に関する次の記述のうち、誤っているものはどれですか?
1. 1 KB のアイテムを読み取るのにかかるコストは約 1 要求ユニット (つまり 1 RU) です。
2. プロビジョニングされた RU の数を超えた場合、要求は速度制限されます。
3. 要求ユニットの数を設定したら、この数を変更することはできません。
4. Azure Cosmos コンテナー (またはデータベース) 上で 'R' 個の RU をプロビジョニングした場合、Azure Cosmos DB では、ご利用のアカウントに関連付けられた各リージョンで 'R' 個の RU が確実に利用できるようになります。
s
### Explanation
Ans: "3. 要求ユニットの数を設定したら、この数を変更することはできません。"
コンテナーまたはデータベースにプロビジョニングされた要求ユニットの数は増減することができます。
---
## Azure Cosmos DB コンテナーの作成後に、パーティション キーを 追加できるのか ?
正誤問題: Azure Cosmos DB コンテナーの作成後に、パーティション キーを 追加 できます。
1. 正しい
2. いいえ
### Explanation
Ans: "2. いいえ"
パーティション キーは、コンテナーの作成時にのみ設定できます。
---
## パーティションキーの選び方
組織では、1 秒ごとに数百万の車両から生成される車両テレメトリ データを格納するために、Azure Cosmos DB を使用することを計画しています。 ストレージの分散を最適化するパーティション キーのオプションは次のうちどれですか?
1. 車両モデル
2. WDDEJ9EB6DA032037 のような車両識別番号 (VIN)
### Explanation
Ans: "2. WDDEJ9EB6DA032037 のような車両識別番号 (VIN)"
自動車製造元では、1 年を通してトランザクションが発生しています。 このオプションでは、パーティション キー値の間でよりバランスのとれたストレージの分散が行われます。
"2": ほとんどの自動車製造元には、数十のモデルしかありません。 このオプションは最も大まかなものである可能性があり、一定数の論理パーティションが作成され、すべての物理パーティション間で均等にデータが分散されない場合があります。
