Terraform Associate 問題集・過去問対策クイズ

複数の担当者が同じクラウド環境を再現できるようにしたい。Terraformを使う主な利点として最も適切なのはどれですか？

答え： 宣言的な構成をコードとして版管理できる

Terraformでは望ましいインフラ状態を構成ファイルで表し、Gitなどで変更履歴を管理できます。

同じTerraform構成を、インフラがすでに望ましい状態にある環境へ再適用しました。通常期待される結果はどれですか？

答え： 差分がなければ変更は提案されない

Terraformは構成、state、実環境を比較し、差分がなければ変更なしと判断します。

リポジトリを初めて取得した直後、構成が要求するproviderとmoduleを準備したい。最初に実行するコマンドはどれですか？

答え： terraform init

terraform initは作業ディレクトリを初期化し、backend、provider、moduleを準備します。

本番変更のレビュー時点と適用時点で内容が変わらないようにしたい。適切な手順はどれですか？

答え： terraform plan -out=tfplanで保存し、terraform apply tfplanを実行する

保存済みplanをapplyへ渡すと、レビューした実行計画そのものを適用できます。

CIでTerraform構成の構文と内部整合性を、インフラを変更せずに確認したい。最も適切なコマンドはどれですか？

答え： terraform validate

terraform validateは構成の構文と引数などの整合性を検査し、リモートリソースを変更しません。

環境名としてdev、stg、prodだけを受け付け、誤入力をplan前に検出したい。適切なのはどれですか？

答え： variableブロックのvalidationブロック

input variableのvalidationで条件とエラーメッセージを定義すると、不正値を早期に拒否できます。

複数リソースで共通利用する命名文字列を、外部入力として公開せず構成内で一度だけ計算したい。何を使いますか？

答え： localsブロック

local valueは構成内の式や共通値に名前を付け、重複を減らすために使います。

サブネットを名前ごとに管理し、一覧へ別の名前を追加しても既存インスタンスとの対応を安定させたい。適切なメタ引数はどれですか？

答え： for_each

for_eachはmapやsetのキーで各インスタンスを識別でき、意味のある安定したアドレスを作れます。

チームで同じ構成を操作するため、stateの同時更新による破損を防ぎたい。最も適切な方針はどれですか？

答え： state lockingに対応したremote backendを利用する

共有remote stateとlockingを使うと、単一の正本を保ちつつ競合する書き込みを抑止できます。

リソースブロック名を変更したが、実インフラを作り直したくない。変更履歴を構成に残す方法はどれですか？

答え： 旧アドレスから新アドレスへのmovedブロックを追加する

movedブロックは旧アドレスと新アドレスの対応を宣言し、リファクタをstateへ安全に反映します。

手作業で作られた既存リソースをTerraform管理へ取り込みたい。最初に必要な考え方はどれですか？

答え： 対象をstateのリソースアドレスへ関連付ける

importは既存オブジェクトをTerraformのリソースアドレスとstate上で対応付けます。管理継続には対応する構成も必要です。

outputへsensitive = trueを設定しました。この設定について正しい説明はどれですか？

答え： 通常のCLI表示を抑えるが、state保護は別途必要である

sensitiveは表示漏えいを減らしますが、値がstateに存在する場合があります。stateのアクセス制御や暗号化も必要です。

チーム全員が同じproviderの入手元と互換バージョン範囲を使うようにしたい。どこへ定義しますか？

答え： terraformブロックのrequired_providers

required_providersでsource addressとversion constraintを宣言し、lock fileで選択結果を固定できます。

同じAWS providerを東京と大阪の2リージョンで使い分けたい。適切な方法はどれですか？

答え： 片方のprovider設定へaliasを付け、各リソースで選択する

provider aliasを使うと、同じproviderの複数設定を定義し、リソースやmoduleへ明示的に渡せます。

child moduleで作成したVPC IDをroot moduleの別リソースから使いたい。必要なのはどれですか？

答え： VPC IDを公開するoutput

child moduleのoutputはmodule呼び出し元への公開インターフェースとなり、module.name.output_nameで参照できます。

Terraform Registryのmoduleを本番で利用する。予期しない破壊的変更を避けるため、最も適切な設定はどれですか？

答え： moduleブロックでversion制約を指定する

Registry moduleのversion制約で採用可能なリリース範囲を管理し、更新をレビュー可能にします。

GitへのPull Requestを契機に共有環境でplanを実行し、結果をチームで確認したい。HCP Terraformの構成として適切なのはどれですか？

答え： VCS連携したworkspaceを利用する

