Section 2 問題集：DB 運用管理
全 20 問。バックアップ、監視、コスト/性能最適化、自動化、IAM が中心。
Q1. PITR の期間
問題： Cloud SQL for MySQL で PITR（Point-in-Time Recovery）の最大保持期間は？
- A. 7 日
- B. 14 日
- C. 35 日
- D. 365 日
正解: C
解説: Cloud SQL の PITR は最大 35 日。binary log を継続保持することで実現。 自動バックアップ自体は 7〜365 日設定可能だが、PITR の対象は最大 35 日。
Q2. クエリパフォーマンスの調査
問題： Cloud SQL for PostgreSQL で 特定のクエリが急に遅くなった。最初に確認すべきは？
- A. マシンタイプをアップグレードする
- B. Query Insights で実行計画の変化を確認
- C. リードレプリカを追加する
- D. インスタンスを再起動する
正解: B
解説: 性能劣化の原因究明は Query Insights → 実行計画 → インデックス確認 の順。 リソース増強や再起動は 症状をぼかす対処 であり、根本原因究明にならない。
Q3. IAM DB 認証のメリット
問題： Cloud SQL の IAM DB 認証 を使う最大のメリットは？
- A. クエリ性能が向上する
- B. パスワード管理が不要、監査ログに統合される
- C. ストレージコストが削減される
- D. レプリケーション遅延が短縮される
正解: B
解説:
- IAM DB 認証 = サービスアカウントベース、短命トークン で認証
- パスワード管理・ローテーション不要
- 監査ログに統合（誰が何時にアクセスしたか追跡可能）
Q4. アラート設計
問題： Cloud SQL の CPU が瞬間的に 80% を超えるが、業務影響なく安定運用しています。 不必要な誤検知を防ぐ アラート設計は？
- A. CPU > 80% で即座にアラート
- B. CPU > 80% が 1 分間継続でアラート
- C. CPU > 80% が 5 分間継続でアラート
- D. CPU > 50% でアラート
正解: C
解説:
- 良いアラートは「アクション可能」「誤検知が少ない」「重要度がある」
- 継続時間 5 分 で瞬間スパイクを除外
- 50% は閾値が低すぎ
- 1 分は瞬間スパイクで頻発する
Q5. バックアップ戦略
問題： 本番 DB のバックアップ要件で、 7 年間保管 が必要です。最もコスト効率の良い手段は？
- A. Cloud SQL 自動バックアップを 7 年保持
- B. PITR を 7 年保持
- C. 月次エクスポート → Cloud Storage Archive クラス
- D. 別の Cloud SQL インスタンスに常時レプリカ
正解: C
解説:
- 7 年保管 = 長期アーカイブ → Cloud Storage Archive クラス が最安
- Cloud SQL のバックアップ保持は最大 365 日（7 年は不可）
- PITR は最大 35 日
- 常時レプリカはコスト高
Q6. リードレプリカ遅延
問題： Cloud SQL の リードレプリカで 遅延が常時 5 分以上 発生。最も適切な対応は？
- A. Primary をスケールアップ
- B. レプリカのリソース確認 + 不要な書き込み負荷削減
- C. クロスリージョン リードレプリカに変更
- D. PITR を無効化
正解: B
解説:
- レプリ遅延の主原因 = レプリカ側のリソース不足 または 大量バッチ書き込み
- 大量更新（ALTER, バッチ）を確認・分割
- Primary 強化は的外れ
- クロスリージョンはむしろ遅延増加
Q7. スケーリング判断
問題： Cloud SQL for PostgreSQL で 読み取り QPS が 80%増加 の見込み。書き込みは変化なし。最適な対応は？
- A. マシンタイプアップグレード
- B. リードレプリカを追加し、アプリの読み取りを分散
- C. Spanner へ移行
- D. AlloyDB へ移行
正解: B
解説:
- 読み取りスケール → リードレプリカ追加 が最も低コスト・低リスク
- マシンアップは書き込みも含めスケールし、コスト過剰
- Spanner/AlloyDB 移行はオーバースペック
Q8. 監視メトリクス選定
問題： Cloud SQL の 接続枯渇 を早期検知したい。監視すべき主要メトリクスは？
- A. cloudsql.googleapis.com/database/cpu/utilization
- B. cloudsql.googleapis.com/database/network/connections
- C. cloudsql.googleapis.com/database/memory/usage
- D. cloudsql.googleapis.com/database/disk/utilization
正解: B
解説:
- 接続数メトリクス で max_connections に対する利用率を監視
- 接続枯渇前に コネクションプーラー 導入を検討
Q9. メジャーバージョンアップ
問題： Cloud SQL for PostgreSQL 13 → 15 へのメジャーアップグレードで、 ロールバック可能 にしたい。最適な手段は？
- A. インプレースアップグレード
- B. 新規 15 インスタンス + DMS で移行 + 旧 13 を保持
- C. クロスリージョン リードレプリカに昇格
- D. 自動マイナーアップグレードに任せる
正解: B
解説:
- インプレースは ロールバック不可
- DMS で Blue-Green 構成 が標準的なベストプラクティス
- 旧 13 を残せばロールバック可能
- 自動マイナーアップグレードはメジャー対象外
Q10. CMEK の管理
問題： CMEK で Cloud SQL を暗号化中、 Cloud KMS の鍵を誤って無効化 しました。何が起きる？
- A. インスタンスは動作継続するが、新規バックアップが失敗
- B. インスタンスはすぐに停止し、再開には鍵の有効化が必要
- C. データが自動的にロールバックされる
- D. Google が自動的に代替鍵を割り当てる
正解: B
解説:
- CMEK 鍵を無効化 すると、DB は暗号化キーへアクセスできず 停止
- 鍵を有効化すれば復旧可能
- そのためバックアップ・代替鍵などは関与しない
Q11. Cloud Workflows での自動化
問題： 毎日 02:00 に Cloud SQL のエクスポートを自動実行し、ファイル名にタイムスタンプを付与したい。最適な構成は？
- A. cron on Compute Engine
- B. Cloud Scheduler → Cloud Functions → gcloud sql export
- C. Cloud Build スケジュール実行
- D. App Engine cron jobs
正解: B
解説:
- Google 推奨パターン: Cloud Scheduler → Functions or Workflows → gcloud/API
- サーバーレス、運用負荷ゼロ、料金最小
- VM cron は管理負荷あり
- App Engine cron は GAE 環境前提
Q12. インデックス過多の弊害
問題： PostgreSQL テーブルに インデックスを 20 個 作成しています。書き込みが遅くなった原因は？
- A. メモリ不足
- B. 各書き込みで全インデックス更新が必要
- C. ストレージ不足
- D. インデックスはバージョン管理されないため
正解: B
解説:
- インデックスは INSERT/UPDATE/DELETE 毎に更新コスト がかかる
- 不要なインデックス削除（pg_stat_user_indexes で未使用を確認）
- Index Advisor で必要なものだけ残す
Q13. PostgreSQL VACUUM の管理
問題： PostgreSQL で テーブルサイズが想定以上に肥大化 + クエリ遅延。最初に確認すべきは？
- A. インデックス再構築
- B. autovacuum / VACUUM ANALYZE の状態確認
- C. マシンタイプアップ
- D. リードレプリカ追加
正解: B
解説:
- PostgreSQL は MVCC でデッドタプルが残る → VACUUM で回収
- autovacuum が無効/不十分だと膨張
- pg_stat_user_tables で確認、
VACUUM FULLは最終手段（ロック取得）
Q14. Cloud SQL Maintenance Window
問題： 本番 Cloud SQL のメンテナンスを 業務時間外 に集中させたい。設定は？
- A. メンテナンスウィンドウを 日曜 03:00-04:00 JST に設定
- B. すべてのメンテナンスを無効化
- C. 自動マイナーアップグレードをオフ
- D. メンテナンス時に手動でフェイルオーバー
正解: A
解説:
- メンテナンスウィンドウ で時間帯を指定
- メンテナンスを完全無効化は不可（セキュリティパッチ等は必要）
- 自動マイナー切ると脆弱性パッチも適用されない
Q15. Spanner クエリ最適化
問題： Spanner で特定クエリが遅い。EXPLAIN で フルテーブルスキャン が確認された。最も効果的な対応は？
- A. Processing Units を増やす
- B. クエリで使う列に セカンダリインデックス を追加
- C. テーブルを再作成
- D. アプリ側でキャッシュ
正解: B
解説:
- Spanner も セカンダリインデックス で性能改善
- フルスキャン回避はインデックスが基本
- PU 増加では根本解決にならない
- STORING 句で必要な列を含めると Index Only Scan で更に高速化
Q16. Bigtable のオートスケーリング
問題： Bigtable インスタンスで CPU 利用率が 70% を超え続ける。最適な対応は？
- A. オートスケーリング有効化（CPU ターゲット 60%）
- B. ストレージタイプを SSD → HDD に変更
- C. リージョンを変更
- D. テーブルを再作成
正解: A
解説:
- Bigtable は オートスケーリング（CPU + ストレージ ターゲット指定）
- 推奨 CPU ターゲット 50-60%
- HDD は低速ストレージ、性能改善には逆効果
Q17. AlloyDB Index Advisor
問題： AlloyDB の Index Advisor で推奨される機能は？
- A. クエリのキャッシュ戦略
- B. ワークロード分析に基づく不足インデックスの自動推奨
- C. リードレプリカ追加の推奨
- D. マシンタイプの自動調整
正解: B
解説:
- Index Advisor = AlloyDB がワークロードを観測 → 不足インデックスを CREATE INDEX 文として提示
- 開発者は実行するだけ
- キャッシュ・レプリカ・スケーリングは別機能
Q18. クロスリージョン リードレプリカの活用
問題： Cloud SQL のクロスリージョン リードレプリカの 本来の目的 は？
- A. グローバルな読み取り分散
- B. リージョン障害時の DR
- C. 開発環境のコスト削減
- D. ストレージ拡張
正解: B
解説:
- クロスリージョン リードレプリカの主目的は DR
- 読み取り分散も可能だが、レイテンシ・コスト面で限定的
- 本番障害時に手動 Promote で別リージョンで運用継続
Q19. Spanner Backup
問題： Spanner のバックアップ機能で 正しい説明 は？
- A. Backup は最大 7 日保持可能
- B. Backup は最大 1 年（365日）保持可能
- C. Backup は無期限保持可能
- D. Backup は不可（PITR のみ）
正解: B
解説:
- Spanner Backup は最大 1 年保持
- PITR は最大 7 日
- 別リージョンへのコピー可能
Q20. コスト最適化
問題： 本番 Cloud SQL の月額が 過剰 と判明。最も効果的な削減策の組み合わせは？（複数選択）
- A. Committed Use Discount (CUD) 適用
- B. 開発環境を ZONAL に変更
- C. 未使用のリードレプリカ削除
- D. PITR 保持期間を業務要件に合わせて短縮
- E. 自動バックアップを完全停止
正解: A, B, C, D
解説:
- CUD で 20-60% 削減
- 開発は HA 不要 → ZONAL でコスト半減
- 未使用リードレプリカは即削除
- PITR 保持期間最適化（35日 → 7日 など）
- 自動バックアップ停止は NG（業務継続性リスク）
📊 採点と次のステップ
- 80% 以上 → Section 3 へ
- 60-79% → 学習資料 02_運用管理 を再読
- 60% 未満 → 03_要点と暗記.md を毎日復習