Microsoft AZ-400: コードとしてのインフラストラクチャと構成管理 — 学習ガイド

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

こちらの一部です： Microsoft DevOps Engineer Expert AZ-400 — 学習ガイド. 検証済みの解答で練習： Microsoft試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

AzureにおけるInfrastructure as Code (IaC) と構成管理により、インフラストラクチャとアプリケーションの設定を繰り返し、かつ安全に定義、プロビジョニング、適用できます。AzureはネイティブでARM JSONとBicepをサポートし、TerraformやAnsibleとも緊密に連携します。構成状態は、PowerShell Desired State Configuration (DSC)、Azure Automation DSC、Chef、Puppetで宣言できます。アプリケーションの機能ロールアウトとキー管理は、Azure App ConfigurationとKey Vaultで一元管理されます。Packerで構築されたイミュータブルイメージは、ドリフトを削減します。ガバナンスは、Azure PolicyおよびKubernetes向けのOPA/Gatekeeperを用いたpolicy-as-codeとして適用されます。

AzureネイティブIaC: ARMテンプレートとBicep

ARMテンプレートは、Azure Resource Managerがリソースの作成と更新に使用する宣言型のJSONドキュメントです。トップレベルの構造には、$schema、contentVersion、parameters、variables、resources、outputsが含まれます。parametersは環境固有の入力を可能にし、variablesは計算値の導出を助け、resourcesは望ましい状態を宣言し、outputsはリソースIDなどの結果を公開します。テンプレートは、テンプレート式とランタイム関数（例: resourceId, reference, concat, uniqueString）をサポートしており、名前を構成したりプロパティを取得したりできます。

大規模なデプロイを保守可能な単位に分割するには、ネストされたテンプレートまたはリンクされたテンプレートを使用できます。ネストされたテンプレートは、Microsoft.Resources/deploymentsリソースのtemplateプロパティにJSONをインライン化します。リンクされたテンプレートは、templateLink.uriを介してリモートテンプレートを参照します。これは通常、整合性のために時間制限付きのSASを使用してAzure Storageに保存されます。すべてを単一のアーティファクトに収めることができ、各パーツにまたがるトランザクション的なデプロイが必要な場合は、ネストされたテンプレートを使用します。非常に大規模なトポロジや、リポジトリやチーム間でテンプレートを再利用する場合は、リンクされたテンプレートを使用します。deploymentsリソースでデプロイメントスコープを設定することで、必要に応じてデプロイのスコープをリソースグループ、サブスクリプション、管理グループ、またはテナントに設定します。

ARMは2つのデプロイモードをサポートしています。Incremental（デフォルト）は、テンプレートに存在するリソースを作成または更新し、宣言されていないものは削除しません。Completeは、テンプレートで指定されていないターゲットスコープのリソースを削除します。これにより、最小限のドリフトを保証するのに役立ちますが、そのスコープに対してテンプレートが権威的でない場合はリスクも高くなります。ValidateおよびWhat-If操作は、実行前に変更をプレビューしてリスクを軽減するのに役立ちます。

Bicepは、ARM JSONにコンパイルされるドメイン固有言語であり、最高クラスのオーサリング体験を提供します。リソース宣言では、シンボリック名を使用し、型を強制し、existingキーワードをサポートして再デプロイなしで既存のリソースを参照できます。parameters、variables、outputs、リソース宣言は簡潔で、親子関係とスコープは明示的です。モジュールは構成と再利用を可能にします。各モジュールはmoduleキーワードで参照されるBicepファイルであり、テンプレートスペックやOCIアーティファクトレジストリに発行したり、そこから利用したりできます。条件はリソースやモジュール上でifを用いてインラインで表現され、ループはfor式を使用して、明確な依存関係処理とともに複数のインスタンスを宣言します。ARM JSONからの移行は簡単です。az bicep decompile（またはbicep decompile）でJSONをBicepに変換し、その後モジュールにリファクタリングしてシンボリック名を採用します。BicepはARMに対してロスレスであり、プラットフォームの全機能をサポートします。bicep buildはデプロイ用の標準ARM JSONを出力します。

TerraformによるAzureでのクロスプラットフォームIaC

Terraformは、マルチクラウドやプロバイダーに依存しないワークフローが必要な場合に、AzureネイティブのIaCを補完します。azurermプロバイダーはAzure Resource Managerのリソースを管理し、バージョンを固定すべきです。プロバイダー機能を有効にするには、空であってもfeatures {}を含めます。その他の一般的なプロバイダーには、AADオブジェクト用のazureadやユーティリティ値用のrandomがあります。サービスプリンシパル、ホストされたエージェント上のマネージドID、またはAzure CLIを介して認証します。各環境に対して明確なプロバイダー構成戦略を採用し、入力変数と出力を持つ再利用可能なモジュールを一元管理します。

