Terraform Authoring & Ops Pro: 上位資格の範囲と対策

HashiCorp公式の公開資格としてはAssociateが中心だが、本稿では上位レベル（Pro相当）を想定し、実務の難所を軸に学習観点をまとめる。

試験対策だけでなく、Terraform Cloud/EnterpriseやS3+DynamoDBバックエンド運用など、現場の標準パターンで説明する。

上位レベルで問われるTerraformのコア領域

上位レベルでは、HCLを書けることに加え、モジュールの公開品質、ステート運用（ロック・分離・移行）、変更の安全性（create_before_destroy、replace_triggered_by、moved）、ポリシー適用、そしてCIによる自動化と監査可能性が問われる。Terraform Open SourceとTerraform Cloud/Enterprise（TFC/E）の差も把握しておきたい。

出題イメージとしては、単一ワークスペースの単純構成ではなく、複数環境・複数ワークスペース・リモートステート・チーム権限・タグや規約の強制・モジュールバージョニング・プロバイダ更新など、スケールと変更を前提にした意思決定が多い。

• モジュール設計とリリース管理（変数/出力、バリデーション、pre/post条件、セマンティックバージョニング）
• バックエンド選定とステート運用（ロック、分離、moved/state mv/import、機微情報の扱い）
• 差分制御（lifecycle、ignore_changes、置換トリガ、ゼロダウンタイム戦略）
• ガバナンス（Sentinel/OPA、ワークスペース権限、変数セット、プロバイダ制約）
• CI/テスト/監査（validate/planのJSON、静的解析、承認フロー、アーティファクト保持）

Terraform上位レベルの責務マップ

最低限のルート構成スケルトン（バージョン/プロバイダ制約）

terraform {
  required_version = ">= 1.4, < 2.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = var.region
}

module "network" {
  source  = "appcorp/network/vpc"
  version = "~> 2.4"
  cidr_block = var.vpc_cidr
}

モジュール設計の実務パターン

上位レベルでは、モジュールは「使える」だけでなく「安心して更新できる」ことが重要。変数のバリデーション、pre/post条件、デフォルトの整備、命名と出力の後方互換、明確なバージョニング規約が要点となる。破壊的変更はメジャー更新とし、movedでのアドレス移行を併用して影響を最小化する。

README、サンプル、バージョン互換表を揃え、registryに公開する場合は使用例を実行可能に保つ。内部向けでも、CHANGELOGとアップグレードガイドを必ず用意する。

• 入力の境界を明確化（nullable、型、validation）
• precondition/postconditionで前提と成果物の健全性を機械検証
• 出力は構造を安易に変えない。新フィールドは追加、既存は非推奨化を経て削除
• movedでアドレス変更を宣言的に移行。バージョンに合わせて段階適用
• デフォルトタグや共通ラベルはlocalsで一元化し、重複を避ける

条件・検証を備えたモジュール断片

variable "subnet_cidrs" {
  type = list(string)
  validation {
    condition     = length(var.subnet_cidrs) >= 2
    error_message = "少なくとも2つのサブネットCIDRが必要です。"
  }
}

locals {
  default_tags = merge(var.default_tags, {
    managed-by = "terraform"
    module     = "appcorp/network"
  })
}

resource "aws_subnet" "this" {
  for_each          = toset(var.subnet_cidrs)
  vpc_id            = var.vpc_id
  cidr_block        = each.value
  tags              = local.default_tags
  lifecycle {
    precondition {
      condition     = can(cidrnetmask(each.value))
      error_message = "CIDRの形式が不正です。"
    }
  }
}

moved {
  from = aws_subnet.old
  to   = aws_subnet.this
}

output "subnet_ids" {
  description = "作成されたサブネットのID一覧"
  value       = values(aws_subnet.this)[*].id
}

ステート運用とバックエンド設計

ステートは真実の源泉。上位レベルでは、リモートバックエンドでのロック、権限、キー戦略（環境・リージョン・システム単位の分離）を設計し、障害時の復旧手順を標準化する。S3+DynamoDBはオンプレ/マルチアカウントでも定番、Terraform Cloud/Enterpriseはロックと実行管理、ポリシー、監査が統合される。

移行と保守では、terraform state mv/import、モジュールのmovedを使い分ける。drift対応は安易な-state rmや手動修復に走らず、原因を特定し、必要ならignore_changesやプロバイダの力学（差分計算）を理解して調整する。

• キー設計は workspace/env/region/system の組合せで一意に
• S3は必ずバージョニングとMFA削除を有効化、DynamoDBロックを併用
• TFC/EではRun Queueとロック、計画の承認フローで競合を抑止
• バックアップはストレージのバージョニング任せにせず、計画的にexport/スナップショットを取得
• 機微情報はstateに残る可能性を前提に、出力・属性の扱いを最小化

代表的バックエンド設定と運用コマンド

# S3 + DynamoDB ロック
terraform {
  backend "s3" {
    bucket         = "tfstate-prod"
    key            = "network/prod/ap-northeast-1/terraform.tfstate"
    region         = "ap-northeast-1"
    dynamodb_table = "tfstate-lock"
    encrypt        = true
  }
}

