SOAデプロイ、プロビジョニング、および自動化
5人の開発者がTerraformを使用してAWSインフラを共同管理しています。各自がローカルPCでtfstateファイル（Terraformがリソース管理状態を記録するファイル）を管理していたため、複数人が同時に`terraform apply`を実行してstateファイルが破損するインシデントが発生しました。このような問題を防ぐために最も適切なリモートバックエンド構成はどれですか？
AS3バケットをバックエンドとして設定し、S3オブジェクトロック（Object Lock：WORM方式でオブジェクトの上書き・削除を防ぐ機能）を有効にしてstateファイルの上書きを防ぐ
S3 Object Lock（WORM）はコンプライアンス目的の削除防止機能ですが、正常なterraform applyによるstateファイル更新も拒否してしまい、Terraformのlocking機能に使用不可。
BS3バケットをstateファイルの保存先として設定し、DynamoDBテーブルをstateロック（State Locking：同時実行を防ぐための排他制御）に使用するリモートバックエンドを構成する
✓ 正解
S3をstate保存先、DynamoDBをState Locking用として設定する標準構成。terraform apply実行時にDynamoDBロック記録が書き込まれ、同時実行防止してstate破損を防げます。
CS3バケットのバージョニング（Versioning）のみを有効にし、競合が発生した場合に以前のバージョンにロールバックできるようにする
S3バージョニングのみでは同時実行防止にはならず、state破損発生後の復旧用リアクティブ対策に過ぎません。並行apply実行の排他制御メカニズムは実現不可。
DAWS CodeCommitにtfstateファイルをコミットし、プルリクエスト（Pull Request）の承認フローで同時変更を防ぐ
AWS CodeCommit管理はシークレット情報露出リスクあり非推奨。プルリクエスト承認フローは非同期レビュー仕組みで、同時apply防止の排他制御メカニズムにはなりません。
解説
TerraformのS3バックエンドは、S3でstateファイルを共有しDynamoDBでState Lockingを実装する標準的な構成です。`terraform apply`実行時にDynamoDBにロックレコードが書き込まれ、他の開発者が同時にapplyしようとするとロック取得に失敗して処理が停止するため、stateファイルの破損を防げます。
選択肢AのS3オブジェクトロックは、コンプライアンス目的のWORM（Write Once Read Many）機能であり、正常なapplyによるstateファイルの更新も拒否してしまうためTerraformのlockingには使用できません。
選択肢CのS3バージョニングのみでは、同時実行の防止にはならず、破損が発生してから以前の状態に戻すリアクティブな対策に過ぎません。
選択肢DのAWS CodeCommitでのtfstate管理は、シークレット情報が含まれるリスクがあり非推奨です。プルリクエストの承認フローは非同期的なレビューの仕組みであり、同時apply防止の排他制御にはなりません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSOAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →