AZ-305：Designing Microsoft Azure Infrastructure Solutions ID・ガバナンス・監視ソリューションの設計 問2
ID・ガバナンス・監視ソリューションの設計／ログと監視ソリューションの設計ある企業は 20 個のサブスクリプションに散在する約 300 台の Windows/Linux 仮想マシンから、ゲスト OS のパフォーマンスカウンターとイベントログを Log Analytics ワークスペースへ収集しようとしています。今後も仮想マシンは頻繁に追加されます。運用チームは、新しい仮想マシンに対して手動のエージェント導入や個別の収集設定を行わずに済むようにしたいと考えています。この監視の収集設計として最適なものはどれですか。
当サイトのオリジナル問題（AZ-305：Designing Microsoft Azure Infrastructure Solutionsの出題範囲「ID・ガバナンス・監視ソリューションの設計」に対応。実際の試験問題ではありません）
- A各仮想マシンの診断設定で、プラットフォームメトリックとゲスト OS のログをストレージアカウントへ出力し、運用チームが必要時にダウンロードして分析する
- BAzure Monitor エージェントとデータ収集規則（DCR）を、管理グループ スコープの Azure Policy（DeployIfNotExists）で自動的に新規・既存の仮想マシンへ適用する
- CLog Analytics エージェント（MMA）をカスタムスクリプト拡張機能でデプロイし、収集内容をワークスペース側のエージェント構成で一元定義する
- D仮想マシンごとに Azure Automation の Runbook を作成して OS 内のログを定期的に取得し、結果をワークスペースへ HTTP データ収集 API で送信する
正解：B
解説
現行の Azure Monitor の収集基盤は Azure Monitor エージェント（AMA）とデータ収集規則（DCR）です。何を・どこへ収集するかを DCR で宣言的に定義し、Azure Policy の DeployIfNotExists 効果で管理グループなど広いスコープに割り当てれば、既存・新規の仮想マシンへエージェントと DCR の関連付けが自動的に展開されます。Log Analytics エージェント（MMA）は 2024 年 8 月に廃止されており、新規設計では選べません。診断設定は主にプラットフォームのログ・メトリック用で、ゲスト OS 内のカウンターやイベントログの収集設計の中心ではありません。
選択肢ごとの解説
- A誤り。診断設定はプラットフォームのメトリックやログの出力が中心で、ゲスト OS のイベントログ収集には向きません。ストレージ出力では Log Analytics でのクエリや警告にも使えません。
- B正しい。AMA と DCR を Azure Policy で大規模に自動展開でき、新規仮想マシンにも手動作業なしで同じ収集設定が適用されます。
- C誤り。Log Analytics エージェント（MMA）は廃止済みで、新規構成の選択肢として不適切です。個別デプロイを要する点も要件に合いません。
- D誤り。Runbook を VM ごとに作る方式は自前実装で運用負荷が高く、収集の信頼性やスケールの面でも Azure Monitor エージェントによる標準の収集に劣ります。