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　リソースの作成は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はない

正解：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　ステートは構成のバックアップではない。構成のバックアップはバージョン管理システムの役割

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　バックエンド設定の再構成であり、残置されたロックは解除されない

正解：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 を使う

正解：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　個々のリソースの破棄を防ぐだけで、組織横断の規約の強制には使えない