【正解】B
【0からの解説】
① 前提知識・
Terraform はインフラストラクチャをコードで定義するツール（IaC）です。
terraform plan は「どのリソースがどう変わるか」という変更内容をプレビューするだけのコマンド、
terraform apply は実際に変更を適用するコマンドです。
・
Cloud Build は Google Cloud のマネージド CI/CD サービスです。Git リポジトリのプル リクエストやブランチへの push をきっかけに
トリガーでビルドを起動できます。トリガーには「
承認を必須にする」設定があり、承認者（Cloud Build 承認者ロール roles/cloudbuild.builds.approver を持つユーザー）が承認するまでビルドの実行を保留できます。
・
サービス アカウントの権限借用（impersonation）: あるプリンシパル（ここでは Cloud Build のサービス アカウント）が、別のサービス アカウントの
有効期間の短いアクセス トークンを発行して、そのサービス アカウントとして操作する仕組みです。キー ファイルを作成・保管する必要がなく、Terraform の google プロバイダでも impersonate_service_account として使えます。
② 要件と制約語の整理・
有効期間の長い静的なサービス アカウント キーの禁止 → キーレスの認証が必要。
・開発者は
変更を提案（ピアレビュー）できるが、
本番に直接適用する権限を持たない → 適用はパイプラインだけが行い、職務分離を徹底する。
・
安全で自動化され、
適切なガバナンスが確保されていること → 人手による操作ではなく自動化しつつ、適用前に統制ポイントを設ける。
③ 正解 B が要件をどう満たすか・Cloud Build は自身のサービス アカウントで実行され、本番プロジェクトへの権限を持つデプロイ用サービス アカウントを
権限借用して短期トークンで Terraform を実行します。静的キーは一切存在しません。
・プル リクエスト時に
terraform plan を自動実行し、その結果をレビュアーが確認できるようにすることで、ピアレビューの質が上がります。
・
terraform apply の前に
手動承認を必須にすることで、権限のある承認者が確認するまで本番への変更は適用されません。開発者には本番プロジェクトの IAM 権限も承認者ロールも付与しないため、開発者が自分で本番に変更を適用することはできません。Google が推奨する Terraform・Cloud Build・GitOps によるインフラ管理の考え方に、承認ゲートによるガバナンスを加えた構成です。
【誤りの選択肢】
A：権限借用によってキーレスにしている点は正しいものの、マージと同時に terraform apply が自動実行されるため、本番適用の前に明示的な統制ポイントがありません。マージできる開発者は実質的に本番への変更を適用できることになり、plan の結果を確認せずにマージされる危険もあります。B の承認ゲートと比べてガバナンスが弱くなります。
C：本番適用が人手に戻るため「自動化されたワークフロー」の要件に反します。さらに、apply を実行する開発者に本番への権限を与えることになり、「開発者は本番に直接適用する権限を持たない」というルールと矛盾します。ワークステーションごとの環境差異や認証情報の管理、操作の追跡性の面でも、パイプラインによる一元的な適用より劣ります。
D：JSON キーを Secret Manager に保存しても、有効期間の長い静的なサービス アカウント キーを使うことに変わりはなく、セキュリティ チームの禁止事項に正面から違反します。キーの漏えいやローテーション管理のリスクも残ります。
【参考】
Terraform、Cloud Build、GitOps を使用してインフラストラクチャをコードとして管理するサービス アカウントの権限借用 | Identity and Access Management (IAM)ビルドトリガーの作成と管理 | Cloud Build