VCS連携workspaceはコミットやPull Requestに応じたremote runとplan共有を実現できます。

組織ルールに違反するインフラ変更をapply前に拒否したい。HCP Terraformで対応する考え方はどれですか？

答え： policy as codeをrunへ適用する

policy as codeは実行計画を組織ルールで評価し、条件に応じてrunを拒否または警告できます。

CIからクラウドへ認証する際、長期アクセスキーをTerraform変数へ保存したくない。推奨される方針はどれですか？

答え： 短期資格情報やワークロードID連携をproviderで利用する

短期資格情報やOIDCなどの動的認証を使うと、固定秘密情報の保管と漏えいリスクを減らせます。

terraform planでprovider schemaに存在しない引数というエラーが出た。最初に確認すべきものはどれですか？

答え： 利用中providerのバージョンと、そのバージョンのドキュメント

providerのリソースschemaはバージョンで変わり得ます。lock fileと選択バージョン、対応ドキュメントを確認します。

Terraformの宣言的アプローチの説明として最も適切なものはどれですか？

答え： 望ましい最終状態を記述し、到達手順はTerraformが決める

Terraformは望ましい状態を宣言し、現状との差分から必要な変更をTerraformが計画・適用します。

Terraformのplanとapplyの役割分担として適切なものはどれですか？

答え： planは変更計画を表示し、applyが実際に変更を適用する

planは差分（実行計画）を提示し変更はしません。applyがその計画に従って実環境を変更します。

構成ファイルのインデントや書式を標準スタイルに自動整形するコマンドはどれですか？

答え： terraform fmt

terraform fmtはHCLを標準フォーマットへ整形し、レビューしやすく差分を安定させます。

誤って管理対象リソースを全て削除しないために、destroy前に確認すべきことはどれですか？

答え： 実行計画（plan）の削除対象と対象workspace/環境

destroyは対象環境の全管理リソースを削除し得ます。対象workspaceと削除計画を必ず確認します。

リソース作成時に、削除より先に新リソースを作成してダウンタイムを避けたい。適切なlifecycle設定はどれですか？

答え： create_before_destroy = true

create_before_destroyは置換時に新リソースを先に作ってから旧を削除し、ダウンタイムを抑えます。

外部からの変更を取り込み、特定属性の差分を無視して不要な置換を避けたい。適切な設定はどれですか？

答え： lifecycleのignore_changes

ignore_changesは指定属性の差分を無視し、外部要因で変わる値による不要な変更を防ぎます。

Terraform stateファイルに機密情報が含まれ得ることへの対策として適切なものはどれですか？

答え： 暗号化対応のremote backendを使い、アクセスを制限する

stateには平文の機密が入り得るため、暗号化対応backendとアクセス制御で保護します。

stateと実インフラの差分を検出するため、変更を加えずに現状を更新・確認したいときに使うのはどれですか？

答え： terraform plan（refreshを伴う差分確認）

planは現状を参照して構成との差分（ドリフト）を提示し、インフラは変更しません。

terraform initで生成され、採用したproviderの正確なバージョンを記録してチーム間で再現性を保つファイルはどれですか？

答え： .terraform.lock.hcl（依存関係ロックファイル）

lockファイルは選択されたproviderバージョンとハッシュを固定し、環境間で同じバージョンを再現します。

新しいproviderバージョンへ意図的に更新し、lockファイルを書き換えたいときに使うコマンドはどれですか？

答え： terraform init -upgrade

init -upgradeは制約の範囲内でprovider/moduleを更新し、lockファイルを更新します。

moduleを呼び出す際、利用側から値を渡すために定義するものはどれですか？

答え： input variable（変数）

moduleのinput variableは呼び出し側からのパラメータ入口で、outputが結果の出口になります。

共通のネットワーク構成を複数プロジェクトで再利用したい。Terraformで適切な方法はどれですか？

答え： 再利用可能なmoduleとして切り出し、各所からバージョン指定で呼び出す

共通構成はmodule化して再利用し、versionで更新範囲を管理すると保守性と一貫性が高まります。

HCP Terraformのremote runで得られる主な利点として適切なものはどれですか？

答え： 共有環境でplan/applyを実行し、state管理や実行ログを一元化できる

remote runは共有環境で実行し、state・ログ・権限・variableを一元管理できチーム運用に適します。

機密値をvariableで受け取るときの扱いとして適切なものはどれですか？

答え： sensitive = trueにし、tfvarsをコミットせず安全に渡す

機密変数はsensitive指定で表示を抑え、tfvarsや環境変数・秘密管理で安全に渡します。値はstateに残り得る点も意識します。

