収録問題 80問 ／ 10問ランダム出題
ランダムに出題・即時フィードバック・間違えた問題の復習機能付き
Terraform Associateのおすすめ教材を見る →
複数の担当者が同じクラウド環境を再現できるようにしたい。Terraformを使う主な利点として最も適切なのはどれですか？
答え： 宣言的な構成をコードとして版管理できる
Terraformでは望ましいインフラ状態を構成ファイルで表し、Gitなどで変更履歴を管理できます。
同じTerraform構成を、インフラがすでに望ましい状態にある環境へ再適用しました。通常期待される結果はどれですか？
答え： 差分がなければ変更は提案されない
Terraformは構成、state、実環境を比較し、差分がなければ変更なしと判断します。
リポジトリを初めて取得した直後、構成が要求するproviderとモジュールを準備したい。最初に実行するコマンドはどれですか？
答え： terraform init
terraform initは作業ディレクトリを初期化し、バックエンド、provider、モジュールを準備します。
本番変更のレビュー時点と適用時点で内容が変わらないようにしたい。適切な手順はどれですか？
答え： terraform plan -out=tfplanで保存し、terraform apply tfplanを実行する
保存済みplanをapplyへ渡すと、レビューした実行計画そのものを適用できます。
CIでTerraform構成の構文と内部整合性を、インフラを変更せずに確認したい。最も適切なコマンドはどれですか？
答え： terraform validate
terraform validateは構成の構文と引数などの整合性を検査し、リモートリソースを変更しません。
環境名としてdev、stg、prodだけを受け付け、誤入力をplan前に検出したい。適切なのはどれですか？
答え： 変数ブロックのvalidationブロック
入力変数のvalidationで条件とエラーメッセージを定義すると、不正値を早期に拒否できます。
複数のリソースで共通に使う命名用の文字列があります。外部からの入力にはせず、構成の中で一度だけ計算したい。何を使いますか？
答え： localsブロック
ローカル値は構成内の式や共通値に名前を付け、重複を減らすために使います。
サブネットを名前ごとに管理しています。一覧に新しい名前を追加しても、既存のリソースインスタンスとの対応が崩れないようにしたい。適切なメタ引数はどれですか？
答え： for_each
for_eachはmapやsetのキーで各インスタンスを識別でき、意味のある安定したアドレスを作れます。
チームで同じ構成を操作するため、stateの同時更新による破損を防ぎたい。最も適切な方針はどれですか？
答え： state lockingに対応したremote backendを利用する
共有remote stateとlockingを使うと、単一の正本を保ちつつ競合する書き込みを抑止できます。
リソースブロック名を変更したが、実インフラを作り直したくない。変更履歴を構成に残す方法はどれですか？
答え： 旧アドレスから新アドレスへのmovedブロックを追加する
movedブロックは旧アドレスと新アドレスの対応を宣言し、リファクタをstateへ安全に反映します。
手作業で作られた既存リソースをTerraform管理へ取り込みたい。最初に必要な考え方はどれですか？
答え： 対象をstateのリソースアドレスへ関連付ける
importは既存オブジェクトをTerraformのリソースアドレスとstate上で対応付けます。管理継続には対応する構成も必要です。
出力へsensitive = trueを設定しました。この設定について正しい説明はどれですか？
答え： 通常のCLI表示を抑えるが、state保護は別途必要である
sensitiveは表示漏えいを減らしますが、値がstateに存在する場合があります。stateのアクセス制御や暗号化も必要です。
チーム全員が同じproviderの入手元と互換バージョン範囲を使うようにしたい。どこへ定義しますか？
答え： terraformブロックのrequired_providers
required_providersでsource addressとバージョン制約を宣言し、ロックファイルで選択結果を固定できます。
同じAWS providerを東京と大阪の2リージョンで使い分けたい。適切な方法はどれですか？
答え： 片方のprovider設定へaliasを付け、各リソースで選択する
provider aliasを使うと、同じproviderの複数設定を定義し、リソースやモジュールへ明示的に渡せます。
子モジュールで作成したVPC IDをルートモジュールの別リソースから使いたい。必要なのはどれですか？
答え： VPC IDを公開する出力
子モジュールの出力はモジュール呼び出し元への公開インターフェースとなり、module.name.output_nameで参照できます。
Terraform Registryのモジュールを本番で利用する。予期しない破壊的変更を避けるため、最も適切な設定はどれですか？
答え： モジュールブロックでバージョン制約を指定する
Registry moduleのバージョン制約で採用可能なリリース範囲を管理し、更新をレビュー可能にします。
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のリソーススキーマはバージョンで変わり得ます。ロックファイルと選択バージョン、対応ドキュメントを確認します。
Terraformの宣言的アプローチの説明として最も適切なものはどれですか？
答え： 望ましい最終状態を記述し、到達手順はTerraformが決める
Terraformは望ましい状態を宣言し、現状との差分から必要な変更をTerraformが計画・適用します。
Terraformのplanとapplyの役割分担として適切なものはどれですか？
答え： planは変更計画を表示し、applyが実際に変更を適用する
planは差分（実行計画）を提示し変更はしません。applyがその計画に従って実環境を変更します。
構成ファイルのインデントや書式を標準スタイルに自動整形するコマンドはどれですか？
答え： terraform fmt
terraform fmtはHCLを標準フォーマットへ整形し、レビューしやすく差分を安定させます。
誤って管理対象リソースを全て削除しないために、destroy前に確認すべきことはどれですか？
答え： 実行計画（plan）の削除対象と対象workspace/環境
destroyは対象環境の全管理リソースを削除し得ます。対象workspaceと削除計画を必ず確認します。
リソース作成時に、削除より先に新リソースを作成してダウンタイムを避けたい。適切なライフサイクル設定はどれですか？
答え： create_before_destroy = true
create_before_destroyは置換時に新リソースを先に作ってから旧を削除し、ダウンタイムを抑えます。
外部からの変更を取り込み、特定属性の差分を無視して不要な置換を避けたい。適切な設定はどれですか？
答え： ライフサイクルのignore_changes
ignore_changesは指定属性の差分を無視し、外部要因で変わる値による不要な変更を防ぎます。
Terraform stateファイルに機密情報が含まれ得ることへの対策として適切なものはどれですか？
答え： 暗号化対応のremote backendを使い、アクセスを制限する
stateには平文の機密が入り得るため、暗号化対応バックエンドとアクセス制御で保護します。
stateと実インフラの差分を検出するため、変更を加えずに現状を更新・確認したいときに使うのはどれですか？
答え： terraform plan（refreshを伴う差分確認）
planは現状を参照して構成との差分（ドリフト）を提示し、インフラは変更しません。
採用したproviderの正確なバージョンを記録し、チーム全員が同じバージョンを再現できるようにするファイルがあります。terraform initで生成されるこのファイルはどれですか？
答え： .terraform.lock.hcl（依存関係ロックファイル）
ロックファイルは選択されたproviderバージョンとハッシュを固定し、環境間で同じバージョンを再現します。
新しいproviderバージョンへ意図的に更新し、ロックファイルを書き換えたいときに使うコマンドはどれですか？
答え： terraform init -upgrade
init -upgradeは制約の範囲内でprovider/moduleを更新し、ロックファイルを更新します。
モジュールを呼び出す際、利用側から値を渡すために定義するものはどれですか？
答え： 入力変数（変数）
モジュールの入力変数は呼び出し側からのパラメータ入口で、出力が結果の出口になります。
共通のネットワーク構成を複数プロジェクトで再利用したい。Terraformで適切な方法はどれですか？
答え： 再利用可能なモジュールとして切り出し、各所からバージョン指定で呼び出す
共通構成はモジュール化して再利用し、バージョンで更新範囲を管理すると保守性と一貫性が高まります。
HCP Terraformのremote runで得られる主な利点として適切なものはどれですか？
答え： 共有環境でplan/applyを実行し、state管理や実行ログを一元化できる
remote runは共有環境で実行し、state・ログ・権限・変数を一元管理できチーム運用に適します。
機密値を変数で受け取るときの扱いとして適切なものはどれですか？
答え： sensitive = trueにし、tfvarsをコミットせず安全に渡す
機密変数はsensitive指定で表示を抑え、tfvarsや環境変数・秘密管理で安全に渡します。値はstateに残り得る点も意識します。
applyが「state lockを取得できない」と失敗した。まず確認・対応すべきこととして適切なものはどれですか？
答え： 他の実行が進行中でないか確認し、残留ロックのみ慎重にforce-unlockする
まず同時実行の有無を確認します。本当に残留したロックだけを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を定義し、各リソースやモジュールへ対応するproviderを渡す
同一providerの複数設定にはaliasを使います。リソースのproviderメタ引数やモジュールのproviders引数で使用する設定を明示します。
同じモジュールから複数の環境用インスタンスをキー付きで作成したい。適切な方法はどれですか？
答え： モジュールブロックにfor_eachを指定する
モジュールブロックはfor_eachを使用でき、各キーの値をeach.keyやeach.valueで入力へ渡せます。キーはモジュールインスタンスのアドレスにも使われます。
出力に機密値を含める必要がある。画面への通常表示を抑えるために指定するものはどれですか？
答え： 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かどうかを検証したい。一致しなければ独自のメッセージを出して止めたい。適切なのはどれですか？
答え： ライフサイクル内のprecondition
preconditionはリソース、データソース、出力の前提条件を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へ永続化しません。対応するバージョン引数で更新を明示する実装もあります。
既存リソースを宣言的に取り込み、対応するリソース構成の生成案も確認したい。適切な方法はどれですか？
答え： importブロックを記述し、terraform plan -generate-config-out=generated.tfを使う
importブロックは取り込み先アドレスとIDを構成で宣言できます。generate-config-outを付けたplanは、未記述のリソース構成案をファイルへ生成できます。
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を指定する
元のリソースをremovedブロックへ置き換え、fromで対象アドレス、ライフサイクル内でdestroy = falseを指定します。planで実物が破棄されず管理から外れることを確認します。外した後の更新・削除はTerraformが管理しないため、引継ぎ先と責任範囲を合わせます。
prevent_destroy = trueを付けたTerraformのリソースブロックを、設定ごと削除しました。ほかの削除保護がない場合、この設定だけで実物の削除を防げますか？
答え： 設定自体も消えるため、この設定だけでは防げない
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ブロックのコマンドを省略しました。実行環境として適切なのはどれですか？
答え： テスト専用環境で実行し、残存リソースも確認する
runの既定コマンドは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は各要素の値として扱います。文字列への変換や依存関係の追加だけでは未知の値は既知になりません。
親モジュールでaws.drというalias付きproviderを定義しました。子モジュールもaws.drを参照します。子へ同じ設定を渡すための構成はどれですか？
答え： 子でaliasを宣言し、呼出し側のprovidersで対応付ける
alias付きprovider設定は子モジュールへ自動継承されません。子のrequired_providersでconfiguration_aliasesにaws.drを宣言し、親のモジュールブロックでproviders = { aws.dr = aws.dr }のように明示的に渡します。バージョン要件と、リージョンなどを持つ設定の受渡しは別です。
.terraform.lock.hclをGitで共有しています。それでも、Registryのモジュールをバージョン範囲で指定していると、新しいモジュール版が選ばれることがあります。その理由として適切なのはどれですか？
答え： ロックファイルが固定する対象はproviderであるため
依存関係ロックファイルはproviderの選択とチェックサムを扱い、リモートモジュールの版を固定しません。モジュールを厳密に再現したい場合はモジュール側で正確なバージョンを指定するなど、取得元に応じた固定方法が必要です。
Terraformのバックエンドを変更し、既存のstateを旧バックエンドから新バックエンドへ移したい。変更作業を止めてバックアップを取った後に実行する、state移行を伴う初期化コマンドの候補はどれですか？
答え： terraform init -migrate-stateを実行する
-migrate-stateは既存stateの新バックエンドへのコピーを試みます。対象workspaceや移行先を確認し、移行後のplanで意図しない作り直しがないことも確かめます。-reconfigureは以前のバックエンド設定を無視して再設定するもので、既存stateの移行は行いません。
JSONをjsondecodeしたlocal.configにregion属性がない場合だけ、既定値を使いたい。try(local.config.region, "ap-northeast-1")の動作はどれですか？
答え： 属性参照のエラー時に既定の文字列を返す
tryは引数を順に評価し、エラーにならない最初の結果を返します。外部データの欠けた属性などの正規化に使います。未宣言の参照や構文の誤りまで修復する関数ではなく、nullを必ず既定値へ置き換えるものでもありません。
入力変数のvalidationで、文字列var.amountが数値へ変換できるか調べたい。can(tonumber(var.amount))の結果は何ですか？
答え： 変換評価の成否を真偽値で返す
canは式がエラーなく評価できるかを真偽値で返します。例えば"12"ならtrue、数値に変換できない"abc"ならfalseです。入力値そのものを変更したり、変換結果を返したりはしません。
Terraform 1.3以降で、オブジェクト型の属性enabledをoptional(bool, true)と定義しました。呼び出し側がその属性を省略するとどうなりますか？
答え： enabledには既定のtrueが設定される
optionalの第2引数は、その属性の既定値です。ここではboolのtrueが補われます。オブジェクト全体のdefaultと個別属性のdefaultは別の設定なので、入力インターフェースを設計するときに区別します。
toset(["web", "web", "api"])をfor_eachの入力に使います。できるインスタンスの識別について正しい説明はどれですか？
答え： webとapiをキーとする2個になる
setは重複を除き、元の順序を保持しません。文字列setのfor_eachでは各値がキーとなるため、webとapiの2個です。同名の複数インスタンスが必要なら、重複しない論理キーを持つmapなどで表します。
機密のAPIキーをnonsensitiveで包めば公開ログへ出してよいという案があります。適切な判断はどれですか？
答え： 表示上の機密指定を外すだけで秘密は残る
nonsensitiveは機密扱いのマークを取り除く関数です。暗号化・匿名化・失効ではありません。公開してよい派生情報かを確認せず、秘密自体の表示制御を外すと漏えいにつながります。
ネットワークIDだけを参照したい利用者に、terraform_remote_stateのためにstateの読取り権限を渡します。機密性の面で注意する点はどれですか？
答え： state全体へアクセスできる権限になり得る
このデータソースが式へ返すのはroot outputですが、取得にはstateスナップショット全体へのアクセスが必要です。出力だけ公開したい場合は、共有用の設定ストアなどへ必要な値を分離して公開する設計も検討します。
terraform apply -targetで障害箇所だけを復旧できました。復旧後の確認として適切なのはどれですか？
答え： 通常のplanで構成全体の残る差分を確認する
-targetは例外的な復旧などのための限定実行です。全体が構成どおりになったことは保証しないため、通常のplanで残る差分を確認します。日常の変更を常に部分適用すると、意図しない不整合を見落としやすくなります。
速度改善のためplanに-refresh=falseを付けました。クラウド側の手動変更がある場合の注意点はどれですか？
答え： 古いstateを前提に不完全な計画を作り得る
-refresh=falseは計画前の管理対象の状態更新を省きます。外部で変わった実態を反映しないまま計画すると、不完全または不正確になり得ます。provider設定やデータソースなどの通信まで全面的に禁止する指定ではありません。
Terraform 1.5以降でimportブロックを書き、planの生成構成を保存しました。既存リソースの取込みについて適切な次の対応はどれですか？
答え： 生成構成と計画の意図をレビューして適用する
planの構成生成はレビューの出発点です。生成された設定が実態や管理方針に合うか、importに加えて更新・置換・削除が計画されていないかを確認します。importブロックによるstateへの取込みはapplyで行います。
入力変数にdefault = "dev"だけを設定し、nullableは既定のtrueです。呼び出し側が明示的にnullを渡したときの値はどれですか？
答え： 明示したnullが値として使われる
nullableがtrueの入力変数では、明示的なnullがdefaultより優先します。値を省略した場合とnullを渡した場合を区別します。nullを受け付けたくない設計ではnullable = falseなどを検討し、契約を明確にします。