Terraform Associate 004 #10 模擬試験 — 全範囲 50 問 + 解説
読了 20分
シリーズの最終回、全範囲の模擬試験です。解き方の要領は GitHub Foundations 模擬試験と同じです。
- 60 分以内に解いてみます(実際の試験と同じ時間で、問題の密度も近い構成です)
- 1 問ずつすぐに解説を見ずに、最後まで解いてから採点します
- 35 問(70%)以上なら受験準備が整ったと見なします(実際の合格ラインは非公開のため、保守的な基準です)
- 弱い領域が見えたら、該当回(#2〜#9)に戻って整理します
領域配分 #
| 領域 | 問題数 | 範囲 |
|---|---|---|
| IaC の概念と Terraform の目的 (#2) | 6 | Q1〜Q6 |
| 基本: バージョンと provider (#3) | 6 | Q7〜Q12 |
| コアワークフロー (#4) | 8 | Q13〜Q20 |
| state 管理 (#5) | 8 | Q21〜Q28 |
| モジュール (#6) | 6 | Q29〜Q34 |
| 設定の記述とカスタム条件 (#7) | 7 | Q35〜Q41 |
| 新規範囲: ephemeral とメタ引数 (#8) | 5 | Q42〜Q46 |
| HCP Terraform (#9) | 4 | Q47〜Q50 |
IaC の概念と Terraform の目的(Q1〜Q6) #
Q1. IaC(Infrastructure as Code)の利点として適切でないものはどれですか。
解説
IaC は管理方法の改善であり、料金表を変えるものではありません。再現性、バージョン管理、一貫性が正解軸のキーワードで、コスト削減や障害の根絶といった誇張した選択肢がこの領域の定番の罠です。
Q2. Terraform の設定方式を最も正確に説明しているのはどれですか。
解説
Terraform の設定は「何が欲しいか」を書き、手順を書きません。plan が現在の状態との差分から実行計画を計算します。A はシェルスクリプト方式の説明です。
Q3. 同じ設定で Terraform apply を何度実行しても結果が同じになる性質を何と呼びますか。
解説
すでにあるべき状態と一致していれば何もしないため、apply は冪等(idempotent)です。用語そのものを問う問題が実際に出題され、原子性(全部か無か)との混同を狙ってきます。
Q4. Terraform が数多くのクラウドや SaaS をサポートできる構造的な理由はどれですか。
解説
Terraform コアはグラフ計算と plan・state 管理を担い、実際の API 呼び出しは init のときにダウンロードされる provider プラグインが担当します。この分業がエコシステム拡大の構造的な背景です。
Q5. Terraform state の根本的な目的として最も適切なのはどれですか。
解説
state はコードと実際のインフラを比較する根拠になるマッピングで、リソースの属性と依存関係の記録です。state がなければ Terraform は何を管理しているのか分かりません。
Q6. provisioner に対する HashiCorp の公式な立場として適切なのはどれですか。
解説
provisioner は宣言型モデルの外でスクリプトを実行する仕組みのため、失敗処理と冪等性が弱く、公式ドキュメントが最後の手段と位置づけています。イメージビルドや専用の構成管理ツールが推奨される方向です。
基本: バージョンと provider(Q7〜Q12) #
Q7. バージョン制約
~> 6.2 が許容する範囲はどれですか。解説
チルダ演算子は明示した最後の桁の増加だけを許容します。
~> 6.2 は 6.2、6.3、… 6.x までを許し、7.0 をブロックします。~> 6.2.0 なら 6.2.x までしか許されないという違いもあわせて覚えておく必要があります。Q8. .terraform.lock.hcl ファイルの説明として正しいのはどれですか。
解説
required_providers が許容範囲だとすれば、ロックファイルはその中から選ばれた正確なバージョンの固定記録です。コミットすることでチームと CI が同じバージョンを使います。名前の lock は state ロックと無関係というのが罠のポイントです。
Q9. ロックファイルに記録された provider のバージョンを、許容範囲内の最新に上げるコマンドはどれですか。
解説
init -upgrade が制約範囲内で最新バージョンを選び直し、ロックファイルを更新します。C と D は存在しないコマンドです。
Q10. 同じ AWS provider を異なるリージョン設定で 2 つ使うにはどうしますか。
解説
provider ブロックに alias を付けて登録し、リソース側で
provider = aws.alias のように選びます。CloudFront の証明書の us-east-1 要件が代表例です。ほとんどのリソースには region 引数がありません。Q11. provider の認証情報の管理として推奨される方式はどれですか。
解説
認証情報のハードコードは常に誤答の方向です。環境変数、共有認証情報ファイル、実行環境のロール(EC2 インスタンスプロファイル、CI の OIDC)が正解の方向です。
Q12. .terraform ディレクトリの説明として正しいのはどれですか。
解説
.terraform はローカルキャッシュのため、いつでも init で作り直せて .gitignore の対象です。ロックファイル(.terraform.lock.hcl)はこのディレクトリの外にある別ファイルという点も区別のポイントです。
コアワークフロー(Q13〜Q20) #
Q13. HashiCorp が定義する Terraform コアワークフローの 3 段階はどれですか。
解説
公式の 3 段階は Write、Plan、Apply です。init は準備コマンドで、destroy は apply -destroy のエイリアスであり、独立した段階ではないというフレーミングまで出題されます。
Q14. terraform init を再実行する必要がある状況ではないのはどれですか。
解説
init の仕事はバックエンド・provider・モジュールの準備です。リソースの引数の修正は plan・apply の領域で、init は必要ありません。
Q15. plan で確認した内容を、その間の変更なしに正確にそのまま適用する方法はどれですか。
解説
保存された計画ファイルで apply すると、再計算なしにその計画がそのまま適用されます。B は間隙が残り、C はプロンプトの省略だけで再計算します。CI パイプラインの標準パターンです。
Q16. 破損が疑われるリソース 1 つを、次の apply で強制的に作り直させる現行の方法はどれですか。
解説
-replace が taint コマンドの後継の標準です。taint は廃止予定の流れにあり、B は重複作成のリスク、D は削除後の作成になるため順序と参照がずれます。
Q17. -target フラグの説明として最も適切なのはどれですか。
解説
-target はコードとインフラのずれを生みかねないため、障害復旧のような例外的な状況向けです。日常の使用を勧める選択肢は誤答の方向です。
Q18. terraform validate の説明として正しいのはどれですか。
解説
validate は未宣言の変数や誤った引数名といった、設定そのもののエラーを捕まえます。クラウド接続がないため認証情報が不要で、provider のスキーマが必要なため init 後に実行します。B は fmt、D は plan -refresh-only の仕事です。
Q19. 最も詳細な Terraform のデバッグログをファイルに残す設定はどれですか。
解説
デバッグログはコマンドのフラグではなく TF_LOG 環境変数で有効化し、TRACE が最詳細レベルです。TF_LOG_PATH がファイルパスの指定です。B・C・D は存在しません。
Q20. terraform destroy と同じことをするコマンドはどれですか。
解説
destroy は apply -destroy のエイリアスです。plan -destroy は削除計画のプレビューだけで実行せず、state rm は管理からの除外だけでリソースを消しません。
state 管理(Q21〜Q28) #
Q21. デフォルト(ローカルバックエンド)の動作で state が保存される場所はどこですか。
解説
ローカルバックエンドの state は作業ディレクトリの terraform.tfstate です。.terraform ディレクトリはプラグインとモジュールのキャッシュという区別が罠のポイントです。
Q22. リモートバックエンドがローカル state に比べて提供する利点ではないのはどれですか。
解説
plan の計算ロジックはバックエンドに関係なく同じです。リモートバックエンドの価値は共有、ロック、保管の安定性です。
Q23. apply を実行したら「Error acquiring the state lock」が出ました。最初にすべきことはどれですか。
解説
ロックは同時実行を防ぐ正常な動作のため、ほとんどの場合は待つのが正解です。force-unlock は実行者がいないことを確認した後の最後の手段で、進行中の実行のロックを解除すると state の同時書き込み事故になります。
Q24. terraform force-unlock の説明として正しいのはどれですか。
解説
force-unlock は残っているロックの印を取り除くことがすべてです。state を直すことも、他の実行を中断させることもありません。
Q25. terraform state rm を実行するとどうなりますか。
解説
state rm はマッピングの記録だけを消す、管理からの除外です。実際のリソース削除は destroy またはコード削除後の apply の仕事という区別が、このコマンドの核心の出題ポイントです。
Q26. リソースブロックの名前を変えつつ再作成を避ける宣言的な方法はどれですか。
解説
名前の変更はデフォルトでは「削除 + 作成」として計算されるため、moved ブロック(または命令型の state mv)でアドレスの移動を知らせる必要があります。D のような自動認識はありません。
Q27. コンソールで先に作られた既存リソースを Terraform の管理下に取り込む現行の標準はどれですか。
解説
import ブロック(1.5 以上)がレビュー可能な標準の道で、-generate-config-out でコードの下書きも作れます。A は重複作成の試み、B は破損リスクがあり禁じ手です。
Q28. sensitive = true と指定した変数の値の説明として正しいのはどれですか。
解説
sensitive は画面上のマスキングにすぎません。state 平文問題の根本的な対応は write-only 引数で、運用面の対応は state 保管先の暗号化とアクセス制御です。
モジュール(Q29〜Q34) #
Q29. Terraform におけるルートモジュールとは何ですか。
解説
実行ディレクトリの設定がルートモジュールで、module ブロックで呼ぶものが子モジュールです。どんな設定も最低 1 つのモジュール(ルート)であるというフレーミングが出題されます。
Q30. module ブロックの version 引数が有効な source はどれですか。
解説
version はレジストリソース専用です。Git ソースは URL の ref クエリで、ローカルパスはバージョンの概念なしにその時点のファイルで決まります。
Q31. 子モジュールが作った値を呼び出し側で読む方法はどれですか。
解説
モジュールはカプセル化されていて、output で公開された値だけを読めます。必要な値に output がなければ、モジュールに output を追加するのが答えです。
Q32. module ブロックを新しく追加した後、plan が「Module not installed」エラーを出します。解決策はどれですか。
解説
モジュールのインストールは init の仕事です。モジュールの追加や source の変更の後は init を再実行する必要があります。
Q33. パブリックレジストリの verified 表示の説明として正しいのはどれですか。
解説
verified はパートナー検証の表示であり、使用制限でもセキュリティ保証でもありません。モジュールの評価はレジストリの入力・出力ドキュメントとソースで行います。
Q34. レジストリモジュールに version を指定しないとどうなりますか。
解説
version の省略は最新の追跡になるため、誰かが公開した新バージョンが予告なく plan を変え得ます。モジュールのバージョン固定が再現性の基本習慣である理由です。ロックファイルは provider 用で、モジュールのバージョンは記録しません。
設定の記述とカスタム条件(Q35〜Q41) #
Q35. 同じ変数に複数の方法で値が渡されるとき、最終的に適用されるのはどれですか。
解説
優先順位は環境変数 → terraform.tfvars → auto.tfvars → コマンドラインの順で、後のものが勝ちます。コマンドラインの指定が最も強いです。
Q36. locals の説明として正しいのはどれですか。
解説
宣言は複数形の locals、参照は単数形の local という表記の違いが細かい罠です。外部入力は variable、内部計算は locals という役割分担もあわせて出題されます。
Q37. ユーザーデータのスクリプトファイルを読みながら変数を差し込みたいです。適切な関数はどれですか。
解説
templatefile がファイルを読みながら、渡した変数で置換します。file は置換なしで内容を読むだけです。user_data 構成の定番関数です。
Q38. 式の結果を apply なしで対話的に実験するコマンドはどれですか。
解説
console が現在の設定の変数やリソースを読みながら式を実験できる対話型ツールです。eval や expression というコマンドは存在しません。
Q39. リソースの lifecycle ブロックの中で「このリソースを評価する前に成立すべき前提」を検証するのはどれですか。
解説
precondition が評価前の前提、postcondition が評価後の結果の保証です。validation は変数の入力値検証、check は apply をブロックしない継続的な検証という 4 つの区別がこの領域の軸です。
Q40. postcondition の中で自分自身の属性を参照するキーワードはどれですか。
解説
postcondition では self で評価後の自分の属性を参照します(例: self.architecture)。this はモジュール内のリソース名の慣例でありキーワードではなく、each は for_each の反復変数です。
Q41. カスタム条件のうち、失敗しても apply をブロックせず警告だけ残すのはどれですか。
解説
check ブロックだけが非ブロッキングです。デプロイを止めずにインフラの状態(証明書の期限切れ間近など)を継続的に監視する用途で、残りの 3 つは失敗すると plan・apply を止めます。
新規範囲: ephemeral とメタ引数(Q42〜Q46) #
Q42. ephemeral な値の性質として正しいのはどれですか。
解説
ephemeral は記録に残らない実行中専用の値のため、シークレットの扱いに適しています。実行のたびに新しく評価されるという性質が B との区別のポイントです。
Q43. aws_db_instance の password_wo のような write-only 引数の値を後から入れ替える方法はどれですか。
解説
値が state にないため Terraform は変更を検知できず、バージョン番号の増加が入れ替えのトリガーです。この「検知不能 → バージョントリガー」の論理が write-only の出題の核心です。
Q44. depends_on を使うことが正当な場合はどれですか。
解説
依存関係は参照から自動推論されるため、depends_on は参照で表現されない隠れた依存専用です。不要な宣言は並列性を下げて apply を遅くするだけです。
Q45. リストベースの count で作ったリソース群で、リストの中間の要素を削除すると何が起きますか。
解説
count リソースのアイデンティティはインデックスのため、中間の削除が後ろの要素をすべてずらします。キーベースで安全な for_each がこの罠への答えで、両者の選択基準の問題として繰り返し出題されます。
Q46. 本番データベースが誤って削除計画に含まれるのを Terraform のレベルで防ぐ設定はどれですか。
解説
prevent_destroy は削除計画が作られた瞬間にエラーでブロックします。限界(コンソールからの削除は防げず、ブロックの削除とともに保護も消える)まで束にして出題されます。
HCP Terraform(Q47〜Q50) #
Q47. HCP Terraform の workspace の説明として正しいのはどれですか。
解説
HCP の workspace は CLI のワークスペースと名前だけ同じ別の概念で、state・変数・履歴・権限がまとまるプラットフォームの管理単位です。project が複数の workspace を束ねる上位構造です。
Q48. 複数の workspace に共通のクラウド認証情報を供給する標準的な方法はどれですか。
解説
variable set が共通変数の束の正解です。workspace 個別の変数が variable set より優先されるという優先順位もあわせて覚えます。
Q49. Sentinel ポリシーのうち、違反時にブロックされるが権限者がオーバーライドして進められるレベルはどれですか。
解説
soft-mandatory が「ブロックするがオーバーライド可能」です。hard-mandatory は回避不能なブロック、advisory は警告を残すだけです。3 レベルの区別がポリシー問題のすべてと言ってよいほどの定番です。
Q50. Terraform Enterprise とは何ですか。
解説
Enterprise は同じ系統の機能のセルフホスト版です。外部の SaaS にデータを置けない組織のための形態という位置づけだけ分かれば十分です。
採点と次のステップ #
35 問(70%)以上なら受験準備が整ったと見なします。間違えた問題は領域配分の表から該当回を探して戻ります。特に #7 のカスタム条件と #8 の新規範囲は 004 で新しく入った分だけ、誤答が集中したなら優先的に補強する対象です。受験前には公式の study guide とサンプル問題で、試験の英語表現に一度慣れておくことをおすすめします。
シリーズとともに進めてきた学習はここで終わりです。この資格ラインの土台になった Terraform 基礎・実践・運用トラックの 26 本が実務の深さを担っているので、試験の準備中に手が覚えていない概念に当たったら、いつでもトラックに下りて実習を添えることをおすすめします。合格を祈っています。