Terraform 資格の難易度を正しく見積もる：学習時間と出題レベル（Associate / Professional）

Terraform の資格は、基礎の網羅力（Associate）と、設計・運用までの総合力（Professional）で問われ方が大きく変わる。

学習時間は前提スキルで倍以上変わる。設計・状態管理・モジュールの3点に学習時間を集中すると費用対効果が高い。

全体像：難易度レンジと学習時間の現実解

HashiCorp Certified: Terraform Associate は IaC の基本、CLI 操作、状態管理の基礎、モジュール活用、Terraform Cloud/Enterprise の概念を幅広く問う。Professional はこれらに加え、チーム/ガバナンス設計、複数環境の構成戦略、ポリシー適用、トラブルシューティングまで踏み込む。

前提スキルがあるかで学習時間は大きく変わる。クラウドと Git の基本がある人なら Associate は20〜40時間、Professional は60〜120時間が目安。初学者はおおむね倍を見込むと無理がない。出題は「公式が説明する標準的な振る舞い」を前提に設計されるので、ベストプラクティスに沿った理解が最短経路になる。

• 難易度は「広く浅く（Associate）」から「広く深く（Professional）」へ
• 実務1年相当のハンズオンが Professional では効いてくる
• Terraform Cloud/Enterprise は概念理解が必須（詳細実装は出題範囲に注意）
• コマンドの効果と状態の遷移を言語化できると得点が安定する

出題レベルの実像：何がどの深さで問われるか

Associate は、公式ドキュメントで定義される Terraform の基本動作をどれだけ正確に把握しているかを問う。plan と apply の違い、状態と実インフラの対応、モジュールとレジストリの使い方、CLI ワークスペースと Terraform Cloud ワークスペースの概念差などが典型。

Professional は、正しい選択肢を選ぶだけでなく「なぜそれが最善か」を説明できるかに近い。状態管理の分割/移行、VCS 連携のブランチ戦略、ポリシー適用の境界、複数環境/アカウントに跨る依存関係の整理、障害時の安全な復旧など、実務判断を伴う出題が増える。

• plan は実インフラを変更しない。apply が状態と実インフラを更新する
• -replace=ADDR による安全な再作成、import による取り込みの正しい手順
• for_each / count / depends_on の依存解決とアドレス指定
• CLI Workspace と Terraform Cloud Workspace の違い（同名でも役割が別）
• Registry モジュールのバージョン固定と breaking change 回避

Terraform 基本フロー（資格で頻出の概念配置）

学習時間の見積りとプランニング（4週間/8週間）

短期（4週間）で Associate を目指す場合は、平日1時間＋週末3時間程度で計20〜30時間を確保し、各週の到達目標と模擬演習を固定する。Professional は同ペースだと8週間以上を推奨。重要なのは「読む→書く→壊す→直す」のサイクルを最短で回すこと。

公式ドキュメントのタスク中心の読み方が近道になる。CLI リファレンスは暗記でなく、実行結果を観察して挙動を体験する。バージョン依存の小ネタより、状態管理と設計判断の理解に時間を多めに割くと合格に直結する。

• 週単位でドメインを固定（状態→モジュール→TFC→運用）
• 毎週1回はゼロから init/plan/apply/destroy を通す
• Registry モジュールを1つは採用し version を固定
• 学習ログを残し、誤りの原因と回避策を自分の言葉で記録

実務と資格対策を両立する演習メニュー

演習は「小さく作って、安全に壊せる」題材を選ぶ。S3 バックエンド＋DynamoDB ロック、Registry の VPC モジュール、環境変数の分離を組み合わせると、Associate〜Professional の頻出トピックを横断的に体験できる。

意識する観点は3つ。状態の安全性（バックエンドとロック）、再現性（version 固定、変数バリデーション）、拡張性（モジュール化と for_each）。すべて公式が示す標準動作に沿って観察し、plan の差分と apply の結果を言語化する。

• backend の設定とロックの確認（並行 apply の抑止）
• モジュールの入力/出力を理解し、version を固定
• workspace で環境を切り替え、変数の違いを検証
• -replace と import を安全に試し、復旧手順を確立

学習用 main.tf（S3 backend + Registry モジュール）

terraform {
  required_version = ">= 1.5.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
  backend "s3" {
    bucket         = "example-tfstate-bucket"
    key            = "workspaces-example/terraform.tfstate"
    region         = "ap-northeast-1"
    dynamodb_table = "tf-lock"
    encrypt        = true
  }
}

provider "aws" {
  region = var.region
}

variable "region" {
  type    = string
  default = "ap-northeast-1"
  validation {
    condition     = contains(["ap-northeast-1", "us-east-1"], var.region)
    error_message = "サポート対象のリージョンを指定してください。"
  }
}

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"

  name = "exam-lab"
  cidr = "10.0.0.0/16"
  azs  = ["ap-northeast-1a", "ap-northeast-1c"]

  public_subnets       = ["10.0.1.0/24", "10.0.2.0/24"]
  enable_dns_hostnames = true

  tags = { Project = "cert" }
}

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

つまずきポイントと回避策（公式動作に沿って理解する）

状態と差分の理解不足が最頻出のつまずき。plan は変更を提案するだけで、apply が初めて実インフラと状態を書き換える。状態ドリフトは plan で検出されるので、意図しない破壊を避けるためにも差分の根拠を読み解く習慣が重要。

既存リソースの取り込みは import を使う。state ファイルの直接編集は非推奨で、トラブルの温床。再作成が必要なら apply -replace=ADDR を使い、影響範囲を最小化する。count と for_each はアドレス指定が変わるため、リファクタ時のリソース移動（moved ブロック）を併用して破壊的変更を防ぐ。

• state の直接編集は避ける。import / state rm / moved を正しく使う
• -replace は最小範囲で指定し、依存先の再作成を抑制
• for_each へ移行時はキーの安定性を担保（キー変更は破壊的）
• Terraform Cloud の Workspace と CLI Workspace の混同に注意

試験当日の対応：時間配分と見落としやすい知識

先に確実な問題を回収し、判断を要する設計問題は2巡目に回す。plan 出力の読み取り問題は、追加/変更/破棄それぞれの根拠を示す行を素早く確認する。CLI と Terraform Cloud の用語差（run、workspace、variable sets など）は混同しやすいので直前に用語整理をしておくと安定する。

Professional では、誤りでないが「より良くない」選択肢が並ぶ。安全性（並行制御、最小権限）、再現性（version 固定、immutable inputs）、運用性（分離と共有のバランス）の観点で比較し、公式推奨に近い回答を選ぶ姿勢が有効。

• 1巡目で確信度の高い問題を取り切る
• 出題の前提（TFC使用の有無、既存状態の有無）を先に確認
• CLI と TFC の workspace/variables のスコープを明確化
• 破壊的変更の回避策を優先する選択肢を選ぶ

問題で確認

よくある質問