正解：C

解説： 「毎秒数百万件の書き込み」「ミリ秒のキー参照」「結果整合性で可」「PB級・水平スケール」は Bigtable の典型的なユースケース（時系列・IoT）です。ワイドカラム型NoSQLとして低レイテンシ・高スループットを満たします。

• ❌ A：Cloud SQL はリージョナルなOLTP用RDB。毎秒数百万件の書き込みやPB級スケールには対応できません。
• ❌ B：BigQuery はOLAP（大量スキャン集計）向きで、ミリ秒のキー参照や高頻度書き込みには不向き。分析は「別系統」と明記されています。
• ❌ D：Firestore はドキュメント型でモバイル/Web同期向き。毎秒数百万件規模の時系列書き込みは想定用途ではありません。

📖 関連：02_応用.md の「ストレージ選定の意思決定ツリー」「アクセスパターン分析からの選定」

正解：B

解説： 「MySQL互換」「リージョナルで十分」「中小規模トランザクション」「マネージド」は Cloud SQL の定義そのものです。Cloud SQL は MySQL / PostgreSQL / SQL Server に対応したリージョナルなマネージドRDBです。

• ❌ A：Spanner はグローバル分散・水平スケール・無停止が必要なときの選択。「リージョナルで十分」なら過剰でコストも高い。
• ❌ C：AlloyDB は PostgreSQL互換の高性能DB。MySQL互換が要件なので対象外です（ここがひっかけ）。
• ❌ D：Bigtable はリレーショナル/ACIDトランザクションではなくNoSQL。SQLによる一般的なWebバックエンドには不適。

📖 関連：02_応用.md の「Cloud SQL vs Spanner」「選定でよく問われる対比」

正解：B

解説： 「めったに読まない（年1回未満）が消せない長期保管」「保存コスト最小化」は Cloud Storage の Archive クラスが最適です。Archive は保存料が最も安く、最低保存期間は365日で長期コンプライアンス保管に向きます。

• ❌ A：Standard は頻繁アクセス（ホット）向けで保存料が最も高い。年1回未満のアクセスにはコスト過大。
• ❌ C：BigQuery は分析用DWHであり、非構造化ファイル（PDF・画像）の長期アーカイブ先ではありません。
• ❌ D：Cloud SQL はOLTP用RDB。大容量の非構造化ファイル保管には不向きで割高です。

📖 関連：01_基礎.md の「Cloud Storage のストレージクラス」、03_要点と暗記.md の「Cloud Storage クラスとライフサイクル」

正解：B

解説： BigQuery のコスト削減＝「スキャン量の削減」です。①日付などでパーティション分割（プルーニングで不要区画を読まない）、②よく絞る列でクラスタリング（I/O削減）、③必要な列だけSELECT（SELECT *回避）の3点が基本の打ち手です。

• ❌ A：正規化してJOINを増やすのはRDBの発想。BigQueryでは非正規化が基本で、JOINを増やすとむしろ非効率になりがちです。
• ❌ C：SELECT * は全列をスキャンしコストが増大します。コスト削減と真逆です。
• ❌ D：分析クエリのコスト問題を Bigtable で解決するのは誤り。Bigtable はキー参照の低レイテンシストアで、アドホック分析には向きません。

📖 関連：01_基礎.md の「パーティションとクラスタリング」、02_応用.md の「パーティション＋クラスタリングの設計指針」

正解：B

解説： 「グローバル」「強整合ACID」「99.999%」「水平スケール」が揃ったらほぼ Spanner 一択です。TrueTime（GPS＋原子時計）により世界規模で外部一貫性（強整合）を保ちながら水平スケールできる唯一のRDBです。

• ❌ A：Cloud SQL はリージョナルなRDB。リードレプリカを足してもグローバルな強整合の書き込みトランザクションや無制限の水平スケールは実現できません。
• ❌ C：AlloyDB は高性能なリージョナルPostgreSQL互換DB（HTAP寄り）。グローバル分散の強整合トランザクションが要件なら Spanner です。
• ❌ D：Firestore はドキュメント型NoSQL。グローバル金融取引のリレーショナルな強整合トランザクション基盤には不適。

📖 関連：02_応用.md の「Cloud SQL vs Spanner」「Spanner設計のベストプラクティス（TrueTime）」

正解：B

解説： 「リアルタイム同期」「オフライン対応」「ドキュメント指向」「クライアントSDK直結」はすべて Firestore の強みです。モバイル/Webのリアルタイムコラボやゲームのバックエンドに最適です。

