Terraform サンプル問題

正解：B

A　それは手続き的(imperative)なアプローチの説明。シェルスクリプトやSDKを使った自動化がこれにあたる

B（正解）　正解。構成ファイルには「あるべき姿」だけを書き、依存関係の解析と実行順序の決定はTerraformが担う

C　宣言的であることは再作成を意味しない。Terraformは差分のみを適用し、一致しているリソースには手を触れない

D　対話的な操作はコード化の対極にあり、宣言的という語とは無関係

正解：D

A　変更を以前の状態に戻す操作のこと。ずれが生じる現象そのものを指す語ではない

B　同じ操作を何度実行しても結果が変わらない性質。ずれを防ぐ側の概念であり、ずれの名称ではない

C　新旧2系統の環境を切り替えるリリース手法。構成のずれとは別の話題

D（正解）　正解。IaCではplanで実環境と構成の差分を検出できるため、ドリフトを早期に発見して収束させられる

正解：A

A（正解）　正解。Terraform Coreは構成とステートの差分計算を担い、実際のAPI呼び出しはプロバイダプラグインが行う

B　本体には同梱されない。プロバイダはinit時にレジストリから個別にダウンロードされる

C　Terraformはエージェントレスで、APIを直接呼び出す。常駐エージェントは不要

D　リソースタイプはプロバイダ固有(aws_instance、azurerm_virtual_machineなど)。共通化された抽象リソースは提供されない

正解：C

A　よくある誤解。リソースタイプも引数もプロバイダ固有なので、クラウドを変えれば構成の書き直しが必要

B　移行機能は持たない。Terraformはあくまで各プロバイダのAPIを呼ぶだけ

C（正解）　正解。AWSとCloudflareとDatadogを1つのplan/applyで扱うといった、ツールとワークフローの統一が本質

D　バイナリは共通で、差分はプロバイダプラグインが吸収する

正解：B

A　コスト最適化はコード管理の直接の効果ではない。料金はどのリソースをどれだけ作るかで決まる

B（正解）　正解。差分レビュー、変更理由の追跡、リバートといったソフトウェア開発の実践をインフラ変更に持ち込める

C　構成をGitに置いてもステートは必要。ステートは構成と実リソースの対応を保持するもので、役割が異なる

D　実際にAPIを呼ぶ際の資格情報と権限は依然として必要

正解：C

A　ステートに既存リソースが記録されているため重複作成はされない。ステートを持たないスクリプトとの決定的な違い

B　差分がなければ破棄も再作成も行われない。再作成は引数の変更や-replaceの指定で起こる

C（正解）　正解。同じ操作を繰り返しても結果が変わらないこの性質を冪等性と呼ぶ

D　エラーにはならない。差分ゼロは正常な結果

正解：B

A　リソースの作成はapplyの役割。initはリソースに一切触れない

B（正解）　正解。作業ディレクトリを使用可能な状態に整える初期化コマンドで、他のほとんどのコマンドの前提となる

C　実リソースの読み取りと同期はrefresh(planやapplyの一部)が行う処理

D　整形はterraform fmtの役割

正解：C

A　providerブロックはリージョンや資格情報などの設定用。かつてはversionも書けたが非推奨で、バージョン宣言はrequired_providersに集約された

B　これは呼び出し元のプロバイダ設定をモジュールへ引き渡すための引数。どのバージョンを使うかの宣言とは役割が異なる

C（正解）　正解。terraform { required_providers { aws = { source = "hashicorp/aws", version = "~> 5.0" } } } の形で宣言する

D　variableは入力変数の宣言用で、プロバイダの依存関係とは無関係

正解：A

A（正解）　正解。悲観的制約演算子は指定した最も右の桁だけ増加を許すため、~> 4.16はマイナーバージョンの上昇を許し、メジャーの5.0は許さない

B　その範囲になるのは ~> 4.16.0と3桁で書いた場合。桁数によって意味が変わる点が頻出のひっかけ

C　1つに固定したい場合はversion = "4.16.0" のように等号で書く

D　上限なしにしたい場合は ">= 4.16" と書く。~> には必ず上限がある

正解：D

A　ステートのロックはバックエンド側の機能で、このファイルとは無関係。名前が似ているための頻出の取り違え

B　進捗の記録用ではなく、init時に生成・更新される永続的なファイル

C　資格情報は保存されない。秘匿情報を含まないためリポジトリにコミットできる

