WEB問題集
AZ305-IDM#1
ある企業は複数のリージョンに展開された 50 台の仮想マシン、複数の App Service、AKS クラスターを運用しています。これらすべてのリソースのログとメトリックを一元的に収集し、KQL でクエリ可能にしたうえで、管理工数を最小化したいと考えています。推奨すべきソリューションに含めるべきものはどれですか。
解説
【正解: A】の理由
管理工数を最小化しつつ一元的に KQL クエリを実行するには、単一の Log Analytics ワークスペースに集約するのが最適です。診断設定で各リソースのプラットフォームログ/メトリックを同一ワークスペースに送ることで、クロスリソースの相関分析やアラートを一箇所で行えます。ワークスペースを分散させると横断クエリやアクセス管理が煩雑になります。
【他選択肢が違う理由】
- B: ワークスペースを分散させると横断的な KQL クエリやアクセス管理が複雑化し、管理工数が増大します。データ主権など特別な要件がない限り集約が推奨されます。
- C: Storage へのコピーは KQL クエリができず、リアルタイムの分析やアラートに適しません。
- D: Event Hubs は外部 SIEM への転送用ストリームであり、それ自体は KQL クエリやログ保持の宛先になりません。
【参考】
AZ305-IDM#2
ユーザー「user@contoso.com」に、リソースグループ「rg-prod」のスコープで「Reader」ロールを割り当てる PowerShell コマンドを完成させます。各空欄に最も適切な値を選択してください。
New-AzRoleAssignment -SignInName "user@contoso.com" `
-RoleDefinitionName "{{BLANK1}}" `
-ResourceGroupName "{{BLANK2}}"| ステートメント | 選択 |
|---|---|
{{BLANK1}} 割り当てるロール名を指定する -RoleDefinitionName には、要件である Reader を指定します。Owner は閲覧者要件に反する過剰な権限です。 | |
{{BLANK2}} RG スコープでの割り当てには -ResourceGroupName にリソースグループ名 rg-prod を指定します。 |
解説
【正解マッチング】
| 判定対象 | 正解 |
|---|---|
| {{BLANK1}} | Reader |
| {{BLANK2}} | rg-prod |
【各判定の詳細】
- 「{{BLANK1}}」→ Reader: 割り当てるロール名を指定する -RoleDefinitionName には、要件である Reader を指定します。Owner は閲覧者要件に反する過剰な権限です。
- 「{{BLANK2}}」→ rg-prod: RG スコープでの割り当てには -ResourceGroupName にリソースグループ名 rg-prod を指定します。
【参考】
AZ305-IDM#3
Azure リソースの監視を一元化するため、診断設定で各リソースのログとメトリックを Log Analytics ワークスペースへ集約します。監視基盤を構築する手順を、正しい順序に並べ替えてください。
- ログを集約する Log Analytics ワークスペースを作成する
- 対象リソースに診断設定を追加し送信先にワークスペースを指定する
- 収集するログ カテゴリとメトリックを選択する
- Kusto (KQL) クエリやアラート ルールで監視・通知を構成する
解説
【正しい順序】
- ステップ 1: ワークスペース作成
- ステップ 2: 診断設定追加
- ステップ 3: カテゴリ選択
- ステップ 4: クエリ・アラート構成
【各ステップの理由】
- ステップ 1 ワークスペース作成: ログとメトリックの集約先となる Log Analytics ワークスペースを最初に用意します。
- ステップ 2 診断設定追加: 各リソースに診断設定を追加し、送信先として作成済みワークスペースを指定して収集を有効化します。
- ステップ 3 カテゴリ選択: 必要なログ カテゴリとメトリックを選び、過剰なコストを避けつつ要件に必要なデータを収集します。
- ステップ 4 クエリ・アラート構成: KQL クエリで分析し、アラート ルールを設定して異常時に通知が飛ぶようにします。
【誤った順序の問題点】
- ワークスペース作成前に診断設定を追加する: 送信先のワークスペースが存在しないと診断設定でワークスペースを指定できず、構成が完了しません。
- カテゴリ選択を省略する: 収集対象を選ばないと必要なログが取得できず、または不要なデータでコストが増大します。
【参考】
AZ305-IDM#4
ある設計で、Azure リソースが他の Azure サービスへ資格情報レスでアクセスする ID 戦略を推奨します。マネージド ID の正しい設計判断を 2 つ選んでください。
2 つ選択してください
解説
【正解: A / B】の理由
マネージド ID の設計では、単一リソースに連動させたい場合はシステム割り当て、複数リソースで共有/独立ライフサイクルが必要な場合はユーザー割り当てを選びます。いずれも資格情報の保管・ローテーションが不要で、Entra ID 認証と RBAC で安全にアクセスできます。
【他選択肢が違う理由】
- C: シークレットのハードコードはマネージド ID を使う目的 (資格情報レス) に反します。
- D: マネージド ID は Azure リソースに紐づくため、Azure 外のサーバーには割り当てられません (その場合はサービス プリンシパル/ワークロード ID フェデレーション)。
- E: ストレージ キーは ID 戦略ではなく、最小権限/監査の観点でも劣ります。
【参考】
AZ305-IDM#5
各 ID サービスを最も適切なユースケースに対応付けてください。
項目（ドラッグしてください）
- マネージド ID
- サービス プリンシパル
- Privileged Identity Management (PIM)
- Microsoft Entra B2B コラボレーション
Azure リソースが資格情報を保持せずに別の Azure サービスへ認証する
非対話型の自動化スクリプトやアプリがディレクトリ オブジェクトとして認証する
管理者ロールを必要なときだけ時間制限付きで昇格させる
取引先のユーザーを自社テナントのアプリにゲストとして招待する
解説
【正しいマッチング完全版】
※ マネージド ID は資格情報管理が不要、サービス プリンシパルは資格情報を伴う非対話型 ID、PIM は JIT 昇格、B2B は外部ユーザー招待が主用途です。
- マネージド ID → Azure リソースが資格情報を保持せずに別の Azure サービスへ認証する
- サービス プリンシパル → 非対話型の自動化スクリプトやアプリがディレクトリ オブジェクトとして認証する
- Privileged Identity Management (PIM) → 管理者ロールを必要なときだけ時間制限付きで昇格させる
- Microsoft Entra B2B コラボレーション → 取引先のユーザーを自社テナントのアプリにゲストとして招待する
【正解マッチング】
| 項目 | カテゴリ |
|---|---|
| マネージド ID | Azure リソースが資格情報を保持せずに別の Azure サービスへ認証する |
| サービス プリンシパル | 非対話型の自動化スクリプトやアプリがディレクトリ オブジェクトとして認証する |
| Privileged Identity Management | 管理者ロールを必要なときだけ時間制限付きで昇格させる |
| Microsoft Entra B2B コラボレーション | 取引先のユーザーを自社テナントのアプリにゲストとして招待する |