【正解】C
【0からの解説】
①前提知識・
Dataflow の Pub/Sub 読み取り：Dataflow のパイプラインが Pub/Sub の
トピックを指定して読み取る場合、コネクタはパイプラインごとに専用の一時サブスクリプションを作成します。そのため、旧バージョンと新バージョンのジョブが同時に動いていると、それぞれがすべてのメッセージを受け取り、同じデータを 2 回書き込むことになります。新バージョンを「更新（update）」ではなく別ジョブとして起動し、旧ジョブを停止（ドレイン）し忘れると、このような二重書き込みが起こります。
・
Cloud Audit Logs（監査ログ）：誰が・どのジョブが・いつ BigQuery のテーブルに書き込んだかなどの操作を記録します。テーブルへの書き込み元のジョブや呼び出し元を特定するのに使えます。
・
Cloud Monitoring：Dataflow ジョブの指標（開始時刻、スループット、要素数など）を確認でき、どのジョブがいつから動いているかを把握できます。
・
パイプラインの停止：ストリーミング ジョブは「ドレイン」で停止すると、取り込み済みのデータを処理し終えてから停止するため、データを失わずに止められます。
②要件と制約の整理(1) 新しいパイプラインのデプロイ後に保存量が 50% 増えた。
(2)
Pub/Sub の入力量は変わっていないのに、
一部のテーブルだけ日次パーティションが
ちょうど 2 倍になった。
(3) 求められているのは
原因の調査と修正。
→ 入力が同じで出力がちょうど 2 倍なので、同じメッセージがそのテーブルに 2 回書き込まれている、つまり旧バージョンと新バージョンのパイプラインが並行して同じテーブルに書き込んでいる可能性が高いと推測できます。
③正解（C）が要件を満たす理由C は、まず影響テーブルの重複行を確認して「二重書き込み」という仮説を検証し、次に BigQuery の監査ログから書き込んでいるジョブ ID を特定し、Cloud Monitoring でそれらの Dataflow ジョブの開始時刻とコード バージョンを突き合わせて、同じテーブルに複数バージョンのパイプラインが書き込んでいることを確かめます。最後に最新バージョン以外を停止することで、原因そのもの（停止し忘れた旧パイプライン）を取り除きます。証拠に基づいて根本原因を特定し、再発しない形で修正する手順になっており、(3) の「調査して修正する」に最も合致します。
【誤りの選択肢】
A：重複行の確認は良いのですが、その後は毎日重複排除の SQL を実行するという対症療法に終わり、旧パイプラインが動き続けるため重複データは毎日発生し続けます。重複排除クエリの料金と運用の手間も増え、原因の修正になっていません。
B：二重稼働しているパイプラインはエラーを出さないため、コードエラーや Cloud Logging のエラーを探しても原因が見つからない可能性が高いです。そのうえ「エラーがなければ」タイムトラベルでリリース前の状態に戻すと、リリース後に取り込んだ正当なデータまで失われます。原因のパイプラインも止めていないため、重複は再び発生します。
D：原因を調査せずにロールバックしており、「調査して修正する」要件を満たしません。ロールバックしても並行して動いている旧ジョブが残っていれば問題は解決しません。また、タイムトラベルの期間は最大 7 日で、シークによる再生にはメッセージの保持設定が必要なため、確実に元に戻せるとは限らず、作業のリスクと手間が大きくなります。
【参考】
Pub/Sub から Dataflow に読み取るCloud Audit Logs の概要 | Cloud Logging実行中の Dataflow パイプラインを停止する