あなたは規制の厳しい金融会社の開発者で、Cloud Run で実行されているリスク計算アプリケーションのリードを務めています。組織ポリシーとして Cloud Run の Binary Authorization（バイナリ認証）が有効になっており、1 つの承認者（Attestor）が存在します。社内のすべてのアプリケーションは承認済みです。各アプリケーションのイメージは、現地時間午後 11 時の 1 時間の変更期間中に CI/CD パイプラインの一部としてデプロイされます。
次の変更期間を待たずに、重大な修正をデプロイする必要がある新しいセキュリティ問題が発生しました。修正済みの新しいイメージを作成し、マネージャーはメールでそのイメージを承認しました。あなたは何をすべきですか？
正解：D
Binary Authorization は非常に強力なガードレールですが、緊急時には通常の承認フロー（アテステーション）をスキップしてデプロイを強行できる 「ブレイクグラス（緊急時用強制デプロイ）」 という機能が用意されています。
なぜ D が正解なのか？
緊急対応への特化: 署名プロセスが間に合わない、あるいは通常の CI/CD パイプラインが利用できない緊急事態において、ポリシーを一時的に「バイパス」してデプロイするために設計された標準機能です。
監査（Auditability）の維持: ブレイクグラスを使用してデプロイすると、Cloud Audit Logs に「なぜ緊急デプロイを行ったか」という記録が残ります。金融業界のような規制の厳しい環境では、ポリシーを勝手に変える（C）よりも、ログを残して事後承認を得る方がコンプライアンス的に適切です。
運用の継続性: 他のイメージの認証ルールを壊すことなく、特定のデプロイだけを例外的に許可できます。
コメント