状態管理は非常に重要です。azurermバックエンドを使用してリモート状態をAzure Storageに保存します。resource_group_name、storage_account_name、container_name、keyを設定し、マネージドIDまたはSASで認証し、BLOBコンテナーで論理削除とバージョン管理を有効にします。バックエンドはBLOBリースを使用して状態をロックし、同時変更を防ぎます。ストレージアカウントへのアクセスはRBACでゲート制御し、オプションでPrivate Endpointで制限すべきです。状態ファイルは環境ごとに分離し、設計上、状態にシークレットを保存しないでください。必要に応じて、シークレットの取得にはKey Vaultとデータソースを使用します。

ワークスペースは、dev、test、prodなどの環境分岐のために、同じ構成内で状態を論理的に分離します。terraform workspace selectを使用し、衝突を避けるためにバックエンドのキーがワークスペースをエンコードするようにします（例: myapp-${terraform.workspace}.tfstate）。ワークスペースは、差分が小さい環境のパリティを保つのに優れています。トポロジが大幅に異なる場合は、ドリフトや条件の複雑さを避けるために、別の構成やモジュールを使用します。サービス接続とTerraform CLIタスクを使用してAzure Pipelinesと統合し、ステージ間でinit/plan/applyを標準化し、承認やポリシーチェックに基づいてapplyをゲート制御します。

アプリケーション構成、イミュータブルイメージ、およびPolicy as Code

Azure App Configurationは、アプリケーション設定と機能フラグを一元管理します。機能フラグは段階的なロールアウトを可能にします。フラグを定義し、必要に応じて、Feature Managerライブラリを通じてパーセンテージベースのロールアウトやユーザーターゲティングなどのフィルターをアタッチします。ラベルを使用すると、環境やリングごとに値を分離できます。構成スナップショットは、一連のキーとラベルに対して、特定の時点における不変のビューをキャプチャし、キーの同時変更による競合状態なしに、多くのサービスにわたって一貫性のある再現可能なロールアウトを可能にします。Key Vault参照を使用すると、シークレットをKey Vaultに保持しつつ、App Configurationには参照のみを保存できます。アプリケーションのマネージドIDは、シークレットに対するget権限を持つ必要があり、クライアントライブラリは、オプションの動的リフレッシュ機能を使用してシークレットを解決し、キャッシュします。両方のサービスでRBACとネットワーク分離を使用してアクセスを保護します。

イミュータブル（不変）インフラストラクチャは、ホストを変更する代わりに既知のイメージから再構築することで、構成ドリフトを排除します。Packerのazure-arm（現在はazure）ビルダーは、ベースOSからイメージを作成し、プロビジョナー（shell、PowerShell、Ansible）を実行し、レプリケートされたリージョンとセマンティックバージョニングを備えたShared Image Galleryに発行します。ゴールデンイメージパイプラインは通常、Packerテンプレートのlintチェック、イメージのビルド、脆弱性およびコンプライアンススキャン（例：InSpec）の実行、統合テスト、ギャラリーへのプロモート（昇格）、そしてVM Scale Setsまたはホストプールの更新を行います。VM Scale Sets、ローリングアップグレード、正常性ベースのアップグレード、および自動OSイメージアップグレードを使用すると、安全で一貫性のあるロールアウトと、以前のイメージバージョンを選択することによる簡単なロールバックが実現します。

Policy as Codeはガードレールを強制します。Azure Policyの定義は、policyRuleを持つJSONオブジェクトです。このルールはリソースのプロパティを評価し、deny、audit、append、modify、または自動修復のためのdeployIfNotExistsなどの効果を適用します。再利用のために定義をパラメータ化し、一貫した割り当てと一元的なコンプライアンス追跡のためにイニシアチブ（ポリシーセット定義）でグループ化します。ポリシーを管理グループ、サブスクリプション、またはリソースグループのスコープで割り当て、modifyおよびdeployIfNotExistsポリシーに対して修復タスクを有効にすることで、既存のリソースをコンプライアンスに準拠させます。ポリシー成果物をソース管理に保存し、プルリクエスト経由でレビューし、Bicep、ARM、またはTerraform経由でデプロイして、環境間での一貫したプロモーションを実現します。

Kubernetesの場合、OPA/Gatekeeperはアドミッション（受付）時の制約を強制します。ConstraintTemplatesはRegoポリシーとそのスキーマを定義し、Constraintsはそれらのポリシーをクラスターに対してインスタンス化します。一般的な制御には、信頼できるレジストリへのイメージの制限、ラベル/アノテーションの要求、特権付きポッドの防止などがあります。Gatekeeperは、GitOpsツール（Flux/Argo CD）やconftestによるCIテストと統合します。Azure Policy for KubernetesはGatekeeperを基盤として構築されており、AKSクラスター全体でAzureネイティブの割り当てとコンプライアンスビューを提供し、クラウドとクラスターのガバナンスを1つのポスチャーダッシュボードで統合します。

