WEB問題集
AZ900-Manage#89
Azure Policy のカスタム定義で、対象リソースに既定値や設定を自動的に付与・修正する効果はどれですか。
解説
【正解: A】の理由
Modify はリソースのプロパティや Tag を作成/更新時に自動で追加・変更する効果で、CostCenter Tag を強制付与する等の用途に最適です。既存リソースも remediation タスクで一括修正できます。
【他選択肢が違う理由】
Modify はリソースのプロパティや Tag を作成/更新時に自動で追加・変更する効果で、CostCenter Tag を強制付与する等の用途に最適です。既存リソースも remediation タスクで一括修正できます。
【他選択肢が違う理由】
- B. 違反作成をブロック: Deny は条件に一致する作成/更新を拒否する効果で、リソースを修正するのではなく弾く動作です
- C. 非準拠を記録のみ: Audit は違反をログ出力するだけで、リソース自体を変更する機能はありません
- D. ポリシー無効化: Disabled はポリシー評価を停止する設定で、リソース変更は行いません
AZ900-Manage#90
PCI DSS や ISO 27001 等の規制要件に対応する複数のポリシーをまとめて一括適用するための仕組みはどれですか。
解説
【正解: A】の理由
Initiative は関連する複数の Policy 定義をグループ化した集合で、PCI DSS / HIPAA / ISO 27001 等の組み込み Initiative を割り当てるだけで規制要件への準拠ポリシーを一括適用できます。コンプライアンス評価も Initiative 単位で集約されます。
【他選択肢が違う理由】
Initiative は関連する複数の Policy 定義をグループ化した集合で、PCI DSS / HIPAA / ISO 27001 等の組み込み Initiative を割り当てるだけで規制要件への準拠ポリシーを一括適用できます。コンプライアンス評価も Initiative 単位で集約されます。
【他選択肢が違う理由】
- B. 削除/変更防止: Resource Locks は誤操作防止の機能で、規制ポリシー集合の適用は行いません
- C. 階層管理単位: Management Group は割り当てスコープを提供しますが、ポリシー集合そのものではありません
- D. 非推奨予定: Azure Blueprints は 2026 年 Deprecated で、後継は Template Specs + Deployment Stacks です
AZ900-Manage#91
適用済みポリシーから特定スコープを一時的に除外し、期限と理由を記録する仕組みはどれですか。
解説
【正解: A】の理由
Policy Exemption は特定リソースやリソース グループを既存の割り当てから例外指定する機能で、期限 (expiresOn) と理由 (waiver / mitigated) を必須項目として記録できます。監査証跡を残しつつ柔軟な運用が可能です。
【他選択肢が違う理由】
Policy Exemption は特定リソースやリソース グループを既存の割り当てから例外指定する機能で、期限 (expiresOn) と理由 (waiver / mitigated) を必須項目として記録できます。監査証跡を残しつつ柔軟な運用が可能です。
【他選択肢が違う理由】
- B. 全体無効化: Disabled は割り当て全体を停止する設定で、スコープ単位の例外管理ではありません
- C. 削除防止: Resource Lock は CanNotDelete/ReadOnly を付与する機能で、ポリシー除外とは無関係です
- D. 権限拒否: Deny Assignment はアクションを拒否する RBAC 機能で、ポリシー評価の例外には使えません
AZ900-Manage#92-1
注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。
前提
ある大企業が複数事業部の Azure 環境にガバナンスを段階的に展開します。各事業部の独自要件と組織全体の統一要件を両立する必要があります。
解決策
Management Groups の階層に Initiative を割り当て、配下サブスクリプションに自動継承で組織全体のガバナンスを適用する。
この解決策は目的を満たしますか?
解説
【判定: はい】の理由
Management Groups にルート寄りで Initiative を割り当てると、配下の全サブスクリプションへ自動継承され組織横断の統一ガバナンスを実現できます。事業部固有要件は配下スコープに追加割り当てして両立できます。
【「いいえ」が違う理由】
継承モデルは大規模組織での標準アプローチで、ルートでの統一適用と配下での個別追加を組み合わせる設計はマイクロソフト推奨です。除外が必要な場合も Exemption で柔軟に対応できます。
Management Groups にルート寄りで Initiative を割り当てると、配下の全サブスクリプションへ自動継承され組織横断の統一ガバナンスを実現できます。事業部固有要件は配下スコープに追加割り当てして両立できます。
【「いいえ」が違う理由】
継承モデルは大規模組織での標準アプローチで、ルートでの統一適用と配下での個別追加を組み合わせる設計はマイクロソフト推奨です。除外が必要な場合も Exemption で柔軟に対応できます。
AZ900-Manage#92-2
注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。
前提
ある大企業が複数事業部の Azure 環境にガバナンスを段階的に展開します。各事業部の独自要件と組織全体の統一要件を両立する必要があります。
解決策
カスタム Policy で組織固有のルール (CostCenter Tag 必須、許可リージョン制限) を Deny 効果で強制する。
この解決策は目的を満たしますか?
解説
【判定: はい】の理由
組み込みポリシーで対応できない組織固有要件はカスタム Policy で表現するのが正攻法です。CostCenter Tag 必須や許可リージョン制限を Deny 効果で適用すれば、違反リソースの作成自体を未然に防げます。
【「いいえ」が違う理由】
カスタム Policy は JSON 定義で柔軟にルールを記述でき、Tag やリージョン制御は典型的なユースケースです。Deny は最も強力な強制効果で、ガバナンス基盤の中核となる正しい設計です。
組み込みポリシーで対応できない組織固有要件はカスタム Policy で表現するのが正攻法です。CostCenter Tag 必須や許可リージョン制限を Deny 効果で適用すれば、違反リソースの作成自体を未然に防げます。
【「いいえ」が違う理由】
カスタム Policy は JSON 定義で柔軟にルールを記述でき、Tag やリージョン制御は典型的なユースケースです。Deny は最も強力な強制効果で、ガバナンス基盤の中核となる正しい設計です。
AZ900-Manage#92-3
注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。
前提
ある大企業が複数事業部の Azure 環境にガバナンスを段階的に展開します。各事業部の独自要件と組織全体の統一要件を両立する必要があります。
解決策
各事業部に個別にポリシーを設定させ、組織全体の統一は行わない。
この解決策は目的を満たしますか?
解説
【判定: いいえ】の理由
組織全体の統一要件を満たすには Management Groups 階層での上位適用が不可欠です。事業部任せでは標準のバラツキやセキュリティ ベースライン未達が生じ、規制対応や監査での説明責任を果たせません。
【「はい」が違う理由】
設問は組織統一要件との両立を求めており、個別委任のみでは要件を満たせません。ルートで統一、配下で追加という階層設計こそが大企業ガバナンスの基本パターンです。
組織全体の統一要件を満たすには Management Groups 階層での上位適用が不可欠です。事業部任せでは標準のバラツキやセキュリティ ベースライン未達が生じ、規制対応や監査での説明責任を果たせません。
【「はい」が違う理由】
設問は組織統一要件との両立を求めており、個別委任のみでは要件を満たせません。ルートで統一、配下で追加という階層設計こそが大企業ガバナンスの基本パターンです。
AZ900-Manage#93
適用済みポリシーに対する全リソースの準拠状態をダッシュボードで継続的に可視化する機能はどれですか。
解説
【正解: A】の理由
Policy Compliance ダッシュボードは割り当て済み Policy / Initiative に対するリソースの準拠率と非準拠リソース一覧を継続評価で表示します。Compliant / Non-compliant / Exempt の状態を集約でき、監査証跡として活用できます。
【他選択肢が違う理由】
Policy Compliance ダッシュボードは割り当て済み Policy / Initiative に対するリソースの準拠率と非準拠リソース一覧を継続評価で表示します。Compliant / Non-compliant / Exempt の状態を集約でき、監査証跡として活用できます。
【他選択肢が違う理由】
- B. プラットフォーム障害情報: Service Health は Azure 側の障害/メンテナンス通知で、ポリシー準拠とは別領域です
- C. 最適化推奨: Advisor はコスト/性能/セキュリティ推奨を提示する機能で、ポリシー評価の集約は行いません
- D. セキュリティ姿勢指標: Secure Score はセキュリティ全般のスコアで、ポリシー準拠の専用ビューではありません
AZ900-Manage#94
Azure のガバナンスを実現する機能を 3 つ選びなさい。
3 つ選択してください
解説
【正解: A, B, C】の理由
Azure Policy はルール強制、Resource Locks は削除/変更防止、Management Groups は階層的スコープ管理を提供し、いずれもガバナンスの中核機能です。3 つを組み合わせて統制された Azure 環境を構築できます。
【他選択肢が違う理由】
Azure Policy はルール強制、Resource Locks は削除/変更防止、Management Groups は階層的スコープ管理を提供し、いずれもガバナンスの中核機能です。3 つを組み合わせて統制された Azure 環境を構築できます。
【他選択肢が違う理由】
- D. RDP/SSH 中継: Bastion はジャンプ ホスト型のリモート アクセス サービスで、ネットワーク領域に属しガバナンス機能ではありません
- E. グローバル L7 配信: Front Door は CDN / WAF / 負荷分散のエッジ サービスで、配信最適化が役割でありガバナンスとは別カテゴリです
AZ900-Manage#95
次の各ステートメントを完成させるため、最も適切な選択肢を選んでください。同じ選択肢は 2 回使用できません。
| ステートメント | 選択 |
|---|---|
リソースのコンプライアンス制御 (Tag 必須化、許可 SKU 制限など) を強制する仕組みは [ ] です。 Azure Policy は Deny / Audit / Modify 等の効果でリソースのプロパティや構成を継続評価し、規格遵守を強制します。Tag 必須化や許可 SKU 制限はその典型的ユースケースです。 | |
本番リソースの誤削除や意図しない変更を防止する仕組みは [ ] です。 Resource Locks は CanNotDelete / ReadOnly の 2 種類を提供し、RBAC 権限を持つユーザーであっても削除や変更を物理的にブロックできます。誤操作防止の最後の砦として機能します。 | |
複数サブスクリプションを階層的に束ねて統一的にポリシーや RBAC を適用する仕組みは [ ] です。 Management Groups はサブスクリプションをツリー状に束ねるコンテナで、上位で割り当てた Policy や RBAC が配下に自動継承されます。組織横断のガバナンス基盤として機能します。 |
AZ900-Manage#96
Azure Policy の展開プロセスを正しい順序に並べ替えてください。
- Identify: 統制すべき要件と対象スコープを特定する
- Author: Policy / Initiative 定義を作成する
- Test: Audit 効果でパイロット環境の影響を評価する
- Deploy: Deny / Modify 等の本番効果で全社展開する
解説
Policy 展開はまず Identify で規制要件や組織標準を棚卸ししてスコープを定めます。次に Author で組み込み Initiative を使うかカスタム定義を書くかを決め、JSON で要件を表現します。続く Test では Audit 効果でパイロット適用し、誤検知や業務影響を評価して定義を調整します。最後に Deploy で Deny / Modify 等の強制効果に切り替え、Management Groups 経由で全社へ段階展開します。この順序を守ることで業務影響を最小化しつつ確実にガバナンスを浸透できます。