LPIC-3 仮想化・コンテナ化クラウド管理とcloud-initオリジナル・公式資料照合難易度★★★★☆
Terraformで作成したクラウド資源は実在しているが、管理用stateを失った。構成は同じでもplanが新規作成を提案する。既存資源を誤って二重作成しないための適切な対応はどれか。
A
stateがないなら資源も消えたはずなので、確認せずapplyする
stateの喪失と実際のクラウド資源の削除は別です。無確認のapplyは二重作成や競合につながります。
B
実在資源と構成を照合し、正当なstateの復元または対応するimportで関連付けを再構成して、planを確認する★ 正解
stateは構成中の資源と実在するオブジェクトの対応を管理します。復旧・import後も変更計画を確認します。
C
構成ファイルに書かれたnameだけで、全providerが必ず既存資源を自動採用すると考える
表示名だけで自動採用されると一般化できません。providerのIDとstateの関連付けを確認します。
D
stateは画面の配色だけを保存するので、管理には関係しないと考える
stateは実在資源との対応や属性等を管理するための重要情報です。適切な保護・バックアップ・ロックも必要です。
解説
Terraformの宣言的構成とstateは別です。既存資源のIDとの対応を安全に回復し、復元・importが対象providerや構成に適合するかを確認してからapplyを判断します。
根拠資料・確認情報
対応範囲：LPIC3 305-300 v3.0
資料確認日：2026-10-28
同じレッスンの問題
問題 1
OpenStack上でVMを作る。認証はKeystone、イメージはGlance、ネットワークはNeutronが担当している。この構成で、compute instanceの作成・管理を担当する中心サービスはどれか。
問題 3
cloud-initの初回処理が成功したVMを、同じdatasource・instance-idのまま通常再起動する。cacheのcleanやモジュールの強制再実行は行わず、標準の実行頻度を変えていない。user-dataのruncmdが毎起動で実行されると期待してよいか。
問題 4
systemdを使うテンプレートVMから、cloud-init対応イメージを複製する。現在の/var/lib/cloudの実行済み状態とmachine-idをそのまま使い回したくない。対応する版のcloud-initにclean --machine-idがあり、次回起動用datasource等も準備できる。このテンプレートだけに行う準備として適切なのはどれか。