# Terraform Cloud (remote) バックエンド
terraform {
  cloud {
    organization = "appcorp"
    workspaces {
      name = "network-prod"
    }
  }
}

# 運用スニペット
# 既存リソースを宣言と紐付け（import）
terraform import aws_subnet.this["10.0.1.0/24"] subnet-abc123

# アドレス移行（state mv）
terraform state mv aws_subnet.old["10.0.1.0/24"] aws_subnet.this["10.0.1.0/24"]

# 差分のJSON化（監査用）
terraform show -json plan.out > plan.json

差分制御とゼロダウンタイムの基本戦略

不可避な置換が発生する変更でも、停止やリスクを抑える工夫ができる。lifecycleのcreate_before_destroy、ignore_changesで外部制御値の差分を抑制、replace_triggered_byで意図したタイミングでの置換を誘発する。プロバイダ依存のブルーグリーンやローリング更新は、モジュールの抽象で包み隠蔽するのが安全だ。

targetはデバッグや段階リリースの補助に留め、恒常運用の前提にしない。多段変更は、モジュールのバージョンを刻み、movedと出力互換を活用してリスクを分割する。

• create_before_destroyで置換順序を制御（依存関係に注意）
• ignore_changesで外部コントロール項目（手動タグ、一時的属性）を無視
• replace_triggered_byで安全側の再作成を明示
• 複数段階の計画を小さく刻み、各段階でplanの証跡を残す

置換順序と差分抑制のHCL例

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

  lifecycle {
    create_before_destroy = true
    ignore_changes = [
      user_data,               # 外部で都度差し替える場合にドリフト抑制
      tags["temporary"]
    ]
    replace_triggered_by = [
      var.force_recreate_token # 任意のトークンで安全側置換
    ]
  }

  timeouts {
    create = "20m"
    delete = "20m"
  }
}

ポリシーとガバナンス（Sentinel/OPAと権限設計）

Terraform Cloud/Enterpriseでは、Sentinelで計画に対する組織ポリシーを強制できる。タグ必須、コスト上限制約、許可されたリージョンやプロバイダのみ許可などをコード化し、ワークスペースやポリシーセットで適用範囲を制御する。Open Source環境では、OPA/RegoとConftestをCIに組み込み、同様の検査を行う。

権限は最小権限を原則に、VCS連携時はトリガ権限とState閲覧権限を慎重に分離する。変数セットやSensitive変数を用い、資格情報をコード外で注入し、監査ログで操作の追跡性を確保する。

• プロバイダ/バージョンの許可リスト化（required_providersの強制）
• タグ/ラベルの標準化をポリシーで必須化
• Sensitive変数と環境ごとの変数セットを使い回し、誤配置を防ぐ
• ポリシーは段階適用（advisory → soft-mandatory → hard-mandatory）で浸透させる

Sentinelの簡易ポリシー例（タグ必須）

import "tfplan/v2" as tfplan

main = rule {
  all tfplan.resources as r {
    r.mode is "managed" implies has_required_tags(r)
  }
}

has_required_tags = func(r) {
  all r.applied.resources as inst {
    inst.change.after.tags is not null and
    inst.change.after.tags["owner"] is not null and
    inst.change.after.tags["env"] in ["dev", "stg", "prod"]
  }
}

CI/テスト/トラブルシュートの実装要点

CIではinit/validate/planを分離し、プランはバイナリアーティファクトとして保存、レビュー後にapplyにのみ使用する。静的解析（tflintなど）やポリシー検査（OPA/Checkov）を早期に回し、重いplanは変更が確定した段階で実行する。VCSの保護ルールと組み合わせ、再現性と証跡を担保する。

障害調査は、plan/show -jsonによる差分の機械読解、TF_LOGやproviderのデバッグフラグ、並列度やAPIレート制限の調整から着手する。インポートは、近年のimport blockが利用可能な環境ならコード側で宣言し、計画に組み込んで手順を見える化する。

• plan.outを使い回し、planとapplyの差し替えを防止
• JSON出力を保存し、承認と監査に活用
• 静的解析とポリシー検査はplan前に走らせる
• 並列度（-parallelism）やリトライでAPIスロットリングに配慮

GitHub Actionsでの基本パイプライン例

name: terraform-ci
on:
  pull_request:
    paths: ["infra/**"]

jobs:
  plan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: 1.6.6
      - run: terraform -chdir=infra init -input=false
      - run: terraform -chdir=infra validate
      - run: terraform -chdir=infra plan -input=false -out=plan.out
      - run: terraform -chdir=infra show -json plan.out > plan.json
      - uses: actions/upload-artifact@v4
        with:
          name: tf-plan
          path: infra/plan.out
  apply:
    if: github.ref == 'refs/heads/main' && github.event_name == 'workflow_dispatch'
    needs: plan
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - uses: actions/download-artifact@v4
        with:
          name: tf-plan
          path: infra
      - run: terraform -chdir=infra init -input=false
      - run: terraform -chdir=infra apply -input=false "plan.out"

問題で確認

よくある質問