D（正解）　正解。依存関係ロックファイルと呼ばれ、バージョン管理にコミットしてチーム全員で同じプロバイダを使うようにする

正解：B

A　-reconfigureはバックエンド設定を既存の設定を無視して初期化し直すオプション。プロバイダの更新は行わない

B（正解）　正解。制約を満たす最新のプロバイダとモジュールを取得し直し、.terraform.lock.hclを更新する

C　実リソースの現状をステートに反映するだけで、プラグインの更新はしない

D架空　このサブコマンドは存在しない。terraform providersにはlockやmirrorといったサブコマンドはあるがupgradeはない

正解：C

A　GitHubリポジトリの指定ではない。プロバイダはビルド済みバイナリとしてレジストリから配布される

B　ローカルパスではない。ローカルの実装を使う場合はdev_overridesなど別の仕組みを用いる

C（正解）　正解。完全形はregistry.terraform.io/hashicorp/awsで、ホスト名を省略すると公開レジストリが既定になる

D　バックエンドとは無関係。sourceはプロバイダの配布元アドレス

正解：A

A（正解）　正解。指定したディレクトリを共有キャッシュとして使い、既に取得済みのプラグインは再ダウンロードせず再利用する

B　作業ディレクトリ内の .terraformに相当する作業用ディレクトリの場所を変える変数。ディレクトリ間の共有キャッシュにはならない

C　デバッグログの出力先ファイルを指定する変数で、プラグイン取得とは無関係

D　initに既定の引数を毎回付け足す変数。オプションを書く手間は省けるが、ダウンロードの重複そのものは解消しない

正解：D

A　分割するのも設計上ありうるが、単一構成でも実現できるため「しかない」は誤り

B　リージョンはプロバイダ設定の引数であり、個々のリソースにregion引数は存在しない

C　required_providersでは同じプロバイダを重複して宣言できない。宣言は1つで、設定を複数持たせるのが正しい

D（正解）　正解。エイリアスによって同一プロバイダの複数設定を使い分けられる。エイリアスなしの設定が既定として使われる

正解：A

A（正解）　正解。planは読み取りと差分計算のみを行う。適用は別途applyが必要

B　planは規模にかかわらず一切の変更を行わない

C　既存リソースの取り込みはimportの役割で、planは自動では行わない

D　整形はfmt、検証はvalidate。planはそれらより先の、実環境との差分計算まで行う

正解：C

A　-forceは古いバージョンの名残で、現在のapplyでは承認スキップの正規のオプションではない

B　-input=falseは未指定の変数などを対話的に尋ねる動作を止めるための指定で、適用の承認そのものを省くものではない。承認を省くには -auto-approveか保存済みプランの指定が要る

C（正解）　正解。yesの入力を求めずにそのまま適用する。保存済みプランファイルを渡す場合も確認は省略される

D　ステートのロック取得を無効にするオプション。承認プロンプトとは無関係で、むしろ同時実行によるステート破損を招く

正解：B

A　実リソースの現状をステートに反映するだけで、リソースは削除されない

B（正解）　正解。destroyは、管理下の全リソースを削除する計画を作って適用するapply -destroyの別名にあたる

C　state rmはステートから外すだけで実リソースは残る。むしろ課金され続ける取り残しを生む危険な取り違え

D　結果的に削除計画にはなるが、コードを失う破壊的な操作であり等価な手段とは言えない

正解：D

A　公式には例外的な用途とされ、常用は推奨されない。構成全体との整合が崩れやすい

B　ステートからの除外はstate rm。-targetは計画の対象を絞るオプション

C　依存先も必要に応じて計画に含まれる。完全に単独で評価されるわけではない

D（正解）　正解。エラーからの回復やデバッグのための一時的な手段であり、常用すると構成ドリフトを招く

正解：B

A　planは実リソースを読み取るためプロバイダの認証が必要になる。資格情報のない環境では失敗しうる

B（正解）　正解。属性名の誤りや型の不一致などを構成内で完結して検査する。事前にinitでプロバイダのスキーマが必要な点に注意

C　確認できるのは書式が正規形かどうかだけで、構文エラーや参照ミスの検出は目的ではない

D　ステートや保存済みプランの内容を人が読める形で表示するコマンドで、構成の検証は行わない

正解：A

A（正解）　正解。-checkは書き換えずに差分の有無だけを判定し、整形が必要ならゼロ以外の終了コードを返す。-recursiveでサブディレクトリも対象になる

