Terraform 関連資格の全体像：Associate と Authoring / Operations Professional の位置付け

Terraform の資格は、基礎の Associate と、実務の深さで分かれる Professional（Authoring / Operations）の三層で理解すると学習が進みます。Associate は概念と基本操作、Authoring はモジュール設計とコード品質、Operations はチーム運用とプラットフォーム活用に比重があります。

本稿は、公式ドキュメントに準拠した安定概念を軸に、試験対策と現場適用を両立する観点で構成しています。バージョン依存の詳細は避け、プロバイダ・状態管理・HCP Terraform（Terraform Cloud/Enterprise）など不変の基礎に焦点を当てます。

全体像：トラックと役割の切り分け

Terraform 認定は、インフラ自動化の理解度と役割に応じて段階化されています。Associate は単体の開発者が安全に IaC を扱うための基礎力を評価します。Authoring Professional は再利用可能なモジュールの設計・表現力・品質管理を評価し、Operations Professional はチーム/組織スケールでの運用、状態と権限、ポリシー適用、実行基盤の選定・運用を評価します。

試験学習の観点では、まず CLI ワークフローと状態管理の基礎を固め、その後にコード表現の拡張（変数・型・動的構成・モジュール）、最後に HCP Terraform のワークスペース、ポリシーと RBAC、リモート実行とパイプラインに進むのが無理がありません。

• Associate：概念、CLI ワークフロー、基本的な状態管理、モジュール利用の基礎
• Authoring Pro：モジュール設計、入力/出力設計、バージョニングと互換性、動的構成・式の活用
• Operations Pro：バックエンド・ロック・並行実行、HCP Terraform のワークスペース/RBAC/ポリシー、ランのオーケストレーション

資格トラックの位置付け（概念図）

Associate
   |
   v
Authoring Pro  <-->  Operations Pro
   (書く力)          (回す力)
        \________ 組織的な IaC 成熟度 ________/

CLI 基本ワークフロー（Associate の土台）

# ディレクトリ初期化とプラグイン解決
terraform init

# 変更のプレビュー
terraform plan -out=plan.out

# 適用（計画を固定して適用）
terraform apply plan.out

# 破棄（検証用環境など）
terraform destroy

Associate の出題範囲と実務への接続

Associate は Terraform のコア概念と安全な日々の操作に焦点があります。provider の仕組み、resource/data の違い、変数と出力、state の役割、CLI ワークフロー、モジュールの基本、そして（必要に応じて）HCP Terraform のワークスペースや実行の基礎を問われます。

実務では、計画の解釈、意図しない破壊の回避、state の場所・ロック・バックアップ方針、変数の取り扱い（環境変数や tfvars）などが安全運用の鍵になります。

• plan 出力からの差分読解と副作用の把握
• state の基本操作（参照・バックアップ）と配置選択の理由説明
• モジュールの呼び出しと入力/出力の受け渡し
• HCP Terraform を使う場合のワークスペース基本概念（VCS 連携や手動実行の理解）

基本ワークフロー（概念）

[コード] -> terraform init -> terraform plan -> レビュー -> terraform apply
                                   |
                                 state

最小構成の例（理解しやすい main.tf）

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
    }
  }
}

provider "aws" {
  region = var.region
}

variable "region" {
  type    = string
  default = "us-east-1"
}

resource "aws_s3_bucket" "example" {
  bucket = "nl-associate-example-${random_id.suffix.hex}"
}

resource "random_id" "suffix" {
  byte_length = 2
}

output "bucket_name" {
  value = aws_s3_bucket.example.id
}

Authoring Professional：再利用可能なコードを書く力

Authoring Professional は、モジュール設計とコード品質が中心です。入力の型・検証、出力の安定契約、バージョン互換性、for_each や dynamic ブロック、条件式や関数での表現力が問われます。Registry での公開・バージョニング、破壊的変更を避ける設計判断も評価対象になりやすい領域です。

実務では、モジュールの境界設定、デフォルト値と必須入力のバランス、命名規約、ドキュメント化、例示コードの提供、セマンティックバージョニングによる互換性管理が品質と展開速度を左右します。

• 入力の型付けと validation で契約を明確化
• locals と式を使い、副作用の少ない宣言的表現に寄せる
• for_each / dynamic で冪等かつ読みやすい展開を実現
• SemVer と CHANGELOG で互換性ポリシーを維持

モジュールの公開と利用（概念）

Authoring Dev  -->  Private/公開 Registry  -->  Consumer
     |                    | versions: 1.2.3          |
     |-- README/例示 ---->| immutability              |-- version constraints

モジュール設計スニペット（型・検証・動的ブロック）

# modules/vpc/variables.tf
variable "cidr" {
  type        = string
  description = "VPC CIDR"
  validation {
    condition     = can(cidrhost(var.cidr, 0))
    error_message = "cidr には有効な CIDR を指定してください。"
  }
}

variable "public_subnets" {
  type = map(object({
    cidr = string
    az   = string
  }))
}

# modules/vpc/main.tf
resource "aws_vpc" "this" {
  cidr_block = var.cidr
  tags       = { Name = "core-vpc" }
}

resource "aws_subnet" "public" {
  for_each          = var.public_subnets
  vpc_id            = aws_vpc.this.id
  cidr_block        = each.value.cidr
  availability_zone = each.value.az
  map_public_ip_on_launch = true
  tags = {
    Name = "public-${each.key}"
  }
}