applyが「state lockを取得できない」と失敗した。まず確認・対応すべきこととして適切なものはどれですか？

答え： 他の実行が進行中でないか確認し、残留lockのみ慎重にforce-unlockする

まず同時実行の有無を確認します。本当に残留したlockだけをforce-unlockで慎重に解除します。安易なstate削除は危険です。

Terraform構成の構文や参照関係が妥当かを、実際のリソース作成前に確認したい。適切なコマンドはどれですか。

答え： terraform validate

terraform validateは構成ファイルの構文、引数、参照などの妥当性を確認します。リモートAPIへ変更を加えるためのコマンドではありません。

同じ変数に環境変数、terraform.tfvars、コマンドラインの-varが指定されている場合、最も優先される値はどれですか。

答え： コマンドラインで指定した-varの値

Terraformの入力変数は複数の方法で設定できますが、コマンドラインの-varや-var-fileは高い優先順位を持ち、通常のtfvarsや環境変数より優先されます。

既に手作業で作成済みのクラウドリソースを、削除せずにTerraform管理へ取り込みたい。適切な操作はどれですか。

答え： terraform importで既存リソースをstateへ関連付ける

terraform importは既存リソースとTerraformのリソースアドレスをstate上で関連付けます。通常は対応するconfigurationも用意し、planで差分を確認します。

同じ構成で小規模な開発用と検証用のstateを分けたい場合、Terraform workspaceの説明として最も適切なものはどれですか。

答え： 同じ構成ディレクトリで複数のstateを切り替えて扱える仕組み

workspaceは同じ構成に対してstateを分ける機能です。ただし大規模な環境分離や権限分離には、ディレクトリやワークスペース設計を慎重に選ぶ必要があります。

HCP Terraformで、組織のルールに反するplanをapply前に止めたい。該当する考え方として最も適切なものはどれですか。

答え： policy as codeでplanを評価する

HCP Terraformではpolicy as codeにより、planの内容を組織ルールに照らして評価し、違反時に実行を警告または停止できます。

リソース名をaws_instance.oldからaws_instance.webへ変更するとき、実物の再作成を避けてアドレス変更を記録する方法はどれですか？

答え： movedブロックで移動元と移動先を宣言する

movedブロックはTerraformにリソースアドレスの移動を伝え、同じ実物を新しいアドレスで追跡させます。変更後はplanで再作成が発生しないことを確認します。

障害調査のため、管理中の1リソースだけを次回applyで置き換えるよう明示したい。適切なplanオプションはどれですか？

答え： -replace=リソースアドレス

-replaceは指定した管理対象を置換する計画を要求します。保存したplanを確認してからapplyすれば、意図した変更を事前確認できます。

変数subnet_idsが文字列の集合だけを受け取るよう制約したい。適切なtype指定はどれですか？

答え： set(string)

set(string)は重複を持たない文字列コレクションを表します。順序や重複が必要ならlist(string)など別の型を選びます。

本番環境と開発環境で権限・変更頻度・影響範囲が大きく異なる。state設計として適切なものはどれですか？

答え： 環境ごとにstateとアクセス制御を分離する

環境別にstateと権限を分けると、ロック競合や誤変更の影響範囲を小さくし、本番へのアクセスを限定できます。

同じAWS providerで東京と大阪の両リージョンへリソースを作成したい。適切な構成はどれですか？

答え： provider aliasを定義し、各resourceやmoduleへ対応するproviderを渡す

同一providerの複数設定にはaliasを使います。resourceのproviderメタ引数やmoduleのproviders引数で使用する設定を明示します。

同じmoduleから複数の環境用インスタンスをキー付きで作成したい。適切な方法はどれですか？

答え： moduleブロックにfor_eachを指定する

moduleブロックはfor_eachを使用でき、各キーの値をeach.keyやeach.valueで入力へ渡せます。キーはmoduleインスタンスのアドレスにも使われます。

outputに機密値を含める必要がある。画面への通常表示を抑えるために指定するものはどれですか？

答え： sensitive = true

sensitive指定はCLIやUIで値を伏せますが、値そのものを暗号化したりstateから除外したりはしません。state保管先の暗号化とアクセス制御も必要です。

plan時にdependency cycleエラーが出た。最も適切な対応はどれですか？

答え： 相互参照や不要なdepends_onを見直し、依存関係を一方向にする

cycleはAがBへ、BがAへ依存するような循環で発生します。参照やdepends_onを整理し、必要なら構成を分割して非循環グラフにします。