B　-diffは変更内容を表示するオプション。単体では書き換えが行われ、CIの失敗判定にも使えない

C　validateにこのオプションはなく、そもそも書式の検査は担当外

D　書き換えずに対象ファイル名を列挙するだけで、整形が必要でも終了コードは成功のまま。CIで失敗させるには -checkが要る

正解：C

A　TF_LOG_PROVIDERはプロバイダのログだけに絞る変数、TF_DATA_DIRは作業用ディレクトリの場所を変える変数。どちらもログの出力先指定ではない

B　変数名が誤り。レベルを渡すのはTF_LOG、出力先はTF_LOG_PATH

C（正解）　正解。TF_LOGにはTRACE/DEBUG/INFO/WARN/ERRORを指定でき、TRACEが最も詳細。TF_LOG_PATHの指定でファイルにも書き出される

D　-verboseというオプションはなく、ログレベルの制御は環境変数で行う

正解：D

A架空　cloneというサブコマンドは存在しない

B　initにこのオプションはない。ワークスペースの操作は専用のサブコマンドで行う

C　selectは既存のワークスペースへの切り替え専用で、存在しない名前を指定するとエラーになる

D（正解）　正解。newは作成と同時に切り替えも行う。構成内ではterraform.workspace式で現在の名前を参照できる

正解：A

A（正解）　正解。保存済みプランを渡すと計画は再計算されず、承認された変更だけが適用される。この場合は確認プロンプトも表示されない

B　テキストは人が読むための記録に過ぎない。applyが改めて計画を作り直すため、その間の変更が入り込みうる

C　-targetは対象を絞るだけで、計画内容の同一性は保証しない

D　-lock=falseはむしろロックを無効化する指定で、意味が逆

正解：B

A　ステートに含まれるリソースアドレスの一覧が出るだけで、属性値は得られない

B（正解）　正解。outputブロックで公開した値をJSONで取得できる。単一の値ならterraform output -raw <名前> も使える

C　式を評価する対話シェルで、スクリプトからの機械的な取得には向かない

D　ステート全体をJSONで出せるが構造が大きく、目的の値を取るだけならoutputのほうが適切

正解：C

A　ステートは構成のバックアップではない。構成のバックアップはバージョン管理システムの役割

B　資格情報の保管場所ではない。むしろステートには機密の属性値が平文で入りうるため、保護すべき対象

C（正解）　正解。どの定義がどの実IDに対応するかを記録することで、次回以降に作成・更新・削除のどれが必要かを判断できる

D　計画の永続化はplan -outで作るプランファイルの役目で、ステートとは別物

正解：A

A（正解）　正解。既定はlocalバックエンドで、更新時には直前の内容がterraform.tfstate.backupとして残される

B　.terraformにはプラグインやモジュールが置かれる。ステートは作業ディレクトリ直下で、しかも暗号化されない

C　設定なしに外部へ送信されることはない。リモート保存には明示的なバックエンドやcloudブロックの設定が要る

D　APIからの全再構築はできないためステートが必要になる。これがTerraformの設計の前提

正解：B

A　機密値が平文で入るうえ、同時編集でコンフリクトやロックの欠如による破損を招く。明確なアンチパターン

B（正解）　正解。共有・排他制御・暗号化・バージョニングをまとめて満たせる

C　ワークスペースは環境の分離のための機能。同じ環境を複数人で扱う課題は解決せず、むしろ別々の実環境ができてしまう

D　運用上の緩和策にはなるが、その担当者のPCにステートが依存する単一障害点は残る

正解：D

A　対応状況はバックエンドごとに異なる。ロックを提供しないものもある

B　ステートを書き換えうる操作で取得される。ロックが不要な参照系の操作もある

C　ローカルのメモリでは別のマシンからの同時実行を防げない。ロックはバックエンド側の共有資源で管理される

D（正解）　正解。S3バックエンドでは長らくDynamoDBテーブルの指定でロックを実現してきた。-lock=falseで無効化できるが原則として避ける

正解：C

A　ロックを無効にしたまま運用すると、同時実行でステートを破壊しかねない。恒久的な回避策にしてはいけない

B　管理対象の追跡情報をすべて失う破壊的な操作。実リソースが全て管理外になる

C（正解）　正解。エラーメッセージに表示されたIDを指定して解除する。実行中の操作が本当にないことの確認が前提

D　バックエンド設定の再構成であり、残置されたロックは解除されない

正解：A

A（正解）　正解。ステート上のアドレスだけを付け替えるため、実リソースには一切変更が入らない。1.1以降はmovedブロックでコードとして表現することもできる

B　ステートから外れるだけで新アドレスには結び付かず、次のapplyで新しいインスタンスが作られてしまう

C　-replaceは意図的に再作成させるオプション。避けたい結果をむしろ引き起こす

D架空　このサブコマンドは存在しない

正解：B

A　実リソースは削除されない。削除まで行うのはdestroyやapplyによる破棄計画

B（正解）　正解。以後planには現れず、構成に定義が残っていれば新規作成の対象として扱われる点に注意

C　読み取り専用という状態は存在しない。エントリ自体が削除される

D　自動では戻らない。管理下に戻すにはimportが必要

正解：C

A　自動検出はされない。同名でも新しいリソースを作ろうとするか、名前衝突でエラーになる

B　state mvはステート内のアドレス移動用で、外部の既存リソースを取り込む機能はない

C（正解）　正解。importはステートに既存リソースを結び付けるだけなので、構成側の定義は自分で用意する必要がある。1.5以降はimportブロックと -generate-config-outで定義の生成も可能

D　既にステートにあるリソースの状態を更新するだけで、未管理のリソースは取り込まれない

正解：D

A　同じ効果は得られるが非推奨(deprecated)。ステートを直接書き換える点も後継の方法に劣る

B　管理を外して戻すだけで、再作成にはならない

C　置き換えが起きるときの順序を変える設定であり、置き換え自体を起こす指示ではない

D（正解）　正解。置き換えを計画に含めたうえで通常どおり確認・適用できるため、taintより安全で見通しがよい

正解：C

A　環境変数はデフォルト値を除けば最も優先度が低い。「環境変数が最優先」という思い込みが典型的なひっかけ

B　環境変数よりは優先されるが、コマンドラインの指定には負ける

C（正解）　正解。優先順位は高いほうから -var / -var-file、*.auto.tfvars、terraform.tfvars、TF_VAR_ 環境変数、variableブロックのdefaultの順

D　重複してもエラーにはならず、優先順位に従って1つが採用される

正解：B

A　接頭辞が誤り。TERRAFORM_ という接頭辞は使われない

B（正解）　正解。TF_VAR_ に続けて変数名をそのまま(大文字小文字を含めて一致させて)書く

C　変数名は大文字小文字が区別されるため、db_userという宣言にはこの名前は対応しない

D　TF_ で始まる環境変数はCLIの動作設定用(TF_LOGなど)で、入力変数の受け渡しにはTF_VAR_ を使う

正解：D

A　変数の宣言(variableブロック)を書く慣習的なファイル名で、値を与えるファイルではない

B　自動では読み込まれない。-var-file=prod.tfvarsと明示的に指定する必要がある

C　拡張子が .tfvarsで終わらないため対象外。雛形を配布するための慣習的なファイル

D（正解）　正解。terraform.tfvars(および .json版)と、任意の名前に .auto.tfvarsを付けたファイルが自動的に読み込まれる

正解：A

A（正解）　正解。条件を満たさない値が与えられると、指定したメッセージとともに早い段階で失敗する

B　nullを許さないという指定であり、値の中身が3つのいずれかかどうかは検査できない

C　Terraformの型システムにenum型はない

D　preconditionはlifecycleブロック内でリソースやデータソースに対して書くもの。入力変数そのものの検査にはvalidationが適切

正解：B

A　eachはfor_eachを使ったときに利用できるオブジェクト。countでは参照できない

B（正解）　正解。0, 1, 2と採番され、name = "web-${count.index}" のように使う

C　selfはプロビジョナー内で自身の属性を参照する特殊な語で、繰り返しの添字は持たない

D　語順が逆で、このような参照は存在しない

正解：C

A　受け付けるのはマップか文字列のセット。リストを使う場合はtoset()などで変換する必要がある

B　countとfor_eachは同一ブロックで同時に指定できない

C（正解）　正解。セットを渡した場合はeach.keyとeach.valueが同じ値になる

D　整数の添字で識別されるのはcountのほう。for_eachはキーの文字列で識別される

正解：D

A　そうなるのはfor_eachを使った場合。countでは添字が繰り上がるため影響が波及する

B　countの値が変わるため必ず差分が生じる