• ❌ A：Bigtable はワイドカラム型で時系列・大量書き込み向け。モバイルのリアルタイム同期やオフライン対応SDKは想定用途ではありません。
• ❌ C：Memorystore はキャッシュ層であり、永続的な正本やオフライン同期の仕組みではありません。
• ❌ D：BigQuery は分析用DWH。クライアント直結のトランザクション/同期バックエンドには使いません。

📖 関連：02_応用.md の「Firestore vs Bigtable」、01_基礎.md の「Firestore」

正解：B

解説： アドホックなSQL分析の遅さは BigQuery 内で解決します。スキャン量削減（パーティション/クラスタリング/必要列のみ）に加え、繰り返す重い集計はマテリアライズドビューで事前計算、BIの低レイテンシ化は BI Engine（インメモリ）が定石です。

• ❌ A：「分析が遅いから Bigtable を足す」は典型的な誤り。Bigtable はキー参照の低レイテンシストアであり、アドホックな集計分析の高速化には使いません。
• ❌ C：Cloud SQL へ移しJOINを増やすのは分析ワークロードのスケールに逆行します。大規模分析はBigQueryが適所。
• ❌ D：Firestore はリアルタイム同期用で、BI集計の高速化とは無関係です。

📖 関連：02_応用.md の「アクセスパターン分析からの選定（分析が遅い→Bigtableは誤り）」「マテリアライズドビュー / BI Engine」

正解：B

解説： BigQueryは非正規化が基本。「1:Nで繰り返す情報」はネスト/繰り返しフィールド（ARRAY<STRUCT>）で1行に畳み込むのがBigQuery流で、JOINを削減しスキャン効率を高めます。

• ❌ A：厳密な正規化＋JOID多用はOLTP（RDB）の発想。BigQueryでは逆効果になりがちで、まさにこの問題の原因です。
• ❌ C：分析対象を Bigtable に分割しても、アドホックなSQL集計には向きません。用途が異なります。
• ❌ D：単一STRING列のJSON文字列は、列指向の最適化やスキーマの恩恵を受けられず、STRUCT/ARRAY でのネストより非効率です。

📖 関連：01_基礎.md の「正規化 vs 非正規化／ネスト構造」、02_応用.md の「非正規化とネスト/繰り返しフィールド」

正解：B

解説： Bigtableは行キーで1次元にソートされて分散格納されます。先頭がタイムスタンプだと「最新の書き込み」が常に同じ末尾ノードへ集中し、ホットスポットになります。対策はフィールドプロモーションで高カーディナリティな識別子（vehicleID）を先頭に昇格し、タイムスタンプを後置して書き込みを分散させることです。

• ❌ A：問題は容量やレイテンシではなく書き込みの偏り。HDD化はむしろレイテンシが悪化します。
• ❌ C：Bigtable に「パーティション分割で日付ごとに区切る」というBigQuery的な概念はありません。行キー設計の問題です。
• ❌ D：ホットスポットの原因は行キー設計であり、列ファミリーの正規化では解決しません。

📖 関連：02_応用.md の「Bigtable設計のベストプラクティス（ホットスポット／フィールドプロモーション）」

正解：B

解説： Spanner はキー順にスプリットへ分散します。単調増加キー（連番・タイムスタンプ）は特定スプリットに書き込みが集中しホットスポット化します。対策は UUID/ハッシュ化主キーやキー先頭バイトのハッシュ化で「キーを均等に分散」することです。RDBでありながら Bigtable 同様にホットスポットを意識する点が頻出論点です。

• ❌ A：リードレプリカは読み取りのスケール。書き込みのホットスポットは解消しません。
• ❌ C：要件はグローバル強整合。Cloud SQL（リージョナル）への移行は要件を満たせません。
• ❌ D：連番を密にすると集中がさらに悪化します。分散とは逆の対策です。

📖 関連：02_応用.md の「Spannerのホットスポット回避」、03_要点と暗記.md の「Bigtable / Spanner のホットスポット対策」

正解：A

解説： サブミリ秒の超低レイテンシで頻繁な再読み込みを返す前段キャッシュは Memorystore（Redis/Memcached）の典型用途です。正本はRDBに残したまま、キャッシュ層として追加するのが正しい使い方です。

• ❌ B：Memorystore は揮発しうるインメモリキャッシュであり、永続的な正本（システム・オブ・レコード）にしてはいけません。これは頻出のひっかけです。
• ❌ C：BigQueryは分析用で、低レイテンシなカタログ読み取りのキャッシュ用途ではありません。
• ❌ D：Bigtableはキー参照の低レイテンシストアですが、設問は「正本はRDBにあり、前段にキャッシュを足す」状況。正本の全移行は要件と異なります。

📖 関連：01_基礎.md の「Memorystore」、03_要点と暗記.md の「Memorystore を正本にしない」

