収録問題 50問 ／ 10問ランダム出題
ランダムに出題・即時フィードバック・間違えた問題の復習機能付き
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として登録し、閲覧やログへの露出を抑えます。