C　エラーにはならず、計画は成立してしまう。だからこそ意図しない再作成に気付きにくい

D（正解）　正解。この副作用を避けるには、要素を安定したキーで識別できるfor_eachを使う

正解：A

A（正解）　正解。dynamic "ingress" { for_each = var.rules content { ... } } のように書く。contentの中では、既定でブロックのラベルと同じ名前の変数(この例ではingress.value)で各要素を参照する

B　countが増やすのはリソース自体であって、リソース内部のネストブロックではない

C　ingressはネストブロックなので、繰り返しの数を変数で決めたいならdynamicが要る。属性のように値を代入する書き方はプロバイダの実装に依存するうえ、省略可能な引数も書き切る必要があり推奨されない

D　for式が作れるのはリストやマップなどの値であり、ブロック構造そのものは生成できない

正解：C

A　参照があれば依存関係は自動的に推論される。この場合にdepends_onを書くのは冗長

B　不要な直列化は並列実行の利点を損なう。depends_onは必要な箇所に限って使う

C（正解）　正解。IAMポリシーの反映待ちなど、参照関係として表現できない依存を明示するための最終手段

D　モジュール内でも参照から自動推論される。depends_onはモジュール呼び出しにも書けるが、それも暗黙依存があるときの手段

正解：B

A　指定した属性の差分を無視するだけで、破棄は止められない

B（正解）　正解。そのリソースを破棄する計画が作られた時点でエラーになる。恒久的に消せなくなるわけではなく、引数を外せば破棄できる

C架空　このような引数は存在しない

D　置き換え時に新しいリソースを先に作る順序制御。破棄そのものは防げない

正解：D

A　リストから指定した位置の要素を取り出す関数で、マップのキー参照には使えない

B　引数の中から最初のnullでも空でもない値を返す関数。キーの有無を扱うものではない

C架空　このような組み込み関数は存在しない

D（正解）　正解。lookup(var.tags, "env", "dev")のように第3引数で既定値を指定できる

正解：B

A　取り出せないわけではない。sensitiveが抑えているのは通常の表示への露出であって、値の取得そのものではない

B（正解）　正解。-rawや -jsonを指定した場合は機密値も平文で出力されると公式に明記されている。出力先の取り扱いには注意が要る

C　書き換えは不要。指定したままでも明示的に値を求めるコマンドでは取得できる

D架空　このオプションは存在しない。伏せずに取り出すには -rawか -jsonを使う

正解：D

A　ステートは引き続き必要で、HCP Terraformが保管とバージョン管理を担う

B　リモート側に実行環境がある。速度ではなく一貫性と統制が主な価値

C　むしろ逆で、資格情報をワークスペース側に集約でき、個人PCへの配布を避けられる

D（正解）　正解。個人の端末環境の差異に左右されず、誰が何を適用したかの記録も残る

正解：A

A（正解）　正解。CLIのワークスペースが同一バックエンド内でステートを分けるだけなのに対し、HCP側はより広い設定の入れ物になっている

B　含むものが大きく異なる。この取り違えは頻出

C　ステートの保管はHCP Terraformの中心的な機能のひとつ

D　CLIのワークスペースが分けるのはステート。変数の切り替えは -var-fileなどで別途行う

正解：C

A架空　このような機能名は存在しない

B　検査できるのは構成の内部整合性まで。計画の中身に対する組織的な規約の強制はできない

C（正解）　正解。planとapplyの間で評価され、advisory / soft-mandatory / hard-mandatoryの強制レベルを設定できる

D　個々のリソースの破棄を防ぐだけで、組織横断の規約の強制には使えない

正解：B

A　誰でも参照できてしまうため、社内限定という要件を満たさない

B（正解）　正解。組織内に限定して発行でき、moduleブロックのsourceとversionで通常のレジストリモジュールと同じように利用できる

C　複製が増えるほど更新の追随が困難になる。バージョン管理された単一の配布元を持つのが狙い

D　ステートの共有はモジュールの配布手段ではない。他構成の出力を読むterraform_remote_stateとも別の話

正解：C

A　PRの時点では適用されない。applyはマージ後の実行で、しかも承認設定に従う

B　PR時にフィードバックを返せることがVCS連携の主な価値なので、何も起きないというのは誤り

C（正解）　正解。適用はされない使い捨ての計画で、レビュー時点で変更内容を把握できる

D　投機的プランは適用を伴わないため、ステートをロックしない