Terraform Associateクイズ

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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

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

答え：

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