AZ-900 Management & Governance #14

【正解: A】の理由
Cloud Adoption Framework は {ResourceType}-{Workload}-{Environment}-{Region}-{Instance} の命名パターンを推奨します。リソース種別 / 用途 / 環境 / リージョン / インスタンス番号を含めることで、一覧性と運用性を両立できます。

【他選択肢が違う理由】

• B. GUID 名: 一意性は確保できますが人間が判別できず、運用や課金分析で混乱を招きます
• C. リソース ID のみ: ID は自動生成されますが、検索性や可読性が低く運用に向きません
• D. タイムスタンプのみ: 用途や環境が判別できず、同時刻作成時の競合も発生します

【正解: A】の理由
CostCenter / Owner / Environment / Project / Compliance の 5 タグは、課金 / 責任 / 環境 / 案件 / 規制という運用横断の主要観点を網羅します。Azure Policy の Require a tag and its value 効果で強制すれば、未タグ リソースの作成を拒否できます。

【他選択肢が違う理由】

• B. Name タグ単独: 名前はリソース名で代替できコスト配賦や責任追跡には不足します
• C. Creator のみ: 作成者は分かりますが、コスト / 環境 / 規制の観点が欠落します
• D. 任意運用: 強制がないとタグ品質がばらつき、コスト分析やガバナンスが破綻します

【正解: A】の理由
Azure Automation Runbooks は PowerShell / Python スクリプトをクラウド上で実行する Process Automation 機能です。スケジュール / Webhook / イベントでトリガーでき、Hybrid Runbook Worker でオンプレ作業も自動化できます。

【他選択肢が違う理由】

• B. Alerts 通知のみ: 通知は届きますが、人間が手動対応する限り作業自体は自動化されません
• C. Key Vault 保管: Key Vault はシークレット保管庫であり、スクリプトを実行する機能を持ちません
• D. Blob に配置: Blob は単なるオブジェクト ストアで、配置しただけでは何も実行されません

【判定: はい】の理由
Azure Policy の Deny 効果と Require a tag and its value 効果を組み合わせれば、命名規則違反やタグ欠落のリソース作成を拒否できます。これにより全チームに統一規約が強制され、運用標準化とコスト可視化が実現します。

【「いいえ」が違う理由】
ガバナンスの根幹は規約の自動強制です。文書のみでは遵守率がばらつきますが、Policy 拒否によりプログラム的に標準が守られ、命名 / タグの一貫性が確保されます。

【判定: はい】の理由
Runbooks は VM 起動停止 / バックアップ / パッチ適用などの繰り返し作業を PowerShell / Python で自動化できます。手順がコード化されチーム間で再利用可能となり、人的ミスや時間外稼働コストを削減できます。

【「いいえ」が違う理由】
自動化は標準化の中核です。スクリプトは Git 等で一元管理でき、スケジュール実行で属人化を排除します。各チームが個別に手動運用するより、運用品質とコスト効率が大きく向上します。

【判定: いいえ】の理由
各チームが独自規則を維持する方針は、まさに現在の混乱とコスト過剰の原因そのものです。標準化を放棄すれば、リソース検索 / 課金分析 / 監査対応の負荷は増大し続け、組織横断のガバナンスは成立しません。

【「はい」が違う理由】
標準化の目的は組織共通の規約を確立することにあります。チーム独自運用の温存は問題の継続を意味し、Naming + Tagging + Automation を共通基盤として導入することが正しい解決策です。

【正解: A, B, C】の理由
Naming Convention は CAF 推奨の {Type}-{Workload}-{Env}-{Region}-{Instance} で可読性と運用性を確保し、Tagging Strategy はコスト配賦と責任明確化に必須で Policy で強制します。Automation Runbooks は繰り返し作業をコード化し属人化を排除します。三者は運用標準化の中核です。

【他選択肢が違う理由】

• D. 監査ログ無効化: ログ無効化は調査不能とコンプライアンス違反を招き、ベスト プラクティスとは正反対の運用です
• E. Owner 永続付与: 最小権限原則 (PoLP) に反し、PIM による Just-In-Time 昇格と職務分離 (SoD) が正解です

【正解: A, B, C】の理由
Azure Policy は規約をプログラム的に強制し違反を Deny / Audit します。RBAC はロールに基づく最小権限を実装し、職務分離を可能にします。Resource Locks は本番リソースの誤削除 / 誤変更を防ぐ最後のセーフティ ネットです。三者でガバナンス + 運用の防御層を形成します。

【他選択肢が違う理由】

• D. パブリック IP 直公開: ゼロトラスト原則に反し、攻撃面が極大化するため Azure Firewall / Private Endpoint で保護すべきです
• E. MFA 全廃: MFA は ID 侵害の 99% 以上を阻止する基本対策であり、全廃はセキュリティの根幹を破壊します

【正解: A】の理由
Azure Update Manager は Windows / Linux 双方のパッチ評価 / スケジュール適用 / コンプライアンス可視化を一元化するネイティブ サービスです。Arc 経由でオンプレ / 他クラウド VM にも対応し、旧 Automation Update Management の後継として再構築されました。

【他選択肢が違う理由】

• B. Backup: データ保護 / 復旧サービスでありパッチ評価 / 適用機能は持ちません
• C. Site Recovery: 災害復旧 (DR) と VM レプリケーションの領域で、パッチ管理とは別カテゴリです
• D. Bastion: ブラウザ経由の RDP / SSH 踏み台で、OS パッチを評価 / 適用する機能は提供しません