正解：B

解説： 「コピーせず・BQのSQLで・行/列レベルの細粒度ガバナンス」は BigLake テーブルの狙いそのものです。GCS上のオープンフォーマット（Parquet等）をコピーせずに、BigQuery級のガバナンス（行/列レベルのアクセス制御）を適用できます。

• ❌ A：全件ロードは「コピーせず」という要件に反します。
• ❌ C：単純な外部テーブルだけでは行/列レベルの細粒度セキュリティが弱い。細粒度制御には BigLake テーブル化が必要です（ひっかけ）。
• ❌ D：Bigtable はキー参照ストアで、レイク上のParquetをSQL分析・細粒度統制する用途ではありません。

📖 関連：02_応用.md の「BigLake の使いどころ」、01_基礎.md の「BigLake」

正解：A と C

解説：

• A 正しい：四半期に1回程度しか参照しないアーカイブログを Coldline（最低保存90日）へ移行するのは、コスト最適化の定番ライフサイクルルールです。

• C 正しい：アクセスパターンが不明なら Autoclass が有効。アクセス頻度を自動学習してクラスを最適化し、手動ルール設計や早期削除料金のリスクを避けられます。

• ❌ B：Nearline は最低保存期間30日。30日ごとに上書き（実質的に短命）するデータを置くと早期削除/上書きで早期削除料金が発生するアンチパターン。短命データは Standard に。

• ❌ D：Archive は取り出しコストが最も高いクラス。頻繁に配信するホットデータを置くと取り出しコストが膨らみます。逆です。

📖 関連：02_応用.md の「GCS ライフサイクル管理（早期削除料金・Autoclass）」、03_要点と暗記.md の「Cloud Storage クラスとライフサイクル」

正解：A と B と C

解説： これは統合シナリオで「要件を軸でふるい分け、各サービスへ割り当てる」本番そのものの問題です。

• A 正しい：グローバル強整合・無停止・水平スケールは Spanner（TrueTime）。

• B 正しい：毎秒数百万件のテレメトリ・ミリ秒参照は Bigtable（低レイテンシ重視ならSSD）。

• C 正しい：アドホックなSQL分析・BIは BigQuery（非正規化＋パーティション/クラスタリング、BI Engine/マテビュー）。

• ❌ D：本人確認画像（非構造化・コールド長期保管）は Cloud Storage（Coldline/Archive） が適切。Bigtable はキー参照ストアでアーカイブ用途ではありません。

• ❌ E：Memorystore はキャッシュであり正本にしてはいけません。テレメトリの正本は Bigtable。Memorystore を正本にする選択肢は典型的な誤りです。

📖 関連：02_応用.md の「統合シナリオ演習」、03_要点と暗記.md の「ストレージ選定 早見表」

正解：B

解説： 「PostgreSQL互換」「高負荷OLTP」「同じDBで分析も速い（HTAP）」「リージョナル」は AlloyDB の狙いどころです。カラムナエンジンを内蔵し、トランザクションと分析クエリの両方を高速化します。

• ❌ A：Cloud SQL for PostgreSQL でも互換性はありますが、HTAP（同一DBでの高速分析）や高負荷性能は AlloyDB が優れます。設問は「分析も高速に」が決め手。
• ❌ C：Spanner はグローバル分散の強整合RDB。設問は「リージョナルで十分」かつ「PostgreSQL互換」で、要件に対し過剰かつ方向が異なります。
• ❌ D：BigQuery は分析専用のDWH。高負荷OLTPの基幹トランザクションには不向きです。

📖 関連：01_基礎.md の「AlloyDB」、02_応用.md の意思決定ツリー Q5（HTAP→AlloyDB）

正解：B

解説： 「物理的に動かさず論理レイク/ゾーンに整理」「横断ガバナンス（品質・セキュリティ・発見性・系統）」「データメッシュ＋フェデレーテッドガバナンス」の中核は Dataplex です。メタデータの検索・発見・系統は Dataplex Catalog が担い、データスワンプ化を防ぎます。

• ❌ A：バケットを部門で分けるだけでは横断ガバナンス・発見性・系統は得られず、データスワンプ化します。
• ❌ C：「中央チームが全データを抱える」設計はスケールせず、データメッシュ（分散所有＋フェデレーテッドガバナンス）の考え方に反します。
• ❌ D：Memorystore はキャッシュであり、組織横断のメタデータカタログ/ガバナンス基盤ではありません。

📖 関連：02_応用.md の「Dataplex によるレイク管理」「データメッシュ × フェデレーテッドガバナンス」、01_基礎.md の「Dataplex / Dataplex Catalog」