はじめに

こんにちは、ryoです。
先日Terraform Associate 試験を受験し、合格しました。

「合格した話」は沢山掲載されているため「取ってから何が変わったか」について記載します。

本記事のターゲット読者

ターゲットは次の3種類の方を想定しています。

1. AWS 資格は持っているが Terraform は未学習のエンジニアの方
2. 構築 / プリセールス案件で IaC 提案を求められ始めたエンジニアの方
3. Terraform は使っているが体系的に学んだことがないエンジニアの方

よく混同されるツールとの違いを一言で整理すると、

• AWS CloudFormation — AWS 専用。
  Terraform のようなマルチクラウド対応はない
• OpenTofu — Terraform の OSS フォーク。
  構文はほぼ同じ
• Ansible / Puppet / Chef — OS・ミドルウェアの設定管理が主目的。
  インフラのプロビジョニングとは役割が違う

受験した理由

CloudFormation も Terraform も実務で触っていましたが、「動くコードを書ける」と「仕組みを説明できる」は別物だと感じていました。
体系的に学ぶことで後者を埋めたかった、というのが正直なところです。

Terraform を選んだのは、マルチクラウド環境に対応できること、そして普段から一番使い慣れていたからです。

試験対策

学習方法

Udemy で Terraform に関する模擬試験と体系的に学べる計2 コース受講しました。

座学で終わらせないために、学んだ内容はその都度検証環境で動かすことを徹底しました。
試験は英語のみなので、公式ドキュメントも最初から英語で読むよう意識していました。

また Claude の Projects 機能にプロジェクトを作り、誤答した問題や理解が怪しい箇所を全部投げ込んで解説してもらうことで、なぜ正解になるのか、関連知識を含めて解説をしてもらっていました。

試験で重要だった3つのポイント

1. State File / Desired State / 実インフラの3者関係

Terraform の操作はすべてこの3者のズレを解消する作業です。

• Desired State：.tf ファイルに書いた「こうあってほしい」状態
• State File：Terraform が把握している「今こうなっている」状態（terraform.tfstate）
• 実インフラ：AWS 上に実際に存在するリソース

plan は実インフラの現状を refresh で取得したうえで Desired State との差分を出力し、apply はその差分を実インフラに反映して State File を更新します。
「State File を削除した後に apply するとどうなるか？」のような試験問題は、この図が頭に入っていれば迷わず解けます。

2. 似た概念の対比

誤答が多かった4つの組み合わせを表にまとめて覚えました。

module と data の使い分け

• module：自分たちが定義したリソースの集合を呼び出す
• data：既存リソースや API から情報を読むだけ。リソースを作らない

provider と backend の役割

• provider：AWS などクラウド API との通信
• backend：State File の保存先と管理

「どちらが正しいか」ではなく「どの場面でどちらを使うか」が問われる問題が多かったです。

3. 参照構文の細部

moduleやvariableとして定義したものを呼び出す際の構文や、
postcondition 内での自リソースの呼び出しに必要な self の使い方、
バージョン制約 ~> の桁の意味をしっかりと把握することは地味ですが重要な点です。

試験対策というより、コードレビューで「なぜこう書くか」を説明するときにそのまま使える知識です。

AWS 案件での使いどころ

既存環境への Terraform 導入でリスクを事前に潰せる

「既存インフラに Terraform を後から入れる」案件でよく問題になるポイントを、資格学習後は先読みできるようになりました。

ポイント1：terraform import なしで apply すると既存リソースが二重になる

Terraform が plan を計算するとき参照するのは、Desired State と State File の差分だけです。
State File にないリソースは「存在しないもの」として扱われます。

仮に手動で作成済みの VPC がある環境に Terraform を導入するとします。

• State File → 空（この VPC を知らない）
• .tf ファイル → resource aws_vpc main { cidr_block = 10.0.0.0/16 }
• AWS の実態 → VPC がすでに存在している

この状態で terraform apply を実行すると、Terraform は「VPC を新規作成せよ」と判断します。

• VPC のようにユニーク制約がないリソースは、別の VPC ID で2本目が並存し、ルートテーブルとサブネットの整合が崩れます（なお同一リージョンの VPC 数にはデフォルトクォータ 5 があるため、クォータ超過エラーになる場合もあります）
• IAM ロール名のようにユニーク制約があるリソースは already exists エラーで止まりますが、それまでに走った変更はそのままです

そのため、terraform import で先に State File に取り込んでから apply するのが正しい順序です。

