Terraform Associate 004 #2 IaC の概念と Terraform の目的 — 定義問題の攻略
最初の試験範囲は定義の領域です。「IaC の利点でないものはどれか」「Terraform はマルチクラウドをどう扱うか」といった問題で、概念そのものは基礎 #1ですべて登場した内容です。落とし穴は、見慣れていることにあります。知っている内容だからと流し読みして、選択肢の微妙な言い回しの違い(冪等性と原子性、provider と provisioner)にひっかかる領域だからです。試験の言葉に並べ直していきます。
IaC の定義と利点 #
試験が期待する定義は、インフラを手作業の手順ではなく、機械が読める定義ファイルでプロビジョニング・管理する方式です。利点を問う問題で正解候補になるキーワードは次のとおりです。
- 再現性: 同じコードは同じインフラを作ります。環境の複製と災害復旧の土台です。
- バージョン管理: インフラの変更が Git の履歴・レビュー・ロールバックの対象になります。
- 自動化: 人のコンソール操作を CI パイプラインに置き換えます。
- 一貫性(ドリフトの減少): コードが唯一の真実になり、環境間のずれが減ります。
逆に、「IaC の利点」として当てはまらないものを選ばせる問題では、「インフラのコストそのものの削減」「障害の根本的な排除」といった誇張した選択肢がひっかけとして出ます。IaC は管理方式の改善であって、料金表やハードウェアを変えるものではありません。
宣言型と冪等性 #
- 宣言型(declarative): 望む最終状態を記述すると、道具が到達方法を計算します。Terraform の方式です。
- 命令型(imperative): 実行する手順を順番に記述します。シェルスクリプトの方式です。
- 冪等性(idempotency): 同じ操作を何度適用しても結果が同じである性質です。Terraform の apply はすでに一致しているリソースに触れないため、冪等です。
試験の言葉で固めると、Terraform の設定ファイルは「何が欲しいか」を記述し、「どう作るか」の手順は記述しません。plan が現在の状態と望む状態の差を計算して実行計画を作る構造(基礎 #1の宣言型の動作)が、これらの性質の出どころです。
Terraform の目的 — 試験が推す 3 つ #
「なぜ Terraform なのか」を問う問題の正解の軸は 3 つです。
- マルチクラウドと provider エコシステム: Terraform のコアはクラウドを知りません。AWS、Azure、GCP はもちろん SaaS まで provider プラグインが担当し、同じ HCL の文法で数千の provider のリソースを扱えます。「各クラウドの専用ツールを覚えずに 1 つのワークフローに統一できる」が、試験が期待する利点の言い回しです。
- state による追跡: Terraform は管理中のリソースを state に記録し、コード・state・実物の比較で変更を計算します。「state の目的は何か」への答えは、実際のインフラと設定のマッピングを維持して plan を可能にすることです。詳しい構造は #5 で扱います。
- 実行計画(plan): 適用前に何が変わるのかを見せる段階がワークフローに組み込まれています。レビューと安全の根拠です。
頻出の区別問題 #
この領域のひっかけ選択肢は、似た単語の役割の混同から生まれます。表で固めておきます。
| 用語 | 役割 | 混同しやすい相手 |
|---|---|---|
| provider | クラウドやサービスの API との接続プラグイン | provisioner(作成後のスクリプト実行、最後の手段) |
| resource | 管理対象のインフラオブジェクトの宣言 | data source(読み取り専用の参照) |
| Terraform(コア) | グラフ計算・plan・state 管理のバイナリ | provider(実際の API 呼び出しの担当) |
| HCL | 人が書く設定言語(JSON 互換の表記もあり) | YAML(Terraform とは無関係、ひっかけ選択肢の常連) |
特に provisioner は、「Terraform が推奨する構成管理の方法」のように装った誤答として頻出します。公式の立場は最後の手段(last resort)であり、構成管理はイメージのビルドや専用ツールに任せるのが推奨です。
Terraform の構造 — バイナリ 1 つ、プラグイン多数 #
アーキテクチャ問題への備えとして、構造を一度に整理します。Terraform は単一バイナリ(コア)で、init のときに設定に宣言された provider プラグインをダウンロードして一緒に動きます。コアが設定と state から依存関係グラフを作って plan を計算し、provider が各リソースの CRUD を実際の API 呼び出しとして実行します。「Terraform はなぜ新しいサービスが出ても対応できるのか」の答えがこのプラグイン構造で、基礎 #1の比較表で見た競合ツールに対するエコシステムの優位の技術的な背景でもあります。
まとめ #
今回扱った内容です。
- IaC の利点のキーワードは再現性、バージョン管理、自動化、一貫性です。コストや障害の根本解決といった誇張選択肢がひっかけです
- Terraform は宣言型で、apply は冪等です。設定は最終状態を記述し、手順を記述しません
- Terraform の目的の問題は、マルチクラウドの provider エコシステム、state による追跡、実行計画の 3 軸で答えます
- provider と provisioner、resource と data source の役割の区別がひっかけの常連で、provisioner は最後の手段です
- コアはグラフと plan、provider は API 呼び出しという分業構造を覚えておきます
次回(#3 Terraform の基本)では、インストールとバージョン管理、provider の設定に入ります。バージョン制約の演算子とロックファイルという、試験がとりわけ好む 2 つのテーマがある領域です。