Terraform 資格の勉強法: 公式LearnとハンズオンでAssociate/Professionalに通す

Terraformの資格対策は、単に用語を覚えるより、CLIとコードで一連のワークフローを体験する方が圧倒的に早いです。本稿では、HashiCorp公式Learn（https://developer.hashicorp.com/terraform/learn）を主軸に、最短で合格点に届くハンズオン設計を提示します。

バージョンや出題範囲は更新され得るため、細かな仕様は必ず公式ドキュメント（https://developer.hashicorp.com/terraform）と公式認定ページ（https://developer.hashicorp.com/certifications/infrastructure-automation）で最新情報を確認しつつ進めてください。ここでは安定した概念と一般的なベストプラクティスに絞って解説します。

試験ドメインの押さえどころと学習優先度

AssociateはTerraformのワークフロー（init/plan/apply/destroy）、状態管理、基本的なモジュール化、変数・出力の扱い、依存関係解決を中心に問われます。Professionalはこれに加え、複数環境の運用、チーム開発、リファクタリング、リモートバックエンド、ガバナンス、高度なトラブルシュートなどの設計力が求められます。

表の観点で、どのドメインを何で鍛えるかを明確にしてからLearnのユニットとハンズオンを当て込みます。重箱の隅をつつくより、状態と計画の整合性、コードの再利用性、ドリフト検出・取り込みの手順を早めに体験するのが効率的です。

• 前提はCLI操作の正確さ。コマンドの出力を読み、次の一手を決める癖を付ける
• Associateはモジュールの基本形と変数の型・検証、Proはモジュールの分割戦略・再利用境界を深掘り
• 状態はローカルから始め、早めにリモートバックエンドとロックで実務に寄せる
• バージョン差異に注意。挙動が変わりやすい領域は公式Docsで裏取りする

公式Learnの使い方: 進める順序と読み替えのコツ

公式Learnは小さな演習が多く、そのまま順にやると点が線になりにくいことがあります。下記の順序で、最小構成→状態→モジュール→バックエンド→チーム運用の流れに並べ替えると、資格と実務の両方に効きます。

教材はクラウド固有の差異を抽象化して読むのがコツです。AWS・Azure・GCPいずれでも、プロバイダの認証と通信、依存解決、状態の一貫性という核は同じです。

• Day1: Get Started、リソース1つ、variables/outputs
• Day2: 依存関係、dataソース、lifecycleの基本
• Day3: modulesの作成と呼び出し、バージョン固定
• Day4: stateの可視化、terraform stateサブコマンド
• Day5: リモートバックエンド（Terraform CloudやS3）とロック
• Day6: ワークスペースと環境分離、チーム運用の雛形

学習パスの全体像

最初のチェック: CLIとプロバイダの健全性

terraform -version
terraform init -upgrade
terraform providers

最小構成から始めるハンズオン設計

まずは単一のリソースで差分と依存の感覚を掴みます。続いてdataソースで既存情報を参照し、出力で実行結果を確認。最後に小さなモジュールに切り出し、バージョンを固定して再利用を体験します。

クラウドの選択は自由ですが、資格対策では典型リソース（例: AWSではS3、IAMロールなど）を選ぶと出題意図と重なりやすいです。認証情報は環境変数やプロファイルで渡し、コードに直書きしないこと。

• variables.tfで型と検証を定義し、入力エラーを早期に検出
• outputs.tfで重要な識別子を露出し、plan出力と突き合わせる
• module呼び出し時はversionを固定し再現性を担保
• lifecycleは必要最小限。create_before_destroyの副作用に注意

最小例: 単一リソースとモジュール呼び出し

# main.tf
terraform {
  required_version = ">= 1.4"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 5.0"
    }
  }
}

provider "aws" {
  region = var.region
}

module "bucket" {
  source  = "terraform-aws-modules/s3-bucket/aws"
  version = ">= 4.0"

