正解：C

解説： IAM のベストプラクティスは「最小権限の原則」と「個人ではなく Google グループへ付与」の組み合わせ。グループに事前定義ロールを付与すれば、異動・入退社時はグループのメンバー変更だけで権限管理が完結し、付与漏れ・剥奪漏れを防げます。

• ❌ A：基本ロール（オーナー/編集者/閲覧者）は権限が広すぎ、本番では非推奨。最小権限に反する。
• ❌ B：個人へ直接付与すると人数分の管理が発生し、退職・異動時の剥奪漏れが起きやすい。グループ付与が推奨。
• ❌ D：サービスアカウント鍵ファイルの配布は鍵漏洩リスクが高く、そもそも人間の操作には使わない。鍵配布は避け Workload Identity 連携が推奨。

📖 関連：01_基礎.md の「1.1 ① IAM」／02_応用.md の「IAM 設計のベストプラクティス」

正解：B

解説： これは試験頻出パターンです。IAM は「誰が・何を」できるかを制御しますが、正規権限を持つ主体や漏洩した認証情報による持ち出しは防げません。VPC Service Controls はサービス境界（perimeter）を作り、境界外（許可していない VPC やインターネット）へのデータ移動そのものをブロックするため、認証情報漏洩・内部不正による持ち出しに直接対応できます。

• ❌ A：CMEK は鍵管理を顧客が制御する暗号化。保存データの保護であり、正規アクセスによる持ち出し経路は塞げない。
• ❌ C：カスタムロールも IAM の枠内であり、権限の粒度を変えるだけ。漏洩した認証情報の持ち出しは防げない。
• ❌ D：DLP は PII のマスキング/トークン化。データの中身の機密度を下げるが、データ持ち出しの境界制御ではない。

📖 関連：02_応用.md の「VPC Service Controls」（⚠️試験頻出）

正解：C

解説： CSEK（Customer-Supplied Encryption Key／顧客提供暗号鍵） は、顧客が自分で生成・保持する鍵を持ち込み、鍵を Google Cloud に保管させない方式。「鍵を GCP に一切預けない厳格な要件」というキーワードは CSEK を指します。

• ❌ A：デフォルト暗号化は Google が鍵を管理するため、「鍵を預けない」要件に反する。
• ❌ B：CMEK は顧客が鍵を制御できるが、鍵は Cloud KMS（GCP 内） に保管される。「GCP に一切預けない」要件は満たせない。CMEK と CSEK の違いを突くひっかけ。
• ❌ D：独自暗号化はマネージドな鍵管理を放棄する運用負荷の高い実装で、Google が用意した正解の型ではない。要件は持ち込み鍵方式（CSEK）で満たせる。

📖 関連：03_要点と暗記.md の「暗号化の3方式」／02_応用.md の「CMEK vs CSEK」

正解：B

解説： 2つの要件を別々のサービスに割り当てる典型的な設計問題です。①「生 PII を保存しない」→ 取り込み時に Cloud DLP でトークン化/マスキングしてから格納。②「アナリストに集計だけ見せ、元テーブルへの直接権限を与えない」→ 承認済みビュー（Authorized View）。承認済みビューは、元テーブルへの直接アクセス権を与えずにビューの結果だけを参照させられます（必要なら列レベルのポリシータグも併用）。

• ❌ A：生データをそのまま保存しており「生 PII を保存しない」要件に反する。閲覧者ロールでもテーブル内容（PII）は見えてしまう。
• ❌ C：CMEK の鍵を渡さなくても、テーブルへの読み取り権限があれば BigQuery は自動復号して内容を返す。CMEK はアナリストからの列マスキング手段ではない。
• ❌ D：生データのコピーは PII を複製して拡散させるだけで、両要件のどちらも満たさない。

📖 関連：02_応用.md の「PII 保護の設計パターン」（承認済みビュー＋列レベルセキュリティ）

正解：A

解説： BigQuery のデータセットはロケーションが作成後に変更できません。そのため、データ主権要件がある場合は設計段階で EU リージョン/マルチリージョンを確定させる必要があります。これは試験頻出の「後戻りできないロケーション選定」のひっかけです。

• ❌ B：データセットのロケーションは後から変更不可。誤った認識を突く誤答。
• ❌ C：データ主権はまさに「データの保存・処理ロケーション」の問題。ネットワーク設定とは別軸。
• ❌ D：テーブルは所属するデータセットのロケーションに従う。データセット単位でロケーションが決まるため、データセットのロケーション選定が本質。

📖 関連：01_基礎.md の「1.1 ⑤ リージョン考慮（データ主権）」

正解：B

解説： 「グローバル分散 ＋ 強整合 ＋ 水平スケール ＋ ACID トランザクション」という組み合わせは、ほぼ Cloud Spanner 一択です。Spanner はグローバルに分散しながら強整合なトランザクションと無停止スケールを両立する唯一のサービスです。

• ❌ A：Bigtable は超低レイテンシ・大量書き込み向けだが結果整合性寄りで、複数行にまたがる ACID トランザクションには不向き。
• ❌ C：Firestore はドキュメント型でモバイル同期に強いが、グローバル規模の高スループット決済トランザクション基盤の主役ではない。
• ❌ D：Cloud SQL は強整合な RDB だが単一リージョン中心で、グローバル規模の水平スケール要件を満たさない。HA 構成でも対象はリージョン内の可用性。

📖 関連：02_応用.md の「ストレージの ACID/整合性選定」／03_要点と暗記.md の「整合性とストレージ」

正解：C

解説： 「ペタバイト級の時系列・毎秒数百万件の書き込み・ミリ秒読み取り・結果整合性で可」という条件は Cloud Bigtable の典型的なユースケースです。高スループットの大量書き込みと低レイテンシ読み取りに最適化された NoSQL ワイドカラムストアです。

• ❌ A：Spanner は強整合・グローバル分散が必要な場合に選ぶ。ここでは強整合不要で、コスト・スループット面で Bigtable が適切。
• ❌ B：Cloud SQL は汎用 RDB で、毎秒数百万件規模の書き込みスループットには向かない。
• ❌ D：BigQuery は分析（OLAP）向け DWH。ストリーミング挿入は可能だが、ミリ秒の個別キー読み取りや超高スループットの運用系ワークロードには Bigtable が適する。

📖 関連：02_応用.md の「ストレージの ACID/整合性選定」（⚠️「ペタバイト級の時系列、ミリ秒読み取り」→ Bigtable）

正解：A

解説： 「DB そのものを移す ＋ ダウンタイム最小化 ＋ 継続レプリケーション」は Database Migration Service（DMS） の典型ユースケースです。DMS は MySQL/PostgreSQL などを Cloud SQL/AlloyDB へ移行し、継続レプリケーションで差分を反映してカットオーバー時のダウンタイムを最小化します。

• ❌ B：BigQuery Data Transfer Service は他 DWH/SaaS から BigQuery への定期取り込み用。Cloud SQL への DB 移行ではない。
• ❌ C：Transfer Appliance は数十 TB〜PB のオフライン物理転送用。継続的な DB レプリケーション移行の手段ではない。
• ❌ D：Storage Transfer Service は S3/オンプレのファイルを GCS へ転送するサービス。DB 移行ではない。

📖 関連：01_基礎.md の「1.4 ② 移行サービスの使い分け」／02_応用.md の「移行サービス選定（決定木）」

正解：A

解説： Datastream はサーバーレスの CDC（Change Data Capture） サービスで、ソース DB の変更を継続的にキャプチャして BigQuery や Cloud Storage へリアルタイムに近い形で複製します。「DB の変更を継続的に流す」というキーワードは Datastream を指します。

• ❌ B：Cloud Composer はマネージド Airflow で、パイプラインのオーケストレーション（依存関係に沿った実行・スケジューリング）を担う。CDC レプリケーション自体は行わない。
• ❌ C：Transfer Appliance は一度きりの巨大データのオフライン物理転送用で、継続的な変更複製には使わない。
• ❌ D：Dataform は BigQuery 内の SQL 変換（ELT） をバージョン管理・テストするツール。ソース DB からの CDC 複製ではない。

📖 関連：01_基礎.md の「1.4 ② 移行サービスの使い分け」（Datastream）

正解：C

解説： 「数十 TB〜PB 級 ＋ ネットワーク帯域が限られ、オンライン転送が非現実的」という条件は Transfer Appliance の典型ユースケースです。物理アプライアンスにデータを書き込んで Google へ返送し、オフラインで GCS に取り込みます。800 TB を限られた帯域で送る本問はこれに該当します。

• ❌ A：Storage Transfer Service はオンライン転送が現実的な場合に有効。帯域が限られ数か月かかる本問では不適。
• ❌ B：gsutil/gcloud storage の並列アップロードもネットワーク依存で、帯域不足の根本問題を解決しない。
• ❌ D：Datastream は DB の継続的 CDC 用。800 TB の一括履歴移行の手段ではない。

📖 関連：03_要点と暗記.md の Q5（Transfer Appliance）／ひっかけ「大量データを通常のネットワークで転送 → Transfer Appliance」

正解：A・C

解説： 「データを移動・コピーせずマルチクラウドで分析」は BigQuery Omni と BigLake が答えです。BigQuery Omni は AWS S3/Azure 上のデータを移動させずその場で分析でき、越境やデータ移動コストを回避します。BigLake はオープンフォーマット（Parquet/Iceberg）でストレージとコンピュートを分離し、ロックインを軽減しつつ外部データを統一的に扱えます。

• ❌ B：Cloud SQL のクロスリージョンレプリカは DB の可用性/DR 向けで、S3 データを移動せず分析する話とは無関係。
• ❌ D：S3 を GCS へコピーするのは「データを移動・コピーしない」要件に真っ向から反する。
• ❌ E：毎晩のバッチコピーもデータ複製であり、転送コスト・越境を避ける要件に反する。

📖 関連：02_応用.md の「マルチクラウド戦略」（⚠️「データをコピーせずマルチクラウドで分析」→ BigQuery Omni / BigLake）

正解：A・B

解説： ①データ検証は Dataform のアサーションで NULL/一意性/参照整合性を宣言的にテストできます。②不正レコードで処理を止めないためには デッドレターキュー（DLQ） を設け、処理できないレコードを隔離して本流の処理を継続させます。この2つはデータ品質設計の定番です。

• ❌ C：CMEK は暗号化（データ保護）であり、データ検証や不正レコード隔離とは無関係。
• ❌ D：タイムトラベルは論理破損からの復旧（DR/リカバリ）に有効だが、取り込み時のデータ検証や不正レコードの隔離手段ではない。なお BigQuery のタイムトラベルは既定 7 日で、本問の目的とは別軸。
• ❌ E：基本ロールの全員付与は最小権限に反するアンチパターンで、信頼性向上とは無関係。

📖 関連：01_基礎.md の「1.2 ⑤ データ検証」／02_応用.md の「データ検証の作り込み」

正解：A

解説： Dataplex はデータレイク/ウェアハウスを横断する統合データ管理サービスで、ドメイン（レイク/ゾーン）を定義して品質・セキュリティを横断適用します。Dataplex Catalog はメタデータカタログとして「どこに・何のデータがあるか」を検索・発見・タグ付けでき、シャドーデータの削減に有効です。

• ❌ B：Cloud Monitoring はメトリクス監視（可観測性）であり、データカタログ/ガバナンスではない。
• ❌ C：Cloud KMS は暗号鍵の管理。データの発見・カタログ化とは無関係。
• ❌ D：Cloud Composer はパイプラインのオーケストレーション（Airflow）。データ資産の検索・発見が役割ではない。

📖 関連：01_基礎.md の「1.3 ③ ステージング・カタログ化・ディスカバリ」／02_応用.md の「ガバナンスの設計」

正解：B

解説： 「RPO/RTO ほぼゼロ ＋ グローバル ＋ トランザクション RDB」という要件には、Cloud Spanner のマルチリージョン構成が適します。Spanner マルチリージョンは複数リージョンに同期レプリケーションし、リージョン障害時もデータ損失をほぼゼロに保ったまま可用性を維持します（応用資料でも RPO/RTO 厳しい場合の構成例として挙げられています）。

• ❌ A：1 日 1 回のエクスポートでは最大 1 日分のデータ損失が発生し、RPO ほぼゼロを満たさない。コスト優先・RPO 数時間許容のケース向け。
• ❌ C：Bigtable 単一クラスタはリージョン/ゾーン障害に弱く、強整合なトランザクション RDB 要件にも合わない。
• ❌ D：タイムトラベルは論理破損からの復旧手段であり、リージョン障害時の RPO/RTO ゼロを保証する仕組みではない。また BigQuery は分析用途で本問の RDB トランザクション要件と別軸。

📖 関連：02_応用.md の「DR 戦略（RPO/RTO で構成を変える）」

正解：A

解説： これは複数要件を各サービスへ割り当てる統合シナリオ（本番の設計問題そのもの）です。正しい割り当ては——②データ主権：EU ロケーションに固定したデータセットを分離し、組織ポリシーで誤配置を防止、③PII 非開示：取り込み時に DLP でトークン化＋承認済みビュー経由でアクセス、④持ち出し防止：VPC Service Controls で境界設定。すべて応用資料の統合シナリオの骨子と一致します。

• ❌ B：全データ US 集約は EU データ主権に違反。閲覧者ロールでは PII が見えてしまい、CMEK は持ち出し境界の手段でもない。
• ❌ C：BigQuery データセットのロケーションは作成後変更不可（誤り）。生データのコピーは PII を拡散。IAM 最小権限だけでは漏洩時の持ち出しを防げない。
• ❌ D：EU データのグローバル複製は主権違反。Cloud Monitoring は監視であり持ち出しの境界制御ではない。

📖 関連：02_応用.md の「統合シナリオ演習」（データ主権・DLP・承認済みビュー・VPC SC の組み合わせ）