CLI workspaceごとにリソース名へ環境名を含めたい。現在のworkspace名を参照する式はどれですか？

答え： terraform.workspace

terraform.workspaceは現在選択中のCLI workspace名を返します。命名などに利用できますが、workspaceだけで強い権限分離が実現するわけではありません。

HCP Terraformで複数workspaceに共通の非機密変数や機密変数をまとめて適用したい。適切な機能はどれですか？

答え： variable set

variable setは複数workspaceへ共通変数を割り当てられます。機密値はsensitiveとして登録し、閲覧やログへの露出を抑えます。

AWS、Azure、SaaSの設定を同じTerraformワークフローで管理できる主な理由はどれですか？

答え： 各対象向けproviderがAPI操作を実装し、Terraformが共通の宣言的ワークフローを提供するため

Terraform Coreは構成、依存グラフ、plan、stateを扱い、各providerが対象APIとの通信とリソース型を実装します。この分離により共通ワークフローで複数サービスを管理できます。

リソース式からは推論できない外部的な順序制約があり、Terraformへ明示的な依存関係を伝えたい。何を使いますか？

答え： depends_onメタ引数

depends_onはTerraformが参照から自動推論できない隠れた依存関係を明示します。通常は属性参照による暗黙依存を優先し、必要な場合だけ使用します。

リソースを作成する前に、選択されたAMIのアーキテクチャがx86_64であることを検証し、条件不一致なら独自メッセージで止めたい。適切なのはどれですか？

答え： lifecycle内のprecondition

preconditionはリソース、data source、outputの前提条件をplan時に検証し、条件と独自エラーメッセージを定義できます。

短命なAPIトークンをprovider認証へ渡すが、planファイルとstateには保存したくない。Terraform 1.12の方針として適切なのはどれですか？

答え： 入力変数へephemeral = trueを設定し、必要に応じてsensitive = trueも併用する

ephemeral値は実行時に利用できますがplanとstateから除外されます。sensitiveはCLIやUIでの表示を伏せるため、機密値では両方を組み合わせる場合があります。

providerが対応するpassword_woのようなwrite-only引数の説明として正しいものはどれですか？

答え： 値をproviderへ渡した後、Terraformのplanやstateへ保持しない

write-only引数はproviderが実装する機能で、操作中に値を渡しつつplanとstateへ永続化しません。対応するversion引数で更新を明示する実装もあります。

既存リソースを宣言的に取り込み、対応するresource構成の生成案も確認したい。適切な方法はどれですか？

答え： importブロックを記述し、terraform plan -generate-config-out=generated.tfを使う

importブロックは取り込み先アドレスとIDを構成で宣言できます。generate-config-outを付けたplanは、未記述のresource構成案をファイルへ生成できます。

Terraform CLIの予期しない動作を調査するため詳細ログをstderrへ出したい。適切な方法はどれですか？

答え： TF_LOGへDEBUGやTRACEなどのログレベルを設定する

TF_LOGはTRACE、DEBUG、INFO、WARN、ERRORなどを指定して詳細ログを有効化します。ログには機密情報が含まれ得るため、調査後は無効化し安全に扱います。

HCP Terraformで多数のworkspaceを業務システムや担当チーム単位にまとめ、権限やポリシーの管理境界にしたい。使う機能はどれですか？

答え： Projects

HCP Terraform Projectsは関連workspaceを整理し、チーム権限やポリシーなどをまとまり単位で管理するために使います。

ネットワークworkspaceのapply成功後、そこへ依存するアプリworkspaceのrunを自動的にキューへ入れたい。適切なHCP Terraform機能はどれですか？

答え： run trigger

run triggerはsource workspaceのapply成功を契機に、依存するworkspaceへrunをキューできます。triggerによるrunのauto-apply設定は通常のauto-applyとは別に管理されます。

HCP Terraformのrunからクラウドへ接続するとき、保存済みの長期アクセスキーを減らしたい。推奨される方法はどれですか？

答え： dynamic provider credentialsでrunごとの短期認証情報を取得する

dynamic provider credentialsはOIDCなどの信頼関係を使い、run時に短命なクラウド認証情報を発行します。保存済み長期キーの漏えいリスクを下げられます。

Terraform 1.7以降で、管理中のリソースを別チームへ引き渡します。実物を削除せず、管理から外す変更をコードレビューできる形に残す方法はどれですか？

答え： removedにdestroy = falseを指定する

元のresourceをremovedブロックへ置き換え、fromで対象アドレス、lifecycle内でdestroy = falseを指定します。planで実物が破棄されず管理から外れることを確認します。外した後の更新・削除はTerraformが管理しないため、引継ぎ先と責任範囲を合わせます。