  bucket = var.bucket_name
  acl    = "private"
  tags = {
    managed_by = "terraform"
    env        = var.env
  }
}

# variables.tf
variable "region" { type = string }
variable "env"    { type = string }
variable "bucket_name" {
  type        = string
  description = "S3 bucket name"
}

# outputs.tf
output "bucket_id" {
  value = module.bucket.s3_bucket_id
}

状態とバックエンド: 失敗を先に体験して覚える

tfstateは唯一の真実です。ローカル状態で仕組みを理解したら、早めにリモートバックエンドへ移行してロックと並行実行の挙動を確認しましょう。S3+DynamoDBやTerraform Cloudのリモート状態はいずれもよく出る話題です。

バックエンド移行は安全に行います。terraform init -migrate-stateで既存の状態を移行し、差分が出ないことをplanで確認。ワークスペースを使う場合は命名規約と環境変数のスコープを設計してから増やします。

• 状態の破損時は編集せず、まずは原因切り分け。ロック解除は最後の手段
• terraform stateコマンドで参照・mv・rmの意味を体で覚える
• バックエンドの認証は適用時点で有効であることをCIで検証
• workspaceは増やしすぎない。環境分離は命名と変数管理で担保

S3バックエンド例と基本オペレーション

# backend.tf
terraform {
  backend "s3" {
    bucket         = "my-tfstate-bucket"
    key            = "infra/dev/terraform.tfstate"
    region         = "ap-northeast-1"
    dynamodb_table = "my-tf-lock"
    encrypt        = true
  }
}

# 初期化と移行
terraform init -migrate-state

# ワークスペース操作
terraform workspace list
terraform workspace new dev
terraform workspace select dev

# 状態の参照
terraform state list
terraform state show aws_s3_bucket.this

ドリフトと取り込み(import): 既存資産をコード化する力

実務では既存リソースの取り込みとドリフト解消が頻出です。planで差分を把握し、必要に応じてimportでTerraform管理下に移します。取り込み後はコードと実体の差を潰し、不要ならterraform state rm、構成を合わせるならコード修正で整合させます。

従来のterraform importコマンドに加え、Terraformのバージョンによってはimportブロックが使えます。環境のバージョン方針に合わせ、どちらを採るかを決めてください。いずれの場合も、取り込み対象のアドレスとIDは正確に。

• planの差分は追加・変更・削除のどれか。削除が出てよいかの判断基準を事前に決める
• importは状態だけ作る。コードは後追いで一致させる必要がある
• IDの粒度はプロバイダごとに異なるため公式Docsで確認
• 大規模取り込みはスクリプト化して手順を標準化

importの2つのやり方（バージョン方針に合わせて選択）

# 1) 従来のCLI import（広く使える）
terraform import aws_s3_bucket.example my-existing-bucket

# 2) importブロック（対応バージョンのみ）
# import.tf
# import {
#   to = aws_s3_bucket.example
#   id = "my-existing-bucket"
# }
# terraform plan

模擬試験とレビュー: 失点源を潰すチェックリスト

模擬問題は用語の確認に有効ですが、最後は自分のリポジトリで再現できるかが勝負です。エラーや警告の原因を言語化し、再発防止の手をコードに落とせるかを確認しましょう。

Proを目指す場合は、複数環境/複数プロバイダの構成管理、バージョンピン留め、CIでのplan差分レビュー、アクセス制御とロール分離までを一連で通せると安定します。

• plan出力のうち、なぜその差分になったか説明できるか
• 状態移行・バックエンド変更時に無停止で進める具体手順は言えるか
• モジュールの破壊的変更をどう安全に適用するか
• providerの認証失敗やレート制限時のリトライ戦略を説明できるか

planの機械可読出力でレビューを厳密化

# JSON化して差分をCIで検査
terraform plan -out=tfplan
terraform show -json tfplan > plan.json
# plan.jsonをCIでlint/ポリシー検査に回す（例: 変更許可タグの有無など）

問題で確認

よくある質問