# root/main.tf（利用側）
module "vpc" {
  source = "appcorp/vpc/aws"
  version = "~> 1.2"
  cidr    = "10.0.0.0/16"
  public_subnets = {
    a = { cidr = "10.0.1.0/24", az = "us-east-1a" }
    b = { cidr = "10.0.2.0/24", az = "us-east-1b" }
  }
}

output "vpc_id" { value = module.vpc.vpc_id }

Operations Professional：運用・プラットフォームの深掘り

Operations Professional は、状態管理、リモートバックエンド、ロックと並行制御、HCP Terraform（Terraform Cloud/Enterprise）のワークスペース、RBAC、ポリシー（Sentinel）やランタスク、VCS 連携と実行キュー制御など、チーム運用を安全に回す力を評価します。

重要なのは、意図せぬ並行適用や手作業変更の混入を避ける統制です。バックエンドの選定、ワークスペース戦略、実行権限の分離、ポリシーセットの適用、変数/機密の保護、実行ログと監査の活用が試験と実務双方の肝になります。

• remote backend とロック（例：S3 + DynamoDB、HCP Terraform 内蔵ロック）
• ワークスペースと VCS 連携、キューと承認フローの理解
• Sentinel ポリシーの適用レベル（advisory/soft-mandatory/hard-mandatory）
• state 操作のガバナンス（mv/rm/import の安全運用）

運用パイプライン（HCP Terraform 利用イメージ）

Dev PR -> VCS webhook -> HCP Terraform workspace
                           |-> plan -> policy check -> apply
                                   |            ^
                                   v            |
                               remote state  Sentinel

バックエンドとクラウド統合の設定例（安定機能）

# 例1: S3 バックエンド（DynamoDB ロック）
terraform {
  backend "s3" {
    bucket         = "tfstate-bucket"
    key            = "prod/network/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "tfstate-lock"
    encrypt        = true
  }
}

# 例2: Terraform Cloud/HCP Terraform の cloud ブロック
terraform {
  cloud {
    organization = "acme"
    workspaces {
      name = "prod-network"
    }
  }
}

# 代表的な state メンテナンス（要計画・要バックアップ）
# terraform state list
# terraform state mv aws_subnet.public["a"] aws_subnet.public["az-a"]
# terraform state rm aws_eip.legacy

学習計画：Associate から Pro へ段階的に伸ばす

まずは単一プロジェクトで state とワークフローに慣れ、次にモジュール化とバージョニング、最後に HCP Terraform とポリシーでチーム運用に拡張する順番が効率的です。各段階で実務タスクを用意し、プランのレビューやロールバック可能性を必ず検証します。

模擬環境は小さく、短時間で作成・破棄できるものに限定します。計測可能なゴール（lint/validate/plan の自動化、モジュールのバージョン更新演習、ワークスペースの RBAC 設定）を置くと試験と実務の両輪が回ります。

• 週次で小さな実験を回し、毎回 README に学びを追記
• プランの差分スクリーンショットや plan.out を必ず保存
• モジュール更新は SemVer ポリシーと合わせて PR テンプレート化

学習の段階化

Foundation --> Authoring --> Operations
   state/CLI     modules       TFC/TFE + policy/RBAC

CI で最低限の品質ゲートを作る例（言語非依存のシェル）

# フォーマットと構文検証
terraform fmt -check
terraform validate

# 計画作成とアーティファクト化
terraform plan -out=plan.out
terraform show -no-color plan.out > plan.txt

# 失敗時に PR をブロックする（CI の失敗で評価）
# exit 1 を返すだけで十分なガードになる

よくある落とし穴と対策（試験と現場での共通点）

落とし穴の多くは、リソースアドレスの変更、状態の手動編集、バージョン不一致、ワークスペース・変数の誤用に起因します。試験では意図しない再作成や破壊的変更を回避する設計・手順が問われやすく、現場でも同様です。

特に Operations 領域では、並行実行、権限の過不足、ポリシーの適用レベルの誤設定が事故に直結します。実行前のレビューと実行後の監査ログ確認をルーチン化しましょう。

• for_each のキー変更でリソースが再作成されるケースを理解する
• state rm を安易に使わない（ドリフトの原因になり得る）
• provider と module のバージョンを範囲指定で固定
• ポリシー違反時の動作（advisory/mandatory）をチームで合意

再現性を壊す要因の関係

Versions -----> Plan reproducibility <----- State location
    |                    ^                          |
    v                    |                          v
 Module/API changes   Drift risk               Concurrency

S3 バックエンドと Sentinel ポリシーの最小例

# backend（再掲：状態の一元化）
terraform {
  backend "s3" {
    bucket         = "tfstate-bucket"
    key            = "dev/app/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "tfstate-lock"
    encrypt        = true
  }
}

# Sentinel（Terraform Cloud/Enterprise 用の例、適用レベルは運用で設定）
# ファイル: restrict-instance-type.sentinel
import "tfplan/v2" as tfplan

allowed = ["t3.micro", "t3.small", "t3.medium"]

main = rule {
  all tfplan.resources.aws_instance as r {
    all r.applied as inst { inst.instance_type in allowed }
  }
}

問題で確認

よくある質問