AZ-500 の模擬問題を解きながら「Azure Policy の規制準拠イニシアチブ、どれが組み込みでどれがカスタム？」と迷った人は多いと思います。本記事では、実際に議論になった誤答問題を題材に、GDPR / ISO 27001 / FedRAMP High / PCI DSS 3.2.1 の違いと、試験・実務の両面からの押さえどころを整理します。
AZ-500 模擬問題の内容整理
まずは問題の整理から始めましょう。設問の要点は次のとおりです。
- 「Azure Policy で、どの規制について カスタム イニシアチブ（＝ポリシー セット） を作成する必要があるか？」を問う
- 選択肢は次の 4 つ
- FedRAMP High
- PCI DSS 3.2.1
- GDPR
- ISO/IEC 27001:2013
- 模擬試験の採点結果：GDPR が正解 と表示される
- しかし受検者から「GDPR は Azure ポータルに組み込みイニシアチブがあるのでは？」という指摘
この記事では、この模擬問題の「本来の正解」と、その背景になっている Azure Policy / Regulatory Compliance の仕組みを、試験対策と実務の両面から解説します。
結論：模擬問題としての正解は「PCI DSS 3.2.1」
先に結論を書くと、模擬問題の意図・文脈を踏まえた場合、正解は「PCI DSS 3.2.1」 と見るのが妥当です。
理由はシンプルで、
- GDPR、ISO/IEC 27001:2013、FedRAMP High には Azure Policy の 規制準拠 (Regulatory Compliance) 向け組み込みイニシアチブ が存在し、ポータルからそのまま割り当て可能であるため
- 一方、模擬問題が想定するタイミングでは PCI DSS 3.2.1 の組み込みイニシアチブが無く、自分でカスタム イニシアチブを定義する必要があったため
実際、Microsoft Learn の Q&A でも、同様の趣旨で「GDPR は組み込みイニシアチブがあるので誤りであり、PCI DSS 3.2.1 がカスタム対象」と説明されています。
ただし、ここで重要なポイントが 1 つあります。
- 現在の Azure では、PCI DSS 3.2.1 向けの Regulatory Compliance built-in イニシアチブが公式ドキュメントに掲載されている ことです。
つまり、
- 模擬問題が作成された当時：GDPR / ISO27001 / FedRAMP High は組み込みあり、PCI DSS 3.2.1 はカスタムが必要 → 正解は「PCI DSS 3.2.1」
- 現在（2025 年時点）の Azure：PCI DSS 3.2.1 用の Regulatory Compliance イニシアチブもドキュメントに登場している
という「時間差」があるため、学習時にはこのギャップを意識しておく必要があります。
Azure Policy と「規制準拠イニシアチブ」の基礎
問題の狙いを理解するには、まず Azure Policy とイニシアチブの基本を押さえておく必要があります。
Azure Policy の役割
Azure Policy は、Azure 上のリソースに対して「こういうルールで作って・運用してね」という ガバナンスのルールセット を定義・強制する仕組みです。
- リソースの構成をチェックして、準拠していなければ「非準拠」として検出（Effect:
Audit） - 条件を満たさないデプロイを ブロック（Effect:
Deny） - 足りない設定を 自動的にデプロイ（Effect:
DeployIfNotExists）
などの振る舞いを、ポリシー定義で JSON として記述します。
イニシアチブ（ポリシー セット）とは
1 つ 1 つのポリシー定義をバラで管理していると、運用が非常に大変です。そこで登場するのが イニシアチブ（policy set） です。
- 関連する複数のポリシー定義を 1 つのまとまり として管理する単位
- たとえば「ISO 27001:2013 準拠」「PCI DSS 準拠」といった目的ごとにまとめる
- 実際の運用では、サブスクリプションや管理グループに イニシアチブ単位 で割り当てるのが基本
特にコンプライアンス系のイニシアチブは、Azure ポータルの「規制準拠 (Regulatory Compliance)」ビューと連動し、Microsoft Defender for Cloud からも一元的にスコアを見ることができます。
組み込みイニシアチブとカスタム イニシアチブ
イニシアチブには大きく 2 種類あります。
| 種類 | 説明 | 代表例 |
|---|---|---|
| 組み込み (built-in) | Microsoft があらかじめ定義してくれているイニシアチブ。Regulatory Compliance 系、多数のベストプラクティス系が存在。 | ISO 27001:2013、FedRAMP High、PCI DSS v4.0、Microsoft Cloud Security Benchmark など |
| カスタム | 自社要件に合わせて、ユーザーが定義するイニシアチブ。既存の組み込みをコピー & 調整するパターンが多い。 | 「自社セキュリティ標準 2025」「業種固有ガイドライン対応」など |
AZ-500 の問題は、この「どれが組み込みの Regulatory Compliance イニシアチブとして存在し、どれがカスタム前提か」を理解しているかを問うているわけです。
各規制ごとの Azure Policy 組み込み状況
次に、今回の選択肢となった 4 つの規制ごとに、Azure Policy の組み込み状況を整理します。
GDPR（EU 一般データ保護規則）
GDPR は、EU / EEA 居住者の個人データを扱うすべての組織に影響する、非常に広範なプライバシー規制です。
Azure 側ではかなり早い段階から、
- GDPR 対応の Azure Security & Compliance Blueprints
- GDPR を支援する Azure Policy のポリシー セット
などが提供されており、GDPR 準拠を意識した組み込みイニシアチブ として利用できる形になっていました。
そのため、「GDPR に対してカスタム イニシアチブが必須である」という模擬試験の採点は、少なくとも現在の Azure の仕様と比べると明らかに不自然です。
ISO/IEC 27001:2013
ISO/IEC 27001:2013 は、情報セキュリティマネジメントシステム（ISMS）の国際標準です。Azure はこの規格に対して、かなり手厚いサポートを提供しています。
- Azure Policy の Regulatory Compliance built-in イニシアチブ として ISO 27001:2013 向けの定義を提供
- 各コントロールと Azure Policy 定義の対応関係が、公式ドキュメントで公開されている
ポータルからも「ISO 27001:2013」を検索すれば、Regulatory Compliance イニシアチブとして割り当て可能であることが確認できます。
したがって、ISO 27001:2013 に対して、ゼロからカスタム イニシアチブを作る必要は原則ありません。
FedRAMP High
FedRAMP は、アメリカ合衆国連邦政府向けのクラウドセキュリティ認証制度で、その中でも High は最も高い機密性レベルに対応します。
Azure は、商用 Azure / Azure Government の両方で、FedRAMP High 向けの Azure Policy イニシアチブを提供しています。
- 「FedRAMP High」向け Regulatory Compliance built-in イニシアチブが存在
- 各コントロールと Azure Policy 定義とのマッピングが公開されており、ポータルからそのまま割り当て可能
よって、「FedRAMP High はカスタム イニシアチブ必須」という選択肢は誤りです。
PCI DSS 3.2.1
最後に問題の焦点である、PCI DSS 3.2.1 です。PCI DSS はクレジットカード情報保護のための国際セキュリティ基準で、バージョン 4.0 が新しい世代としてリリースされています。
しばらくの間、Azure Policy が公式に提供していたのは、主に PCI DSS v4.0 / v4.0.1 向けの Regulatory Compliance イニシアチブでした。この状態を前提にすると、
- PCI DSS v4.*：組み込みイニシアチブがある
- PCI DSS 3.2.1：バージョン違いのため、規制側から「3.2.1 で評価してほしい」と言われた場合は カスタム イニシアチブを作る必要がある
というのが、模擬問題が狙っていたポイントです。
ところが現在のドキュメントを見ると、PCI DSS 3.2.1 向けの Regulatory Compliance built-in イニシアチブの存在 が明示されており、Azure Policy 定義とのマッピングも公開されています。
このため、
- 模擬問題の作成時点では「PCI DSS 3.2.1 は組み込みがない → カスタム必須」という設計だった
- 現在の Azure では「PCI DSS 3.2.1 に対しても built-in イニシアチブが用意されている」
という時間差が生じています。
模擬問題の採点が「GDPR 正解」になっていた理由を推測する
では、なぜ模擬試験では GDPR が正解 とされていたのでしょうか。考えられる可能性は次の 2 つです。
- 問題作成者が GDPR の組み込みイニシアチブの存在を見落としていた
- Azure Policy のアップデートに問題集が追従できていなかった（採点キーの更新漏れ）
Azure のコンプライアンス関連機能は、ここ数年でかなり頻繁にアップデートされています。
- 新しい規制向けのイニシアチブが追加される
- 既存イニシアチブが v3 → v4 のように バージョンアップ する
- Microsoft Defender for Cloud 側の規制準拠ダッシュボードとの連携内容が変わる
といった変化が日常茶飯事で、そのたびにドキュメントや UI も順次更新されていきます。
模擬試験ベンダーがこれらの変化をリアルタイムで追従するのは難しいため、
- 当時の Azure では「GDPR に対応するイニシアチブが弱かった」時期の知識で問題を作ってしまった
- あるいは、イニシアチブではなく Blueprint ベースの古い情報を元にしていた
といった背景が考えられます。
いずれにせよ、現在の Azure の仕様に照らすと「GDPR が唯一のカスタム対象」という採点は誤りである、と捉えて問題ありません。
試験対策としての「覚え方」
AZ-500 対策としては、あまり細かいバージョン番号を暗記してもアップデートですぐに古くなってしまいます。そこで、以下のような「考え方のパターン」を抑えるのがおすすめです。
パターンで覚える：メジャー規制は基本「組み込みあり」
まず大枠として、次のように覚えておくと迷いにくくなります。
| 規制・標準 | Azure Policy の基本スタンス | 試験での扱いのイメージ |
|---|---|---|
| GDPR | Blueprint やポリシー セットが早期から提供されている。準拠支援の仕組みは Azure 側で用意されている。 | 「GDPR は組み込みイニシアチブがある」前提で考える。 |
| ISO/IEC 27001:2013 | Regulatory Compliance built-in イニシアチブとマッピングが公開されている。 | 「ISO 27001 は組み込みあり」が基本。 |
| FedRAMP High | Azure / Azure Government で built-in イニシアチブが提供。 | 「FedRAMP High も組み込みあり」として扱う。 |
| PCI DSS | v4.0 / v4.0.1 など最新版に重点が置かれ、旧版 3.2.1 はタイミングによって扱いが揺れやすい。 | 「バージョンを聞かれたら、ひとまず怪しむ」ぐらいの意識を持つ。 |
特に、「わざわざバージョン番号まで指定して聞いてきている」問題では、
- PCI DSS 3.2.1 のように、旧版を指定している選択肢
を重点的に疑う癖をつけておくと、今回のような問題で引っかかりにくくなります。
暗記フレーズ例
試験勉強向けに、簡単な語呂合わせ的な覚え方を挙げておきます。
- 「GDPR・ISO・FedRAMP は、だいたい おまかせ」
→ Azure が組み込みイニシアチブを用意してくれているので、自分で 0 から作るケースは少ない。 - 「PCI は バージョン要確認」
→ v4.* なのか 3.2.1 なのかで扱いが変わる問題が出てもおかしくない。
この程度のざっくりした覚え方で十分です。細かい定義は、常に Microsoft Learn の最新ドキュメントを確認する前提で考えましょう。
Azure ポータルで組み込みイニシアチブを確認する手順
実務でも試験でも、「結局自分のサブスクリプションではどうなっているのか」を確認する癖をつけておくことが重要です。以下は、Azure ポータルで Regulatory Compliance イニシアチブを確認する代表的な手順です。
- Azure ポータルで左メニューから 「Policy」 を開く
- 左のメニューから 「定義 (Definitions)」 を選択
- 上部のタブから 「イニシアチブ定義 (Initiative definitions)」 を選ぶ
- 「種類 (Type)」フィルタで
Built-inを選択し、組み込みだけに絞り込む - 検索ボックスに「
ISO 27001」「FedRAMP」「PCI」「GDPR」などを入力して検索 - ヒットしたイニシアチブをクリックし、中身のポリシー定義やパラメーターを確認
この操作に慣れておくと、
- 問題集の解説が古くないかを、自分で検証できる
- 実務で「この規制って Azure 側にテンプレートない？」と聞かれたときにすぐ調べられる
という大きなメリットがあります。
PCI DSS 3.2.1 をカスタム イニシアチブで実現する流れ
次に、模擬問題の解説にもあった「PCI DSS 3.2.1 を求められた場合の対応」について、実務ベースでの進め方を整理します。
1. 要件の確認：本当に 3.2.1 固定なのか？
まず確認すべきは、「なぜ 3.2.1 でなければいけないのか？」という点です。
- 監査法人やカードブランドの要件で、明示的に 3.2.1 を指定 しているのか
- 単にドキュメントが古くて、実は v4.0 を受け入れてくれる のか
もし v4.* ベースで構わないのであれば、Azure が提供している PCI DSS v4.* の組み込みイニシアチブをそのまま活用 した方が、管理コストを大きく抑えられます。
2. 組み込みイニシアチブを「ベースライン」として利用
それでも「どうしても 3.2.1 ベースで見たい」という要件が残る場合は、Azure Policy の組み込みを ベースラインとして流用 します。
- ポータルで PCI DSS v4.0 / v4.0.1 のイニシアチブを開く
- 含まれているポリシー定義と、PCI DSS 3.2.1 のコントロール一覧を突き合わせて 差分を洗い出す
- 3.2.1 にしか存在しない／逆に v4.* 特有のコントロールを整理する
そのうえで、
- 3.2.1 にも v4.* にも共通 するコントロール → 組み込みのポリシー定義をそのまま再利用
- 3.2.1 固有 のコントロール → 必要に応じて カスタム ポリシー定義 を作成して追加
- v4.* 固有 のコントロール → 3.2.1 ベースのイニシアチブからは外す（または「参考」として別イニシアチブに切り出す）
といった形で、自社用の「PCI DSS 3.2.1 イニシアチブ」 を構築します。
3. イニシアチブの新規作成と Effect の調整
実際にイニシアチブを新規作成する際のポイントは次のとおりです。
- 最初は すべて Audit（監査）モード で始める
- いきなり Deny を入れると、本番システムのデプロイが止まるリスクがあります
- 監査結果を見ながら、影響が少ないものから Deny / DeployIfNotExists に切り替えていく
- イニシアチブの パラメーター（対象リージョン、タグ、SKU など） を、組織の標準に合わせて固定・制限しておく
Azure Policy イニシアチブの JSON 構造については、公式ドキュメントの「initiative definition structure」が参考になります。
4. Microsoft Defender for Cloud の規制準拠ダッシュボードと連携
イニシアチブを割り当てたら、Microsoft Defender for Cloud の「規制準拠 (Regulatory Compliance)」ビューでスコアを可視化します。
- PCI DSS 3.2.1 用のイニシアチブを割り当てたスコープに対して、Defender for Cloud 側でも評価を有効化
- 「コントロール別・ポリシー別」にどこが非準拠なのかを確認
- 修正アクションの自動化（Logic Apps / ワークフロー）と組み合わせて、継続的な準拠維持プロセスを構築
こうすることで、「監査の時だけ慌てて準備する PCI DSS」から、「日常的にモニタリングされている PCI DSS」へと、運用の成熟度を引き上げることができます。
最新情報との付き合い方：試験と実務のギャップをどう埋めるか
ここまで見てきた通り、
- 模擬問題が想定する世界：
- GDPR / ISO 27001 / FedRAMP High … 組み込みイニシアチブあり
- PCI DSS 3.2.1 … 組み込みがない → カスタム必須 → これが正解
- 現在の Azure 公式ドキュメントの世界：
- ISO 27001:2013、FedRAMP High、PCI DSS 3.2.1 など、多数の規制に対して Regulatory Compliance built-in イニシアチブが用意されている
というギャップが存在します。
この差を埋めるためのポイントは次の 3 つです。
1. 試験問題は「出題当時の世界」を前提にしている
AZ-500 に限らず、クラウド資格試験は、必ずしも 最新のポータル UI やサービス仕様 にリアルタイムで追従しているわけではありません。
- 問題が作られたタイミングのベストプラクティスや UI を前提にしている
- それから数年経つと、サービス側が進化して問題文の前提が古くなる
そのため、模擬問題に出会ったら、
- 「今の Azure ではどうなっているか」 を自分の目で確かめる
- 矛盾があっても、「試験問題としてはこう解く」「実務ではこうする」と 割り切って二重で理解 する
という姿勢が重要です。
2. 実務では「とにかく公式ドキュメントを信じる」
一方、日々の仕事で環境設計や監査対応を行う場合は、
- Microsoft Learn / Azure ドキュメント（特に Regulatory Compliance 関連ページ）
- Microsoft Defender for Cloud の規制準拠ビュー
を常にソース・オブ・トゥルースとして扱うべきです。
サードパーティのブログや書籍、模擬試験はあくまで「参考情報」であり、少しでも違和感があったら、
- Azure ポータルで実際に該当イニシアチブを検索する
- 公式ドキュメントを検索して確認する
という二段階チェックを習慣化しましょう。
3. 「バージョン番号」を見る癖をつける
最後にもう一度強調したいのが、
- PCI DSS 3.2.1 vs PCI DSS v4.0
- ISO/IEC 27001:2013 vs ISO/IEC 27001:2022
といった バージョン番号の違い をきちんと意識する癖です。
規制準拠系の問題では、「わざわざバージョンまで書いてある」選択肢には必ず意味がある と考えた方がよく、今回の模擬問題もまさにこのパターンに該当します。
今回の模擬問題を一言でまとめると
最後に、今回の AZ-500 模擬問題のポイントを、改めて一言でまとめておきます。
| 規制名 | 模擬問題が想定していた世界 | 現在の Azure ドキュメントの世界 | コメント（試験対策の観点） |
|---|---|---|---|
| GDPR | 組み込みイニシアチブあり。カスタム必須ではない。 | GDPR 準拠を支援する Blueprint / ポリシー セットが存在。 | 「GDPR が唯一のカスタム対象」という採点は誤りと考えてよい。 |
| ISO/IEC 27001:2013 | 組み込み Regulatory Compliance イニシアチブあり。 | Regulatory Compliance built-in とマッピングが明示されている。 | 試験でも実務でも「組み込みあり」で覚えておく。 |
| FedRAMP High | 組み込みイニシアチブあり。 | Azure / Azure Government 向け built-in イニシアチブが存在。 | やはり「組み込みあり」で記憶して問題ない。 |
| PCI DSS 3.2.1 | 組み込みがない → カスタム イニシアチブが必要 → これが模擬問題の正解。 | 現在は PCI DSS 3.2.1 向けの Regulatory Compliance built-in イニシアチブもドキュメントに掲載。 | 「バージョン差に注意」の典型例。試験では問題文の意図を読みつつ回答する。 |
このように整理しておけば、同種の問題に出会ったときにも、
- どの規制が Azure の組み込みイニシアチブでカバーされているのか
- どこからカスタムの出番になるのか
を論理的に判断できるようになります。
まとめ
本記事では、AZ-500 模擬問題の誤答をきっかけに、Azure Policy の規制準拠イニシアチブと GDPR / ISO 27001 / FedRAMP High / PCI DSS 3.2.1 の関係を整理しました。
- 模擬問題の意図としては、PCI DSS 3.2.1 がカスタム イニシアチブ対象 であり、GDPR を正解にする採点は誤りと考えられる
- ただし、Azure 自体は日々アップデートされており、現在は PCI DSS 3.2.1 向け built-in イニシアチブもドキュメントに登場している
- 試験対策では「GDPR / ISO 27001 / FedRAMP は組み込みあり」「PCI はバージョン要確認」のパターンで覚えるとよい
- 実務では、必ず Azure ポータルと Microsoft Learn の最新ドキュメント を確認し、問題集の解説を鵜呑みにしない
AZ-500 の学習は、そのまま Azure セキュリティ設計の実務にも直結します。模擬問題の「正解」が古くなっているケースに遭遇したら、
- それをきっかけに Azure ポータルで組み込みイニシアチブを確認する
- 公式ドキュメントで規制とポリシーのマッピングを調べてみる
という一歩踏み込んだ学習をしておくと、単なる「試験対策」を超えて、現場で通用する知識として定着していきます。
ぜひ、今回の PCI DSS 3.2.1 のような「バージョンに着目する問題」をきっかけに、Azure Policy と規制準拠の関係を深く理解し、AZ-500 本番と実務の両方で活かしていってください。
コメント