実践的な問題シナリオ

Spotifyは、Azureインフラストラクチャを標準化し、構成ドリフトを削減し、WindowsとLinux、AKS、およびVMベースのワークロードにまたがるマイクロサービス全体で安全な機能ロールアウトを加速させる必要があります。

ドメイン（ネットワーク、データ、コンピューティング）ごとにBicepモジュールでクラウドリソースをモデル化し、管理グループにスコープされたサブスクリプション経由でデプロイします。これにより、ARM JSONの冗長さをなくし、型付けされた保守可能な宣言、明確なスコープ設定、および再利用が実現します。
複数のチームが利用する共有プラットフォームサービスには、少数のリンクされたARMテンプレートスペックを使用します。テンプレートスペックとしてホストされたリンクテンプレートは、バージョン管理された不変の成果物を提供し、プラットフォームの更新サイクルをアプリチームから切り離します。
クラウド間のエッジおよびCDNの依存関係にはTerraformを選択し、azurermバックエンドを使用してリモートステートをワークスペース（dev/test/prod）ごとにAzure Storageに保存し、ロックにはBLOBリースを使用します。これにより、単一のパイプラインパターンを維持しつつ、ステートを安全に分離し、一貫したプロモーションを可能にします。
アプリケーション構成と機能フラグをAzure App Configurationに一元化します。パーセンテージフィルターとラベルを持つ機能フラグにより、リングベースのロールアウトが可能になります。構成スナップショットは、各デプロイステージが不変で監査済みのキーセットを利用することを保証します。
シークレットをAzure Key Vaultに保存し、App Configurationから参照します。実行時にマネージドIDで参照を解決することで、再デプロイなしでのキーローテーションが可能になり、アプリケーション構成やパイプラインからシークレットを排除します。
Packerを使用してゴールデンイメージをビルドし、Shared Image Galleryに発行することで、VMワークロードにイミュータブルイメージを採用します。パイプラインは、強化スクリプトとInSpecスキャンを実行し、イメージにタグを付け、合格したバージョンのみをプロモートします。VM Scale Setsはギャラリーイメージを利用してブルー/グリーンおよびローリングアップグレードを行い、ドリフトを排除します。
プライベートサブネットでのパブリックIPの公開を拒否し、Log Analyticsへの診断設定を要求し、バックアップポリシーを自動デプロイするAzure Policyイニシアチブでガードレールを強制します。広範なカバレッジのために管理グループレベルで割り当て、既存のリソースに対して修復タスクを作成して、ポスチャーを迅速に収束させます。
コンプライアンスに違反するイメージや特権付きポッドをブロックする制約を適用して、OPA/GatekeeperでAKSを保護します。ポリシーはGitに保存およびバージョン管理され、CIでconftestによって検証され、GitOps経由で適用されることで、クラスターの状態が常にポリシーと一致することを保証します。
Azure Automation DSCでWindowsサーバーの構成を管理します。ノードはRegister-AzAutomationDscNodeで登録し、ConfigurationMode=ApplyAndAutoCorrectを使用してドリフトを検出および修復します。コンパイルジョブはロールごとにMOFを出力し、コンプライアンスダッシュボードは調査のためにドリフトを表面化させます。
azure_rm動的インベントリとazure.azcollectionモジュールを使用して、AnsibleでLinuxの構成とオーケストレーションを管理します。Azure PipelinesはマネージドIDで認証し、プレイブックをべき等に実行し、サービス間の更新を調整することで、Windows上のDSCを補完します。
イメージと実行中のホストの両方でクロスプラットフォームのcompliance-as-codeにChef InSpecプロファイルを利用し、レポート作成のためにChef Automateにデータを送ります。これにより、監査可能でテスト可能な制御がパイプラインと本番環境にもたらされ、規制要件が継続的に検証されることを保証します。

この組み合わせは、型付けされたモジュール式のIaC（Bicep/Terraform）、イミュータブルなホスト（Packer）、一元化されたアプリ構成（App Configuration/Key Vault）、継続的な構成強制（Azure Automation DSC、Ansible）、および強力なガバナンス（Azure Policy、Gatekeeper）を提供します。これにより、ドリフトが削減され、復旧とロールアウトの時間が短縮され、コンプライアンスが実証可能になります。

← Azure Pipelines による CI · すべてのドメイン · コンテナ化と Kubernetes →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →