正解：B

解説： Dataflow は Apache Beam を実行するサーバーレスの処理サービスで、クラスタ管理が不要です。Beam は「Batch and Streaming Unified」を掲げており、同一コードでストリーミングとバッチの両方を記述できます。「途切れず届く（無界データ）」「サーバーレス」「バッチにも流用」という条件すべてに合致します。

• ❌ A：Dataproc はマネージドな Spark/Hadoop クラスタで、クラスタを意識する必要があります。「クラスタ管理を避けたい」「サーバーレス」という条件に反します（既存Spark資産の移行が主な用途）。
• ❌ C：Cloud Data Fusion は GUI でノーコードETLを組むツール。ここではコードでの記述・流用が前提で、ノーコード要件は無く最適とは言えません。
• ❌ D：BigQuery のスケジュールドクエリはバッチ的なELT向けで、途切れず届くストリームの低レイテンシ処理には向きません。

📖 関連：01_基礎.md の「Dataflow（Apache Beam）の役割」

正解：C

解説： Pub/Sub はグローバルなメッセージング基盤で、トピックとサブスクリプションを介して送受信を疎結合化します。急なトラフィック増加を吸収するバッファ、複数受信者へのファンアウトが主な役割で、ストリーミング取り込みの入口として定番です。

• ❌ A：Cloud Storage はオブジェクトストレージ（データレイク）。メッセージングの疎結合・バッファ役ではありません。
• ❌ B：Bigtable は低レイテンシの大規模NoSQL。シンク（参照ストア）であり、メッセージングのバッファではありません。
• ❌ D：Cloud SQL はリレーショナルDB（OLTP）。メッセージングのバッファ用途ではありません。

📖 関連：01_基礎.md の「Pub/Sub の役割」

正解：B

解説： Cloud Data Fusion は CDAP ベースのGUI（ノーコード/ローコード）ETLツールで、ドラッグ＆ドロップでパイプラインを構築できます。Wrangler でデータを見ながら対話的にクレンジング・整形でき、「コードを書きたくない/書けないチーム」に最適です。

• ❌ A：Dataflow は Java/Python/Go でコードを書く必要があり、「コードを書かない」要件に反します。
• ❌ C：Dataproc は Spark/Hadoop のコードを書いて実行するサービスで、ノーコード要件に反します。
• ❌ D：Cloud Composer はワークフローのオーケストレーター（DAGをPythonで定義）。ETLの変換ロジックをGUIで組むツールではありません。

📖 関連：01_基礎.md の「Cloud Data Fusion の役割」

正解：C

解説： Dataproc はマネージドな Spark / Hadoop クラスタで、OSSのビッグデータエコシステム（Spark, Hive, Pig 等）をそのまま動かせます。既存のSpark/Hadoopコード資産を書き換えずに移行したいケースの定番です。コスト最適化には ephemeral（一時）クラスタ＋GCS が定石です。

• ❌ A：Dataflow への書き換えは Apache Beam でのコードの作り直しが必要で、「書き換えずに」という要件に反します。
• ❌ B：Data Fusion での再構築も作り直しであり、既存資産の流用にはなりません。
• ❌ D：BigQuery への移植もSQLへの書き換えが必要で、Spark/Hadoop資産をそのまま動かすことにはなりません。

📖 関連：01_基礎.md の「Dataproc の役割」

正解：B

解説： 「直近5分」という重なりのある集計を「1分ごと」に更新するには、スライディングウィンドウを使い、window=5分（集計対象の幅）、period=1分（出力間隔）を指定します。移動平均・直近N分の傾向を出す典型パターンです。

• ❌ A：固定ウィンドウ幅5分では、5分ごとに重ならず区切られるため「1分ごとに更新」できません（出力は5分に1回）。
• ❌ C：セッションウィンドウは無活動の途切れ（gap）でまとまりを区切るもので、定期的な移動平均には不向きです。
• ❌ D：グローバルウィンドウはストリーム全体を1つの窓とみなし、定期的な時間集計には適しません（カスタムトリガー必須）。

📖 関連：01_基礎.md の「ストリーミングのウィンドウ処理」

正解：C

解説： 「一定時間（30分）アクティビティが無ければ区切る」のはセッションウィンドウの定義そのものです。gap（ギャップ）=30分を指定すると、操作が途切れてから30分経過したところでセッションが閉じます。ウィンドウ幅は操作の連続性に応じて可変になります。

• ❌ A／D：固定ウィンドウは一定幅で機械的に区切るため、ユーザーごとの操作の途切れに合わせた区切りができません。
• ❌ B：スライディングウィンドウは重なりのある定期集計（移動平均など）向けで、無活動による区切りを表現できません。

📖 関連：02_応用.md の「ウィンドウ選択の判断」

正解：B

解説： 順序の乱れや遅延がある中で正しく時間集計するには、イベント時刻（データが実際に発生した時刻）を基準にするのが原則です。ウォーターマークが「この時刻までのデータは出揃った」という境界を示し、ウィンドウ集計の確定タイミングを制御します。これによりネットワーク遅延に左右されない集計ができます。

• ❌ A：処理時刻を基準にすると、遅延や順序逆転がそのまま結果を歪めます。発生時刻ベースの正確な集計になりません。
• ❌ C：到着順のまま集計するのは処理時刻基準と同様の問題があり、順不同データで結果が崩れます。
• ❌ D：翌日バッチにすると遅延・順序の問題は緩和できますが、ストリーミングのリアルタイム性を失います。要件は「正しく集計したい」であり、リアルタイム処理を捨てる必要はありません。

📖 関連：01_基礎.md の「ウォーターマークと遅延到着データ」

正解：B

解説： Pub/Sub は既定で at-least-once（重複あり得る）です。Dataflow は内部でチェックポイントと重複排除を行い、Pub/Sub の重複を吸収して Exactly-once を実現します。BigQuery への書き込みは Storage Write API を使うと Exactly-once セマンティクスが得られ、パイプライン全体で「ちょうど1回」を担保できます。

• ❌ A：at-most-once は欠損（漏れ）が起き得るため、「漏れなく」の要件を満たせません。
• ❌ C：SELECT DISTINCT はクエリ時の対症療法でコストもかかり、ストリーミングの取り込み段階で重複を防ぐ正攻法ではありません。
• ❌ D：リトライを止めるとメッセージの欠損につながり、「漏れなく」を満たせません。

📖 関連：02_応用.md の「Exactly-once の実現」

正解：C

解説： デッドレタートピック（DLQ）は、規定の配信試行回数を超えても処理できなかったメッセージを別トピックへ退避する機能です。詰まりの原因となるメッセージを隔離することで、健全なメッセージの処理を継続でき、パイプライン停止を防げます。退避したメッセージは後で個別に調査・再処理します。

• ❌ A：シークは過去の時刻/スナップショットへ再生位置を戻す機能で、再処理に使うもの。失敗メッセージの隔離用途ではありません。
• ❌ B：順序指定キーは同一キー内の順序保証の機能で、失敗メッセージの切り離しとは無関係です。
• ❌ D：フィルタは属性に基づき配信するメッセージを絞り込む機能で、処理失敗メッセージの自動隔離はできません。

📖 関連：02_応用.md の「Pub/Sub の重要機能」

正解：B

解説： シーク（Seek）は、サブスクリプションの再生位置を過去のタイムスタンプやスナップショットへ巻き戻す機能です。これにより、確認応答（ack）済みのメッセージでも保持期間内であれば再配信させ、バグ修正後の再処理が可能になります。前提としてメッセージ保持が必要です。

• ❌ A：デッドレタートピックは失敗メッセージの隔離であり、過去メッセージ全体の巻き戻し再処理はできません。
• ❌ C：プッシュ/プルの配信方式の変更は再処理とは無関係です。
• ❌ D：順序指定キーは順序保証の機能で、再処理位置の巻き戻しとは関係ありません。

📖 関連：02_応用.md の「Pub/Sub の重要機能（シーク）」

正解：C

解説： Cloud Composer はマネージドな Apache Airflow で、**DAG（有向非巡回グラフ）**として複雑な依存関係・分岐・リトライ・スケジュールをPythonコードで定義できます。豊富なOperatorでGCPサービスを呼べ、既存のAirflow DAG資産をそのまま活用できます。「複雑な依存・多数のデータジョブ」の定番です。

• ❌ A：Cloud Scheduler は cron による起動トリガーにすぎず、ジョブ間の依存関係の管理はできません。
• ❌ B：Workflows はYAML/JSONで定義する軽量なAPI/サービス連携向け。複雑な依存・Airflow資産活用の要件には Composer が適します。
• ❌ D：Pub/Sub は依存関係を持つワークフローのオーケストレーターではありません。

📖 関連：02_応用.md の「Cloud Composer vs Workflows」

正解：B

解説： Workflows はサーバーレスなAPI/サービスのオーケストレーションで、YAML/JSONでステップを定義します。HTTP/API・Cloud Functions・Cloud Run の順次/分岐実行に向き、インフラ管理不要・実行課金で低コストです。「軽量・複雑なDAG不要」の連携に最適です。

• ❌ A：Cloud Composer は常時稼働のAirflow環境でコストが継続的に発生し、軽量・低コスト要件にはオーバースペックです。
• ❌ C：Dataproc Workflow Templates は Spark/Hadoop ジョブのワークフロー用で、汎用的なAPI連携の用途ではありません。
• ❌ D：常時稼働GCE上のスクリプトはインフラ管理が発生し、「管理せず・低コスト」の要件に反します。

📖 関連：02_応用.md の「Cloud Composer vs Workflows」

正解：B

解説： Dataflow ワーカーの**外部IPを無効化（--no_use_public_ips）し、サブネットで限定公開のGoogleアクセス（Private Google Access）**を有効にすると、外部IPなしで内部から Google API へ到達できます。これが攻撃面を縮小するセキュアな基本形で、必要に応じて VPC Service Controls を併用します。

• ❌ A：外部IPを付与する構成は攻撃面を広げ、「外部IPを持たせない」要件に真っ向から反します。
• ❌ C：公衆インターネット経由は最もセキュアでない選択で、要件に反します。
• ❌ D：ローカルRunnerは開発用途であり、本番のセキュアなネットワーク構成の話とは別物です。

📖 関連：02_応用.md の「ネットワーキングのベストプラクティス」

正解：B

解説： Pub/Sub Lite はゾーン/リージョン単位で、スループットとストレージのキャパシティを事前に手動予約する代わりに、標準のPub/Subより大幅に低コストです。「コスト最優先・スループット予測可能・ゾーン単位で許容・キャパシティ計画OK」という条件に合致します。

• ❌ A：標準のPub/Subはグローバル・自動プロビジョニングで運用は楽ですが、コスト最優先の要件では Lite が優位です。
• ❌ C：Cloud Tasks はタスクキュー（非同期タスクの実行管理）で、大規模ストリーミング取り込みの基盤ではありません。
• ❌ D：BigQuery ストリーミングはメッセージング基盤ではなく、BigQueryへの行の挿入手段であり、要件の対比対象ではありません。

📖 関連：02_応用.md の「Pub/Sub vs Pub/Sub Lite」

正解：B

解説： Streaming Engine はストリーミングジョブのウィンドウ状態の保持をサービス側へオフロードし、ワーカーを軽量化します。状態をワーカーから切り離すことで、オートスケールが高速・滑らかになり、ワーカーの障害やスケール変更に強くなります。今回の「オートスケール追従が遅い・状態管理で不安定」という症状の直接の対策です。

• ❌ A：Dataflow Shuffle はバッチのシャッフル（GroupBy/Join）をサービス側で実行する機能で、ストリーミングのオートスケール改善が目的ではありません（対象が異なる典型ひっかけ）。
• ❌ C：FlexRS はバッチを低コストで実行する遅延スケジューリングで、ストリーミングの安定性とは別物です。
• ❌ D：ディスク拡張は状態をワーカーから切り離す根本対策にならず、オートスケールの追従改善にもつながりません。

📖 関連：02_応用.md の「Dataflow Shuffle と Streaming Engine」

正解：A・B

解説： 「途中経過を早く出す」には、ウォーターマーク到達前に発火する早期発火（early firing）を含む複合トリガーを使います（A）。「遅れて届いたデータも反映」するには、**許容遅延（allowed lateness）**を設定し、**累積モード（accumulating）**で結果を再計算・更新します（B）。この2つの組み合わせが「早期結果＋遅延更新」の定石です。

• ❌ C：処理時刻基準にすると、遅延・順序逆転で集計が歪みます。正しく扱うのはイベント時刻＋ウォーターマークであり逆効果です。
• ❌ D：グローバルウィンドウ化＋トリガー無効化では、時間単位の途中経過・更新という要件を満たせません。
• ❌ E：ウォーターマークを無効化すると「いつ確定するか/何が遅延か」の判断ができず、遅延データの扱いが破綻します。

📖 関連：01_基礎.md の「トリガー」「ウォーターマークと遅延到着データ」

正解：A・B

解説： 「同一ユーザーのイベントの順序保持」には順序指定キー（Ordering Key）を使います。キー単位で順序が保証されます（A）。「壊れたメッセージで止めない」には、規定回数失敗したメッセージを退避するデッドレタートピックを使い、健全な処理を継続します（B）。

• ❌ C：シークは過去への巻き戻し再処理であり、今回の順序保持・失敗隔離とは目的が異なります。
• ❌ D：順序指定キーはキーごとの順序であり、Pub/Sub は「全メッセージのグローバルな全順序」を目的とした機能を提供しません。要件も「同一ユーザーだけ」であり全順序は不要です。
• ❌ E：メッセージ保持の無効化はむしろ再処理（シーク）を不可能にし、要件解決に寄与しません。

📖 関連：02_応用.md の「Pub/Sub の重要機能」

正解：A・B

解説： CI/CD の中核は Cloud Build。Gitへの push/PR でトリガーし、cloudbuild.yaml に従ってテスト→ビルド→デプロイを自動化、dev→staging→prod へテスト通過分だけ昇格します（A）。Composer は DAG を Cloud Build から GCS の dags/ フォルダへ自動配置するのがベストプラクティスです（B）。Dataflow は Flex テンプレートをビルドして Artifact Registry に登録し、環境ごとにパラメータ実行します。

• ❌ C：本番直接編集は再現性・テスト・レビューを欠き、CI/CDの原則に反します。
• ❌ D：ローカルからの手動デプロイは自動化・再現性の要件を満たしません。
• ❌ E：環境を分けない単一prodへの直接デプロイは、段階的な検証・昇格（dev→staging→prod）の要件に反します。

📖 関連：02_応用.md の「CI/CD の設計（Cloud Build）」、01_基礎.md の「CI/CD」