LPIC-3 仮想化・コンテナ化クラウド管理とcloud-initオリジナル・公式資料照合難易度★★★★☆
systemdを使うテンプレートVMから、cloud-init対応イメージを複製する。現在の/var/lib/cloudの実行済み状態とmachine-idをそのまま使い回したくない。対応する版のcloud-initにclean --machine-idがあり、次回起動用datasource等も準備できる。このテンプレートだけに行う準備として適切なのはどれか。
A
実行済み状態とmachine-idを固定してコピーし、全複製を同一インスタンスとして扱わせる
初回処理が省略されたり同一machine-idを引き継いだりする原因になります。個体ごとの初期化を設計します。
B
/var/lib/cloudだけを読み取り専用にすれば、固有IDは自動的にすべて異なる
読み取り専用化は状態の初期化ではなく、初回処理に必要な更新を妨げる場合もあります。
C
cloud-initのログを読むだけで、実行済み状態は自動削除される
ログの読取りは状態を変更しません。cache・instance判定・machine-idの準備は別の操作です。
D
cloud-init clean --machine-id等で実行状態と固有IDの初期化を準備し、不要な再起動をせずimage化して、複製先の初回処理を検証する★ 正解
cleanでcloud-initの状態を初期化し、--machine-idで次回の固有ID生成を準備できます。複製後のdatasourceと動作確認も必要です。
解説
cloud-initのcacheとsystemdのmachine-idを区別してテンプレートを準備します。cleanは本番個体へ無条件に実行する処理ではなく、SSH host keyや秘密情報、datasource等のimage化準備をすべて自動保証するものでもありません。
根拠資料・確認情報
対応範囲：LPIC3 305-300 v3.0
資料確認日：2026-10-28
同じレッスンの問題
問題 1
OpenStack上でVMを作る。認証はKeystone、イメージはGlance、ネットワークはNeutronが担当している。この構成で、compute instanceの作成・管理を担当する中心サービスはどれか。
問題 2
Terraformで作成したクラウド資源は実在しているが、管理用stateを失った。構成は同じでもplanが新規作成を提案する。既存資源を誤って二重作成しないための適切な対応はどれか。
問題 3
cloud-initの初回処理が成功したVMを、同じdatasource・instance-idのまま通常再起動する。cacheのcleanやモジュールの強制再実行は行わず、標準の実行頻度を変えていない。user-dataのruncmdが毎起動で実行されると期待してよいか。