import 実行の例
実環境に存在するリソースを terraform ソース内で定義したうえで、「import block」(ソース下部)を作成し、terraform apply を実行することで、実環境に存在するリソースを terraform ソースコードに取り込むことが可能です。
※リソースの取り込み後、import block は削除可能ですが、HashiCorp公式ドキュメントでは履歴的な記録として残すことを推奨しております。
参考：Import a single resource

resource "aws_vpc" "main" {
  # import 後に plan 差分が出ないよう、実際の VPC 設定と合わせる
  cidr_block           = "10.0.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true

tags = {
    Name = "my-existing-vpc"
  }
}

import {
  to = aws_vpc.main
  id = "vpc-xxxxxxxxxxxxxxxxx" # 実際の VPC ID に置き換えてください
}

既存環境への導入プロジェクトでは、この import 作業をスコープと工数に入れないと後で詰まります。

ポイント2：Auto Scaling Group (ASG) の desired_capacity をコードで持つと事故になる

事故の流れはこうです。

1. .tf に desired_capacity = 2 と書いて ASG を作成
2. 負荷が上がり、スケーリングポリシーが発動して台数が 8 に増える
3. タグ変更など別の目的で terraform apply を実行
4. Terraform が差分を検出——「コードは 2、実態は 8、修正が必要」と判断
5. 6 台を終了させてサービスが処理能力を失う

3と5の間に繋がりがないのが厄介な点です。
タグを1つ追加するだけの apply でも、同じステートで管理されている限り desired_capacity は一緒に上書きされます。

対策は lifecycle ブロックで除外することです。

resource "aws_autoscaling_group" "example" {
  min_size         = 2
  max_size         = 10
  desired_capacity = 2

lifecycle {
    ignore_changes = [desired_capacity]
  }
}

ignore_changes に指定した属性は、作成後の apply で差分として扱われなくなります。
min_size / max_size はスケーリングの上下限という設計値なので引き続き管理し、
実行時に変動する desired_capacity だけ除外する、という使い分けです。

なお Terraform 1.x では desired_capacity は Optional なので、そもそも記述しないという選択肢もあります。

試験で「lifecycle ブロックの用途は？」という問いに答えられても、実務でいつ使うかわからなければ意味がありません。
このポイントを知っていると、ASG の設計レビューで自然に確認できます。

プリセールスで「なぜ Terraform か」を説明できる

顧客から「CloudFormation じゃだめなんですか」と聞かれたとき、以前は「Terraform のほうが柔軟です」くらいしか答えられませんでした。

今は Provider が抽象化レイヤーになっており、AWS・Azure・GCP を同じ構文・同じ運用ルールで管理できる点。
CloudFormation は AWS 専用なので、オンプレや他クラウドが混在する環境では選択肢にならない点を論理立てて説明できるようになりました。

また State File の存在を使った ROI の説明も有効です。
IaC の価値は「同じ環境を何度でも作れる」だけではなく、コードと実インフラの乖離を検知できる点にあります。
「動いているからそのままでいい」という顧客に対して、運用フェーズで差分検知が機能することを具体的に示せます。

セキュリティ要件をコードのバリデーションで担保できる

試験で対比を覚えた validation / precondition / postcondition / check は、CI/CD のセキュリティゲートとしてそのまま使えます。

variable "environment" {
  type = string
  validation {
    condition     = contains(["dev", "stg", "prod"], var.environment)
    error_message = "environment は dev, stg, prod のいずれかを指定してください。"
  }
}

誤った環境名での apply を plan 段階でブロックできます。
検知より予防のほうがコストが低いですが、「どの構文がいつ評価されるか」を知らないと設計に入れられません。
参照: validation / precondition / check の構文仕様は HashiCorp Custom Conditions ドキュメント を参照。

まとめ

試験を通じて変わったのは、「Terraform が書ける」から「Terraform の動作を説明できる」になったことです。

資格の価値は合格した瞬間より、取った後にどう使うかで決まると思っています。
今後、社内でのコードレビューやプリセールス時に得た知識を活用していきたいと思います。

次は、上位資格の「Terraform Authoring and Operations Professional」取得を目指したいと思います。

参考資料

• HashiCorp Terraform 公式ドキュメント
• HashiCorp Custom Conditions ドキュメント
• Terraform Associate 試験についての参考記事 (Qiita)

Terraform Associate 004（2026年受験）・Terraform 1.x 系を前提としています。