【正解】B
【0からの解説】
①前提知識
Terraform は、管理しているリソースの実際の状態を「状態ファイル（terraform.tfstate）」に記録し、構成ファイルとの差分から変更を計画・適用します。状態ファイルにはリソースの属性がそのまま記録されるため、パスワードなどの機密性の高い値が平文で含まれることがあります。状態の保存場所を決めるのが「バックエンド」で、既定のローカル バックエンドでは作業者の PC に状態ファイルが保存されます。
Google Cloud では、gcs バックエンド（Cloud Storage バックエンド）で状態ファイルを Cloud Storage バケットに保存することが推奨されています。gcs バックエンドは状態のロック（同時に 2 人が apply して状態が壊れるのを防ぐ）に対応し、バケットの IAM でアクセスを制御でき、オブジェクトのバージョニングで過去の状態に戻すこともできます。
②要件の整理
・複数人が同時に作業しても競合しない（状態の共有とロック）
・機密性の高い値をローカルマシンに永続化しない
③正解の理由
Cloud Storage バックエンドを使うと、状態ファイルはチーム全員が共有する 1 か所（バケット）に保存され、実行中はロックがかかるため同時実行による破損を防げます。状態ファイルはローカルのディスクに保存されないため、機密値が各自のマシンに残りません。Google Cloud の Terraform ベスト プラクティスでも、リモート状態として Cloud Storage を使うこと、状態ファイルを Git にコミットしないことが推奨されています。
【誤りの選択肢】
A：踏み台サーバーの共有アカウントで実行すると、誰が変更したかの追跡（監査）ができなくなり、セキュリティのベスト プラクティスに反します。状態ファイルは踏み台サーバーのローカル ディスクに永続化されたままで、同時に作業した場合のロックもありません。
C：状態ファイルを Git リポジトリに保存すると、機密値がリポジトリの履歴に残り、各自がクローンしたローカルマシンにも複製されます。Git はロックの仕組みを提供しないため、同時実行の競合も防げません。Google のベスト プラクティスでも状態ファイルを Git にコミットしないことが推奨されています。
D：手動で状態ファイルを受け渡す方法は、最新版の取り違えや同時変更による状態の不整合を防げず、機密値も各メンバーのローカルマシンに保存されます。運用負荷も大きく、要件のいずれも満たしません。
【参考】
Terraform の状態を Cloud Storage バケットに保存するTerraform の操作に関するベスト プラクティス