Terraform 試験の問題例: 主要ドメインの問題形式（Associate / Pro）

Terraform の試験は、コマンド暗記よりも「状態管理」と「変更の安全性」を理解しているかを見ます。

実務での落とし穴（同時実行、バックエンド設定漏れ、モジュールの破壊的変更、誤った -target 依存切り離し）に直結する設問が多いです。

Terraform ワークフローの基礎と問題パターン

Associate では plan/apply/destroy の役割や、計画が何に基づくか（.tf の宣言、現在の tfstate、実インフラの差分）を正しく説明できることが問われます。Pro ではチーム運用前提の設問（レビュー、並行実行、CI 連携）が増えます。

典型的なひっかけは、plan が副作用を発生させると誤解するケースや、設定を変えずに -refresh-only で差分を確認できることを知らないケースです。

• terraform plan は提案のみ。副作用なし。
• terraform apply は計画の実行。-auto-approve の乱用はリスク。
• -refresh-only は実インフラから状態のみ更新。リソース作成・削除はしない。
• 差分の根拠は「宣言」「状態」「実インフラ」。いずれかがズレると計画が変わる。

plan/apply とリモート状態・ロックの関係

Developer CLI        Remote Backend (S3/Azure/GCS)        Provider API
      |                           |                           |
      | terraform plan            |                           |
      |-------------------------->|  読み取り: tfstate        |
      |                           |-------------------------->|
      |                           |<--------------------------|
      |<--------------------------|  計画に必要な状態取得      |
      |                           |                           |
      | terraform apply           |                           |
      |-------------------------->|  ロック取得 (DynamoDB等)   |
      |                           |=== LOCK ===               |
      |                           |-------------------------->|
      |                           |<--------------------------|
      |<--------------------------|  変更反映後に状態書き込み  |
      |                           |--- UNLOCK --------------- |

最小構成の例（出力で plan の差分を観察）

terraform {
  required_version = ">= 1.0"
}

variable "project_name" {
  type    = string
  default = "demo"
}

locals {
  tag = "app-${var.project_name}"
}

output "tag_example" {
  value = local.tag
  sensitive = false
}

# var.project_name を変更して plan を比較し、apply 前に差分を理解する

State と CLI コマンドの出題傾向

状態は単なるキャッシュではなく、Terraform が作成・管理するオブジェクトの真実の情報源です。手動編集は非推奨で、state サブコマンドで安全に操作します。

Associate では state list/show/mv/rm、import の基本。Pro ではドリフト調整、選択的移行、チーム運用での手順化が問われやすいです。

• state list: 管理下のアドレス一覧を確認
• state show: 単一リソースの属性を確認（機密値の扱いに注意）
• state mv: アドレスの移動。モジュールリファクタ時に使用
• state rm: 管理外化。実リソースは削除されない
• import: 既存リソースを状態に取り込む。設定は生成しない点に注意

CLI 操作の実例

# 管理下のリソース一覧
terraform state list

# 単一リソースの詳細（ID・属性）
terraform state show aws_s3_bucket.logs

# モジュール化に伴うアドレス移行
terraform state mv aws_s3_bucket.logs module.storage.aws_s3_bucket.logs

# 既存 VPC の取り込み（ID は実リソースの識別子）
terraform import aws_vpc.main vpc-0abc1234def567890

# ドリフト確認のみ
terraform plan -refresh-only

状態管理とバックエンド比較（Associate/Pro 共通）

リモートバックエンドは単一の真実の状態とロックを提供し、チーム運用の前提になります。S3 を使う場合は DynamoDB によるロックを忘れがちです。ロックがないと並行 apply で破壊的な競合が起きます。

試験では「どのバックエンドがロックをサポートするか」「暗号化や権限モデルの違い」「設定で落としやすい罠」を選ばせる設問が定番です。

• local は単独利用向け。チーム運用では避ける
• ロック有無、暗号化、認証方式、権限分離を比較して選択
• S3 利用時はバージョニングと SSE、DynamoDB ロックをセットで設計

S3 バックエンド（DynamoDB ロック込み）

terraform {
  backend "s3" {
    bucket         = "tfstate-prod"
    key            = "network/terraform.tfstate"
    region         = "ap-northeast-1"
    dynamodb_table = "tfstate-lock"
    encrypt        = true
  }
}

# 事前に S3 バケット(バージョニング有効) と DynamoDB テーブル(パーティションキー: LockID) を用意

モジュール、変数、出力の設計

Associate ではモジュールの呼び出し・変数/出力の受け渡し、Pro ではバージョン固定、for_each/count、入力検証、汎用化しすぎない設計が問われます。

for_each はキー安定性が重要です。破壊を避けるため、実体にひもづく不変キー（例: 名前）を使います。

• module バージョンを固定（ref または registry の version）
• variable validation で入力の境界を明確化
• output は消費側を意識し最小限の露出に抑える
• count と for_each は相互変換が破壊的になり得る

モジュール呼び出しと入力検証の例

module "vpc" {
  source  = "git::https://example.com/terraform-modules.git//vpc?ref=v1.4.2"
  name    = var.project
  cidr    = var.cidr
  azs     = var.azs
}

variable "project" {
  type = string
  validation {
    condition     = length(var.project) <= 12
    error_message = "project は 12 文字以内にしてください。"
  }
}

variable "cidr" {
  type = string
}

output "vpc_id" {
  value = module.vpc.id
  sensitive = false
}

リソースライフサイクル、依存、プロビジョナ

ライフサイクル制御は破壊的変更の回避に有効ですが、乱用は複雑化を招きます。依存は暗黙的（参照）を優先し、必要時のみ depends_on を使います。

プロビジョナは最終手段です。構成管理はクラウドネイティブ手段（User Data、起動テンプレート等）や外部ツールで代替するのが推奨です。

• prevent_destroy は重要リソースの誤削除を防ぐ
• create_before_destroy は置換時のダウンタイムを低減
• replace_triggered_by で入れ替え条件を明示
• depends_on は循環依存に注意
• プロビジョナは失敗時再実行やドリフトの温床になりやすい

ライフサイクルと依存の例

resource "aws_launch_template" "app" {
  name_prefix   = "app-"
  image_id      = var.ami
  instance_type = var.instance_type

  lifecycle {
    create_before_destroy = true
    prevent_destroy       = false
  }
}

resource "aws_autoscaling_group" "asg" {
  name                = "app-asg"
  desired_capacity    = 3
  max_size            = 5
  min_size            = 3
  launch_template {
    id      = aws_launch_template.app.id
    version = "$Latest"
  }
  depends_on = [aws_launch_template.app]
}

# プロビジョナの代わりに起動時ユーザーデータ等で初期化

ワークスペース、ポリシー、Import の注意点

ワークスペースは同一構成の環境分離（state 分離）であり、完全なセキュリティ境界ではありません。環境ごとにバケットや権限を分ける設計が推奨です。

ポリシー（例: Terraform Cloud の Sentinel、または OPA など）で事前ガードを設定し、危険な変更をレビュー前にブロックします。

import は既存リソースを状態に関連付ける操作です。設定ファイルは自動生成されないため、対応するリソース定義を先に用意しておく必要があります。

• ワークスペースは state の切替。変数やバックエンドの分離戦略が鍵
• ポリシーチェックは plan 時の早期失敗を促す
• import 後は plan で差分ゼロを確認。足りない属性は設定に追記

ワークスペースと import の実例

# 環境用ワークスペース
terraform workspace new staging
terraform workspace select staging

# 既存リソースの取り込み
# 先に対応する resource ブロックを定義しておく
terraform import aws_iam_role.app_role app-role

# Sentinel/OPA は CI/Remote 実行で plan にフックして評価する運用が一般的

問題で確認

よくある質問