prevent_destroy = trueを付けたTerraformのresourceブロックを、設定ごと削除しました。ほかの削除保護がない場合、この設定だけで実物の削除を防げますか？

答え： 設定自体も消えるため、この設定だけでは防げない

prevent_destroyは構成に存在する間、破棄を伴う計画を拒否します。ブロックごと消すとこの設定も消えるため、削除を禁止する恒久的な外部制御ではありません。重要なリソースではplanレビューやクラウド側の削除保護も組み合わせます。

CIでterraform plan -detailed-exitcodeを実行すると、エラー表示はなく終了コード2でした。この結果をどのように扱うのが適切ですか？

答え： 差分ありとして、計画内容のレビューへ進める

detailed-exitcodeでは0が差分なし、1がエラー、2が差分ありの成功です。通常の「0以外は失敗」というCI設定をそのまま使うと、正常な変更計画まで失敗にします。planは実物へ変更を適用していないため、承認とapplyは別の段階です。

Terraformの通常変数に機密値を渡し、plan -out=tfplanで保存しました。画面ではsensitive指定で伏せ字です。このplanファイルの保管方針はどれですか？

答え： 機密値を含み得るため、閲覧者と保存期間を制限する

sensitiveによる画面上の伏せ字は、保存planから機密値を取り除く処理ではありません。通常の機密変数などが保存され得るため、CI成果物のアクセス制御・保管期間・暗号化を設計します。planの閲覧権限を、単なるログ閲覧と同じ感覚で広げないことが重要です。

Terraform 1.6以降のterraform testで、実providerを使うrunブロックのcommandを省略しました。実行環境として適切なのはどれですか？

答え： テスト専用環境で実行し、残存リソースも確認する

runの既定commandはapplyで、実providerなら課金対象を含むリソースを作る可能性があります。テスト用の独立した権限・環境を使い、終了時の破棄失敗も確認します。作成を伴わない検証が目的なら、適切なrunでcommand = planを明示するなど目的に合わせます。

Terraform 1.5以降で、checkブロックのassert条件がfalseでした。構成自体に別のエラーがない場合、この仕組みを必須条件の強制に使う際の注意点はどれですか？

答え： 失敗は警告なので、実行を止める検証と使い分ける

checkのassert失敗は警告で、通常はTerraformの処理を停止しません。必須入力にはvariable validation、リソース操作の前提にはpreconditionなど、止めるための仕組みを使い分けます。観測した不健全な状態の通知と、変更を許可しない条件は区別します。

新規作成するリソースのIDをmapのキーにしてfor_eachへ渡したところ、plan時にキーが未確定というエラーになりました。適切な見直しはどれですか？

答え： 既知の論理名をキーにし、作成後のIDは値へ持たせる

for_eachはplanでインスタンスのアドレスを確定するため、キーが既知である必要があります。環境名などの安定した論理キーを使い、作成後に決まるIDは各要素の値として扱います。文字列への変換や依存関係の追加だけでは未知の値は既知になりません。

親moduleでaws.drというalias付きproviderを定義しました。子moduleもaws.drを参照します。子へ同じ設定を渡すための構成はどれですか？

答え： 子でaliasを宣言し、呼出し側のprovidersで対応付ける

alias付きprovider設定は子moduleへ自動継承されません。子のrequired_providersでconfiguration_aliasesにaws.drを宣言し、親のmoduleブロックでproviders = { aws.dr = aws.dr }のように明示的に渡します。バージョン要件と、リージョンなどを持つ設定の受渡しは別です。

.terraform.lock.hclをGitで共有していますが、Registry moduleを範囲指定していると新しいmodule版が選ばれることがあります。理由として適切なのはどれですか？

答え： lockファイルが固定する対象はproviderであるため

依存関係lockファイルはproviderの選択とチェックサムを扱い、リモートmoduleの版を固定しません。moduleを厳密に再現したい場合はmodule側で正確なversionを指定するなど、取得元に応じた固定方法が必要です。

Terraformのbackendを変更し、既存stateを旧backendから新backendへ移したい。変更作業を止めてバックアップを確保した後、移行を伴う初期化の候補はどれですか？

答え： terraform init -migrate-stateを実行する

-migrate-stateは既存stateの新backendへのコピーを試みます。対象workspaceや移行先を確認し、移行後のplanで意図しない作り直しがないことも確かめます。-reconfigureは以前のbackend設定を無視して再設定するもので、既存stateの移行は行いません。