最終確認: 2026年5月
AZ-900 試験の対象となる AWS サービスを、プレーンな Terraform を使用して構築します。1 ブロックずつ、それぞれ試験ドメインに関連付けられています。同じコードが OpenTofu でも動作します。
このラボの終了までに、プレーンなTerraformを使用して、最小限で現実的な最初のAzureワークロードをプロビジョニングします。具体的には、リソースグループ、安全なデフォルト設定のストレージアカウント、小さなLinux VM、そして請求が発生する前にメールで通知するコスト管理予算アラートです。各リソースはAZ-900試験の柱のいずれかに対応しています。
すべてのリソースはプレーンなTerraformです。変数、モジュール、リモートステートはありません。スニペットを単一の main.tf にドロップし、一度 terraform init を実行してから、terraform apply をステップバイステップで実行します。
>= 1.5 または OpenTofu >= 1.6。az login を一度実行すると、Terraformの azurerm プロバイダーがアクティブなサブスクリプションを自動的に検出します。このラボ内のすべてのリソースは、新しいサブスクリプション向けのAzureの無料利用枠に収まります(最初の30日間で200ドルのクレジットに加え、常時無料の範囲内):
無料利用枠外でVMを24時間年中無休で稼働させると、月額約5ドルかかります。ラボが完了したら破棄してください。
すべてのAzure Terraformスタックは同じ方法で開始します。azurerm プロバイダーを固定し(現在の安定版である ~> 4.0 を使用)、features ブロックを宣言します。空の features {} ブロックは必須であり、これがないと azurerm は初期化されません。これはTerraform作成者レベルで最もテストされているAZ-900の「プロビジョニング」の慣例です。
random_id リソースは、グローバルに一意なストレージアカウント名を生成するための標準パターンです。Azureストレージアカウント名は、3~24文字の小文字の英数字で、すべてのAzureサブスクリプション全体でグローバルに一意である必要があります。random_id は名前に4桁の16進数を追加して衝突を回避します。
terraform {
required_version = ">= 1.5"
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "~> 4.0"
}
random = {
source = "hashicorp/random"
version = "~> 3.6"
}
}
}
provider "azurerm" {
features {}
}
resource "random_id" "suffix" {
byte_length = 2
}
locals {
tags = {
Project = "certlabpro-az-900"
ManagedBy = "terraform"
}
}すべてのAzureリソースはリソースグループに属します。これはAzureの普遍的な組織コンテナです。リソースグループは無料で、リージョンに関連付けられており(リソースグループ自体はメタデータのみですが、その内容はデフォルトでそのリージョンにスコープされます)、一括管理の単位です。リソースグループを削除すると、その中のすべてが削除されます。
AZ-900の「クラウドの概念」および「Azure ID、ガバナンス、プライバシー、コンプライアンス」のドメインは、この概念を強く強調しています。リソースグループは、RBACロールの割り当て、Azureポリシー、コスト追跡のための最小スコープ単位です。すべてのリソースグループにタグを付けましょう。
resource "azurerm_resource_group" "main" {
name = "certlabpro-az-900-rg"
location = "eastus"
tags = local.tags
}Azure Storageは、すべてのAZ-900ワークロードが使用する基盤となるデータサービスです。ここでは、標準ティアのLRS(ローカル冗長ストレージ)アカウントを作成します。これは最も安価なレプリケーションオプションであり、非プロダクションラボワークロードにおけるAZ-900で想定されるデフォルトです。パブリックネットワークアクセスは無効化され、HTTPSのみが強制され、最小TLSバージョンは1.2に設定されています(AZ-900の「セキュリティ」ドメインでは、これら3つが基本的な衛生デフォルトとして明示的にテストされます)。
account_kind = "StorageV2" は現在の汎用v2アカウントです。AZ-900では、これを BlobStorage(以前のBLOB専用)や FileStorage(プレミアムファイル)と区別するよう求められることがあります。「汎用」に関する質問には、StorageV2 が正しい答えです。
resource "azurerm_storage_account" "main" {
name = "certlabpro${random_id.suffix.hex}"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
account_tier = "Standard"
account_replication_type = "LRS"
account_kind = "StorageV2"
https_traffic_only_enabled = true
min_tls_version = "TLS1_2"
public_network_access_enabled = false
allow_nested_items_to_be_public = false
tags = local.tags
}AZ-900では、「Azureの価格、SLA、およびライフサイクル」というドメイン全体が課金概念に充てられています。この分野で最もテストされる実用的な成果物の1つは、予算アラートです。これは、実際の費用または予測費用がしきい値を超えたときにメールで通知するコスト管理のメカニズムです。
予算はステップ2で作成したリソースグループにスコープされ、このラボ内のすべてのもの(そしてこのラボのみ)を追跡します。通知は予算の80%で発生します。「なぜ100%ではなく80%なのか?」というAZ-900の繰り返し質問パターンがありますが、それは80%であればまだ対応する時間があるのに対し、100%ではすでに費用が発生しているためです。
terraform apply を実行する前に、you@example.com を実際のメールアドレスに置き換えてください。
resource "azurerm_consumption_budget_resource_group" "main" {
name = "certlabpro-az-900-budget"
resource_group_id = azurerm_resource_group.main.id
amount = 10
time_grain = "Monthly"
time_period {
start_date = "2026-06-01T00:00:00Z"
}
notification {
enabled = true
threshold = 80
operator = "GreaterThan"
threshold_type = "Actual"
contact_emails = ["you@example.com"]
}
}標準の terraform destroy は、このラボ内のすべてを破棄します。Azure固有の注意点として、リソースグループを削除すると、Terraformがそれらを認識していなくても、Azureはその内部のすべてのリソースを副作用として削除します。これはAZ-900でテストされるクリーンアップの基本です。リソースグループ内に何があるか分からなくなった場合、リソースグループを削除するとサブツリー全体が消去されます。共有サブスクリプションでは慎重に使用してください。
新しいサブスクリプションでは、ストレージアカウントはデフォルトで14日間の論理削除保持期間を持ちます。この期間中、名前空間は予約されたままになります。すぐにラボを再実行すると、名前の衝突が発生する可能性があります。random_id サフィックスは通常これを回避しますが、保証されません。
AZ-900は広範なサービス表面をカバーしています。これには、Azure Virtual Machines(この最小限のラボでは概念的に触れるだけで実際にVMはデプロイしません)、App Service、Azure Functions、AKS、Azure SQL、Cosmos DB、Azure AD/Entra ID、Azure Policy、Azure Blueprints、ARMテンプレート、Bicep、料金計算ツール、TCO計算ツール、Azure Advisor、Service Healthなど、他にも多数含まれます。
私たちは最小限で現実的な最初のワークロードにこだわります。なぜなら、この試験はサービスごとの詳細なプロビジョニングではなく、広範な概念的流暢さをテストするからです。上記で触れた4つの柱—リソースグループ(ガバナンス)、ストレージアカウント(サービス + セキュリティデフォルト)、コスト管理(価格設定)、そして暗示的なコンピューティングターゲット—は、他のすべてのAZ-900の概念が基づく基盤です。
サービスごとのカバー範囲については、この認定ページにある閲覧およびEditorialセクションをご覧ください。これらはAZ-900の範囲内のすべての名前付きサービスを参照しています。