Section 6: 運用卓越性 — 問題集（20 問）

対象範囲: Section 6 (~12.5%) — Ensuring solution and operations excellence 総問題数: 20 問 想定所要時間: 60 分（1 問 3 分目安）

学習方針

本問題集は 公式試験ガイド v2025-10 改訂版 に準拠しています。
Section 6 は Well-Architected Framework の Operational Excellence pillar を中心に、Observability（Monitoring/Logging/Trace/Profiler）、デプロイ管理、品質管理、本番信頼性（Chaos / Pentest / Load Testing）を扱います。
2025 改訂で Managed Prometheus / Forecast-based Alert / Gemini Cloud Assist Investigations が新たに重要トピックとして加わりました。

正答率の目安

正答率	評価	次のアクション
90% 以上	合格圏（試験本番でも安定）	模擬試験 → 直前は要点と暗記のみループ
75–89%	合格安全圏未到達	弱点別復習ガイド（巻末）で重点強化
60–74%	要対策	`02_応用.md` を再読 → Section 5 と紐付け
60% 未満	不合格圏	`01_基礎.md` から学び直し

問題 1 （難易度: ★）

シナリオ: Altostrat Media は動画配信サービスを運営しています。プロダクトリードが「SLO ベースの信頼性管理を導入したい」と提案しました。SRE チームは SLI / SLO / SLA の違いを正しく理解した上で設計を始める必要があります。

質問: SLI / SLO / SLA の違いとして 最も正確な記述 はどれですか。

選択肢:

A. SLI = 顧客との契約値、SLO = 内部目標、SLA = 実測値
B. SLI = 実測値、SLO = 内部目標、SLA = 顧客との契約値（罰則あり）
C. SLI = 罰則付き契約、SLO = 実測値、SLA = 内部目標
D. 3 つはすべて同義語

解答と解説

正解: B

解説:

B が正解: SLI（Service Level Indicator）= 信頼性の実測値（例: HTTP 成功率 99.5%）、SLO（Service Level Objective）= 内部の目標値（例: 99.9% を目指す）、SLA（Service Level Agreement）= 顧客との契約値（罰則あり、通常 SLO より緩い）。
A 不正解: SLI と SLA が逆。SLI は実測、SLA は契約。
C 不正解: 3 つの定義が混乱。
D 不正解: 3 つは明確に異なる概念。

ひっかけポイント: SLO > SLA（内部目標は契約より厳しく設定する）が原則。SLI < SLO の場合、エラーバジェットを消費しています。

関連リソース:

../02_学習資料/06_運用卓越性/02_応用.md

問題 2 （難易度: ★★）

シナリオ: あなたは SRE として、API サービスの SLO を 99.9% に設定しています。月間運用時間ベースで、SLO に従う場合に許容される エラーバジェット（月あたりのダウンタイム） を計算しています。

質問: SLO 99.9% における月間エラーバジェットの数値はどれですか。

選択肢:

A. 約 4 分 19 秒
B. 約 43 分 12 秒
C. 約 7 時間 18 分
D. 約 25.9 秒

解答と解説

正解: B

解説:

B が正解: SLO 99.9% は月間 0.1% のダウンタイム許容 = 30 日 × 24 時間 × 60 分 × 0.001 = 43 分 12 秒。これがエラーバジェットです。
A 不正解: 約 4 分 19 秒は SLO 99.99% のエラーバジェット。
C 不正解: 約 7 時間 18 分は SLO 99% のエラーバジェット。
D 不正解: 約 25.9 秒は SLO 99.999%（Five Nines）のエラーバジェット。

ひっかけポイント: SLO 別エラーバジェットの数値は 暗記必須: 99% = 7h18m、99.5% = 3h39m、99.9% = 43m12s、99.99% = 4m19s、99.999% = 25.9s。

関連リソース:

../02_学習資料/06_運用卓越性/03_要点と暗記.md

問題 3 （難易度: ★★）

シナリオ: Cymbal Retail はマルチクラウド戦略で、AWS と GCP の両方で Prometheus メトリクスを収集していました。GCP 内で OSS Prometheus 互換のメトリクス管理を採用し、自動スケール・長期保存・PromQL クエリ を実現したいと考えています。運用負荷を最小化する選択肢を求めています。

質問: この要件に最適な GCP サービスはどれですか。

選択肢:

A. Cloud Monitoring（標準メトリクスのみ）
B. Managed Service for Prometheus
C. Self-hosted Prometheus on GKE
D. Cloud Logging Metrics

解答と解説

正解: B

解説:

B が正解: Managed Service for Prometheus は GCP マネージドの Prometheus 互換サービス。PromQL クエリ対応、自動スケール、24 ヶ月のメトリクス保持、Grafana 統合が標準提供されます。OSS Prometheus からの移行も容易。
A 不正解: Cloud Monitoring は標準メトリクスシステムですが、Prometheus 互換ではありません。
C 不正解: Self-hosted は運用負荷高（スケーリング・ストレージ管理）。マネージド推奨。
D 不正解: Cloud Logging Metrics はログベースメトリクスで、Prometheus 用途ではありません。

ひっかけポイント: 2025 改訂で Managed Service for Prometheus が試験範囲に明示追加されました。「PromQL / 24 ヶ月保持 / 自動スケール」のキーワードでは即答できることが大切です。

関連リソース:

../02_学習資料/06_運用卓越性/02_応用.md

問題 4 （難易度: ★★★）

シナリオ: あなたは SRE として、ユーザー体験を悪化させる前に問題を検知する効果的なアラートを設計したいと考えています。一般的な「CPU 80% アラート」は誤検知が多く、運用チームのアラート疲れを引き起こしていました。SLO ベースのアラート戦略を導入する方針です。

質問: Multi-window / Multi-burn-rate アラートの推奨設定として 適切な記述を 2 つ 選びなさい。

選択肢:

A. Fast burn: 5 分間 × 14.4x（即時 Critical 通知用）
B. Slow burn: 6 時間 × 1x（中長期的劣化を検知）
C. Single-window: 24 時間平均でアラート（誤検知を減らすため）
D. Static threshold: CPU 90% で即時アラート（症状ベースより簡単）

解答と解説

正解: A, B

解説:

A が正解: Fast burn (5min × 14.4x) は重大障害の即時検知用。1 時間でエラーバジェット 14.4% を消費するペースで Critical 通知。
B が正解: Slow burn (6h × 1x) は中長期的な劣化検知用。6 時間で 1x ペース = 通常通り消費しているが、累積で問題化する兆候を検知。
C 不正解: Single-window は反応が遅すぎて重大障害を見逃す可能性。Multi-window が推奨。
D 不正解: Static threshold（CPU % など）は 症状ベースではないため、ユーザー影響と相関しません。SRE では避けるべきパターンです。

ひっかけポイント: SRE 推奨は Fast (5min × 14.4x) / Medium (1h × 6x) / Slow (6h × 1x) の 3 段階。CPU % のような静的しきい値は Anti-pattern。

関連リソース:

../02_学習資料/06_運用卓越性/02_応用.md

問題 5 （難易度: ★★）

シナリオ: KnightMotives Automotive はテレマティクス基盤を運営しています。クォータ枯渇に至る前に 予測ベース で警告したいと考えています。例えば「現在のペースなら 7 日後にクォータ枯渇」のようなプロアクティブな通知が必要です。

質問: この要件に最適な Cloud Monitoring の機能はどれですか。

選択肢:

A. Static Threshold Alert
B. Multi-window Burn Rate Alert
C. Forecast-based Alert
D. Uptime Check

解答と解説

正解: C

解説:

C が正解: Forecast-based Alert は機械学習で将来値を予測し、しきい値到達前にアラートを発します。クォータ枯渇予知、ディスク容量逼迫予知などに使えます。2025 改訂で試験範囲入りした新機能。
A 不正解: Static Threshold は現時点の値ベースで、予測ではありません。
B 不正解: Multi-window Burn Rate は SLO 消費速度の検知で、未来予測ではありません。
D 不正解: Uptime Check は外形監視で、予測機能はありません。

ひっかけポイント: 「プロアクティブ予測」キーワードでは Forecast Alert 一択。2025 試験範囲新規追加項目。

関連リソース:

../02_学習資料/06_運用卓越性/02_応用.md

問題 6 （難易度: ★★）

シナリオ: EHR Healthcare は医療情報を扱う SaaS で、HIPAA コンプライアンス要件があります。ユーザーが患者情報にアクセスした全イベントを記録・保持する必要があります。デフォルトでは特定のログタイプが無効になっているため、明示的な有効化が必要です。

質問: HIPAA コンプライアンスのために有効化すべき GCP の Audit Logs はどれですか。

選択肢:

A. Admin Activity Logs（デフォルト有効）
B. Data Access Logs（デフォルト無効）
C. System Event Logs（デフォルト有効）
D. Policy Denied Logs（デフォルト有効）

解答と解説

正解: B

解説:

B が正解: Data Access Audit Logs はデフォルト無効です。患者情報・PHI へのアクセスを記録するため、HIPAA / GDPR などのコンプライアンス要件下では 明示的に有効化 する必要があります。ログ量が膨大になるためデフォルト無効。
A 不正解: Admin Activity Logs はリソース変更を記録（デフォルト有効）。データアクセスではありません。
C 不正解: System Event Logs は GCP 自動操作の記録（デフォルト有効）。
D 不正解: Policy Denied Logs はポリシー違反の記録（デフォルト有効）。

ひっかけポイント: Audit Logs 4 種を覚える: Admin Activity / Data Access（デフォルト無効）/ System Event / Policy Denied。「データアクセス記録」「コンプラ」キーワードでは即答。

関連リソース:

../02_学習資料/06_運用卓越性/02_応用.md

問題 7 （難易度: ★★★）

シナリオ: Cymbal Retail は大規模 EC サイトで、Black Friday の負荷を事前検証する必要があります。実トラフィックの 10 倍を模擬し、API レスポンスの分布・エラー率・スループットを測定したいと考えています。

質問: この用途に 最も適切な ツール選択肢はどれですか。

選択肢:

A. Locust / k6 / JMeter で負荷テストを実施
B. Chaos Toolkit で障害注入する
C. Pentest を実施する
D. Static Code Analysis を強化する

解答と解説

正解: A

解説:

A が正解: Locust / k6 / JMeter / Gatling は負荷テスト用 OSS の代表。Black Friday のような実トラフィック模擬には最適。Cloud Load Balancing と組み合わせて Spike Test も可能。
B 不正解: Chaos Toolkit は故意に障害注入する Chaos Engineering 用で、負荷テストではありません。
C 不正解: Pentest は侵入テスト（セキュリティ）で、性能負荷テストではありません。
D 不正解: Static Code Analysis はコード品質チェックで、本番負荷検証ではありません。

ひっかけポイント: 信頼性検証の種類を区別: Load Test（性能）/ Chaos（回復力）/ Pentest（セキュリティ）/ Game Day（演習）。「実トラフィック模擬」= Load Test。

関連リソース:

../02_学習資料/06_運用卓越性/02_応用.md

問題 8 （難易度: ★★）

シナリオ: あなたは SRE として、本番環境で稼働するシステムの 回復力（resilience） を検証したいと考えています。実際にネットワーク遅延・Pod 削除・リージョン障害を意図的に注入し、システムが SLO を維持できるかを継続的にテストする方針です。

質問: この用途に最適な手法はどれですか。

選択肢:

A. Load Testing
B. Chaos Engineering
C. Pentest
D. Unit Testing

解答と解説

正解: B

解説:

B が正解: Chaos Engineering は意図的に障害を注入してシステム回復力を検証する手法。Netflix 発祥の Chaos Monkey が起源。GCP では Chaos Toolkit / Litmus / Gremlin などのツールを使います。SRE の重要プラクティスです。
A 不正解: Load Testing は性能検証で、障害注入とは異なります。
C 不正解: Pentest はセキュリティ検証で、回復力ではありません。
D 不正解: Unit Testing はコードレベルテストで、システム回復力ではありません。

ひっかけポイント: Chaos Engineering の 4 原則: 1. 定常状態の仮説（SLO 達成）2. 現実世界の事象を変数化 3. 本番（または近い環境）で実験 4. 自動化・継続実行。

関連リソース:

../02_学習資料/06_運用卓越性/02_応用.md

問題 9 （難易度: ★★）

シナリオ: EHR Healthcare は GCP インフラに対する Pentest（侵入テスト）を計画しています。コンプライアンス要件で年 1 回の Pentest 実施が必要です。あるエンジニアが「GCP で Pentest するには Google への事前申請が必要では？」と尋ねました。

質問: GCP で Pentest を実施する際の 正しい取り扱い はどれですか。

選択肢:

A. GCP 規約で Pentest は事前申請が必要、書面承認後のみ実施可能
B. GCP 規約で Pentest は事前申請不要、ただし DDoS や他テナント影響は禁止
C. GCP で Pentest は全面禁止
D. リージョンごとに別途承認が必要

解答と解説

正解: B

解説:

B が正解: GCP の利用規約では Pentest は事前申請不要。ただし以下は禁止: (1) DDoS 攻撃、(2) 他テナントへの影響、(3) インフラ自体への攻撃（GCP コントロールプレーン）、(4) 過剰負荷。自社リソース対象なら自由に Pentest 可能。
A 不正解: AWS は以前は申請必要でしたが、現在は不要に変更。GCP は元から不要。
C 不正解: Pentest は許可されています（自社リソース対象）。
D 不正解: リージョンごとの承認は不要。

ひっかけポイント: GCP は他クラウドと違って Pentest 事前申請不要。試験では「事前申請が必要」という誤った選択肢で誘導してくる可能性あり。

関連リソース:

../02_学習資料/06_運用卓越性/02_応用.md

問題 10 （難易度: ★★★）

シナリオ: Altostrat Media は本番障害発生時のインシデント対応プロセスを整備しています。ICS（Incident Command System）に基づき役割を明確化したいと考えています。重大障害時に 全体統率と最終判断 を担う中心人物を決める必要があります。

質問: ICS において全体統率・最終判断を担う役割はどれですか。

選択肢:

A. Communication Lead（連絡担当）
B. Operations Lead（修復作業リード）
C. Incident Commander（IC）
D. Subject Matter Expert（SME）

解答と解説

正解: C

解説:

C が正解: IC（Incident Commander） はインシデント対応の全体統率者。最終判断、優先度決定、ステークホルダー連絡指示などを担います。Google SRE の標準モデル。
A 不正解: Communication Lead はステークホルダー連絡・Status Page 更新を担当します。
B 不正解: Operations Lead は修復作業の指揮者で、技術判断を担います。
D 不正解: SME は特定技術の専門家として参加します。

ひっかけポイント: ICS の 5 役割を覚える: IC（統率）/ Communication（連絡）/ Operations（修復）/ Scribe（記録）/ SME（専門家）。

関連リソース:

../02_学習資料/06_運用卓越性/02_応用.md

問題 11 （難易度: ★★）

シナリオ: あなたは複雑な分散システムのパフォーマンス問題を調査中。リクエストが API → Cloud Run → Cloud SQL → Pub/Sub → Worker と流れる中で、どこにレイテンシが集中しているかを可視化したいと考えています。OpenTelemetry 標準対応のサービスを希望しています。

質問: この用途に最適な GCP サービスはどれですか。

選択肢:

A. Cloud Logging
B. Cloud Monitoring
C. Cloud Trace
D. Cloud Profiler

解答と解説

正解: C

解説:

C が正解: Cloud Trace は分散トレースサービス。OpenTelemetry 標準対応で、リクエストの各サービス間レイテンシをスパンとして可視化。ボトルネック特定に最適です。
A 不正解: Cloud Logging はログ集約用で、サービス間のスパン関係は表現できません。
B 不正解: Cloud Monitoring はメトリクス用で、分散リクエストの経路追跡は不得意。
D 不正解: Cloud Profiler はアプリケーション内部のプロファイリング（CPU/メモリ/Heap）で、サービス間トレースではありません。

ひっかけポイント: Observability の 4 大柱: Logging（ログ）/ Monitoring（メトリクス）/ Trace（分散トレース）/ Profiler（プロファイル）。「サービス間のリクエスト経路」= Trace。

関連リソース:

../02_学習資料/06_運用卓越性/02_応用.md

問題 12 （難易度: ★★）

シナリオ: あなたは本番サービスでメモリ使用量が徐々に増加する問題を調査中。コードのどの関数がメモリリークを引き起こしているかを 本番環境で軽量に 特定したいと考えています。性能影響なく継続的にプロファイル収集する手段を求めています。

質問: この用途に最適な GCP サービスはどれですか。

選択肢:

A. Cloud Trace
B. Cloud Profiler
C. Error Reporting
D. Cloud Monitoring カスタムメトリクス

解答と解説

正解: B

解説:

B が正解: Cloud Profiler は本番環境で常時動作する軽量プロファイラー。CPU / メモリ / Heap / Wall time / Lock 待ちなどを統計サンプリングで収集し、Flame Graph で可視化。本番影響 1% 以下と軽量です。Go / Java / Node.js / Python 対応。
A 不正解: Cloud Trace はサービス間トレース用で、アプリケーション内部プロファイルではありません。
C 不正解: Error Reporting は例外集約で、性能プロファイルではありません。
D 不正解: Custom Metrics はメトリクス収集で、コードのプロファイルは不可。

ひっかけポイント: 「本番常時プロファイル」= Cloud Profiler。本番影響が軽量という特徴が頻出。

関連リソース:

../02_学習資料/06_運用卓越性/02_応用.md

問題 13 （難易度: ★★）

シナリオ: KnightMotives Automotive は組織全体（複数プロジェクト・複数フォルダ）のログを SIEM システムに集約する必要があります。各プロジェクトで個別にログシンクを設定するのは運用負荷が大きいため、組織レベルでまとめて設定したいと考えています。

質問: この要件に最適な GCP 機能はどれですか。

選択肢:

A. Aggregated Sink（組織レベルログシンク）
B. Project-level Log Sink
C. Log Bucket Replication
D. Cloud Logging Federation

解答と解説

正解: A

解説:

A が正解: Aggregated Sink は組織・フォルダレベルで設定するログシンクで、配下の全プロジェクトログを 1 つのシンクで集約できます。SIEM 連携・コンプラ用途に最適です。
B 不正解: Project-level Sink は各プロジェクトで個別設定が必要で、運用負荷増。
C 不正解: Log Bucket Replication という機能は存在しません。
D 不正解: Cloud Logging Federation という名称のサービスはありません。

ひっかけポイント: 「組織横断ログ集約」= Aggregated Sink。シンク先は BigQuery / GCS / Pub/Sub / 別 Log Bucket / 外部 SIEM が選べます。

関連リソース:

../02_学習資料/06_運用卓越性/02_応用.md

問題 14 （難易度: ★★★）

シナリオ: EHR Healthcare で本番障害が発生しました。複数のサービス（GKE / Cloud Run / Cloud SQL / Pub/Sub）にまたがる障害で、原因特定が困難です。SRE は AI 支援を使って、リソース横断で関連事象を分析し、原因仮説を生成したいと考えています。

質問: この用途に最適な GCP の AI 機能はどれですか。

選択肢:

A. Gemini Code Assist
B. Vertex AI AutoML
C. Gemini Cloud Assist Investigations
D. Cloud Profiler AI

解答と解説

正解: C

解説:

C が正解: Gemini Cloud Assist Investigations は障害発生時にリソース横断で関連事象を分析、原因仮説を生成する AI 機能。Log Analytics 統合で自然言語でログ検索も可能。2025 改訂で試験範囲入りした新機能。
A 不正解: Gemini Code Assist は IDE 内 AI コーディング支援で、運用障害分析ではありません。
B 不正解: Vertex AI AutoML は ML モデル作成用で、運用支援ではありません。
D 不正解: Cloud Profiler AI という名称のサービスはありません。

ひっかけポイント: 「障害分析 AI 支援」= Gemini Cloud Assist Investigations。Code Assist（IDE）と Cloud Assist（運用）の混同に注意。

関連リソース:

../02_学習資料/06_運用卓越性/02_応用.md

問題 15 （難易度: ★★）

シナリオ: あなたは本番運用チームのリードで、変更管理をしっかり行うため Cloud Deploy を導入しました。次に、コードを変更せずに機能の ON/OFF を切替できる仕組みが必要です。例えば「30% のユーザーにのみ新機能を有効化」「障害発生時に該当機能だけ即時停止」を実現したいと考えています。

質問: この要件に最適な仕組みはどれですか。

選択肢:

A. Blue-Green デプロイ
B. Canary リリース
C. Feature Flag
D. Rolling Update

解答と解説

正解: C

解説:

C が正解: Feature Flag（フィーチャーフラグ）はコード変更なしで機能を ON/OFF できる仕組み。ユーザー属性（地域・プラン）でセグメント別有効化、A/B テスト、障害時の即時停止に使えます。LaunchDarkly や Firebase Remote Config が代表的。
A 不正解: Blue-Green は新版/旧版の切替で、特定機能だけの切替はできません。
B 不正解: Canary は一部ユーザーに新版を出す手法ですが、機能単位の細かい切替ではありません。
D 不正解: Rolling Update は順次置換で、機能切替の仕組みではありません。

ひっかけポイント: 「コード変更なし機能切替」= Feature Flag。デプロイ戦略（Blue-Green / Canary）とは別概念。Progressive Delivery では両者を組み合わせます。

関連リソース:

../02_学習資料/06_運用卓越性/02_応用.md

問題 16 （難易度: ★★）

シナリオ: EHR Healthcare は医療データを扱うため、HIPAA / FedRAMP / IL4 などの規制業界要件を満たす必要があります。GCP 環境を規制業界向けに統制し、機密データのアクセス・処理を強制管理する仕組みを導入したいと考えています。

質問: この要件に最適な GCP サービスはどれですか。

選択肢:

A. Organization Policy のみ
B. Assured Workloads
C. VPC Service Controls のみ
D. Cloud Identity

解答と解説

正解: B

解説:

B が正解: Assured Workloads は規制業界向け統制パッケージ。HIPAA / FedRAMP High / FedRAMP Moderate / IL2 / IL4 / IL5 / CJIS など各規制に対応する Organization Policy / アクセス制御 / リージョン制限 / サポート要員制限を自動適用します。
A 不正解: Organization Policy は基本機能ですが、規制特化の統制パッケージではありません。
C 不正解: VPC Service Controls はネットワーク境界制御で、規制業界統制の一部にすぎません。
D 不正解: Cloud Identity は ID 管理で、規制業界統制ではありません。

ひっかけポイント: 「規制業界（HIPAA / FedRAMP / IL4）」キーワードでは Assured Workloads 一択。

関連リソース:

../02_学習資料/06_運用卓越性/02_応用.md

問題 17 （難易度: ★★）

シナリオ: あなたは GKE クラスタを運用しており、開発者が誤って不正な K8s リソース（特権 Pod、未承認 Image など）をデプロイするのを防ぎたいと考えています。OPA（Open Policy Agent）/ Gatekeeper ベースのポリシー強制を導入する方針です。

質問: GCP で K8s リソースのポリシー強制に最適なサービスはどれですか。

選択肢:

A. Organization Policy
B. Policy Controller（旧 Anthos Config Management）
C. Cloud Armor
D. VPC Service Controls

解答と解説

正解: B

解説:

B が正解: Policy Controller は GKE Enterprise の一部で、Gatekeeper（OPA）をベースに K8s リソースのポリシー強制を行います。特権 Pod 禁止、ラベル必須、Image レジストリ制限などを Constraint として定義可能。
A 不正解: Organization Policy は GCP リソース のポリシー強制で、K8s 内リソースではありません。
C 不正解: Cloud Armor は L7 ファイアウォール（WAF）で、K8s ポリシーではありません。
D 不正解: VPC Service Controls はネットワーク境界制御です。

ひっかけポイント: ポリシー強制の使い分け: Organization Policy（GCP リソース）/ Policy Controller（K8s リソース）。両者を混同しないこと。

関連リソース:

../02_学習資料/06_運用卓越性/02_応用.md

問題 18 （難易度: ★★★）

シナリオ: Cymbal Retail は本番障害発生後の Postmortem を実施しました。SRE リードは「次回の障害を未然に防ぐため、過去 5 件の障害事例から運用ランブックを自動生成したい」と考えています。AI 支援で人手作業を減らす方針です。

質問: この用途に最適な機能はどれですか。

選択肢:

A. Gemini Cloud Assist の Runbook 生成機能
B. Cloud Source Repositories の自動ドキュメント生成
C. Cloud Build のテンプレートジェネレーター
D. Vertex AI Workbench のノートブック自動生成

解答と解説

正解: A

解説:

A が正解: Gemini Cloud Assist には過去の障害対応履歴からランブックを自動生成する機能があります。Postmortem の知見を再利用可能な運用ドキュメントに変換できます。
B 不正解: Cloud Source Repositories は Git ホスティングで、ランブック生成機能はありません。
C 不正解: Cloud Build のテンプレートは CI/CD 用で、ランブック生成ではありません。
D 不正解: Vertex AI Workbench は ML 開発用ノートブックで、運用ランブックではありません。

ひっかけポイント: Gemini Cloud Assist の機能は Investigations / Log + Gemini / Alert Summarization / Runbook 生成 の 4 つを覚える。

関連リソース:

../02_学習資料/06_運用卓越性/02_応用.md

問題 19 （難易度: ★★）

シナリオ: あなたは SRE として、運用工数の削減を目指しています。Google SRE Book を参考に、開発者がコードを書くべき時間を確保するために、繰り返し性のある手作業（Toil）を削減したいと考えています。

質問: Google SRE が推奨する Toil の許容上限はどれですか。

選択肢:

A. 30% 以下
B. 50% 以下
C. 70% 以下
D. 90% 以下

解答と解説

正解: B

解説:

B が正解: Google SRE Book では、エンジニアの作業時間に占める Toil（手作業）の上限を 50% に設定するのが推奨。残り 50% は自動化・改善・開発に充てます。Toil が 50% を超えると、SRE は単なる運用要員になってしまい、長期的な信頼性改善ができません。
A 不正解: 30% は厳しすぎる。理想的だが現実的でない場合もあり、50% が公式上限。
C 不正解: 70% は超過。
D 不正解: 90% は完全に運用要員化した状態で、SRE 文化が機能していません。

ひっかけポイント: Toil 50% の数値は 暗記必須。SRE と通常の Ops の違いを表す重要指標。

関連リソース:

../02_学習資料/06_運用卓越性/03_要点と暗記.md

問題 20 （難易度: ★★★）

シナリオ: KnightMotives Automotive は本番アラート疲れに悩まされています。1 日 500 件以上のアラートが Slack に流れ、本当に重要なものが埋もれてしまいます。SRE リードとして、効果的なアラート戦略を組み立て直す必要があります。Google SRE ベストプラクティスに準拠した設計を求められています。

質問: 良いアラート設計の原則として 適切な記述を 3 つ 選びなさい。

選択肢:

A. 症状ベース（ユーザー影響）で発報する
B. アクション可能（受信者が対応できる）であること
C. SLO Burn Rate ベースで発報し、Multi-window を使う
D. CPU / メモリ % など静的しきい値で網羅的に監視する
E. 全アラートを Critical 優先度で送信する

解答と解説

正解: A, B, C

解説:

A が正解: 症状ベース は SRE ベスプラ。CPU % のような原因ベースではなく、「ユーザーが実際に困っているか」を測ります（例: 5xx エラー率）。
B が正解: アクション可能 は必須。受信者が対応できないアラートはノイズ。Runbook へのリンクを添付するのが推奨です。
C が正解: SLO Burn Rate + Multi-window（5min × 14.4x、1h × 6x、6h × 1x）が SRE 標準。
D 不正解: 静的しきい値の網羅は アラート疲れの元凶。症状ベース + SLO Burn Rate に置き換えるべきです。
E 不正解: 全 Critical は無意味。Severity（Critical / Warning / Info）を使い分け、Notification Channel を振り分けるのが正解です。

ひっかけポイント: 良いアラート 3 原則: 症状ベース / アクション可能 / SLO Burn Rate。Anti-pattern: 静的しきい値、全 Critical、原因ベース。

関連リソース:

../02_学習資料/06_運用卓越性/02_応用.md

正答率早見表

問題	難易度	主トピック	正解
1	★	SLI/SLO/SLA 定義	B
2	★★	エラーバジェット計算	B
3	★★	Managed Prometheus	B
4	★★★	Multi-burn-rate Alert	A, B
5	★★	Forecast Alert	C
6	★★	Data Access Audit Logs	B
7	★★★	Load Test	A
8	★★	Chaos Engineering	B
9	★★	Pentest（GCP 規約）	B
10	★★★	ICS - IC 役割	C
11	★★	Cloud Trace	C
12	★★	Cloud Profiler	B
13	★★	Aggregated Sink	A
14	★★★	Gemini Cloud Assist Investigations	C
15	★★	Feature Flag	C
16	★★	Assured Workloads	B
17	★★	Policy Controller	B
18	★★★	Gemini Runbook 生成	A
19	★★	Toil 50%	B
20	★★★	良いアラート 3 原則	A, B, C

弱点別復習ガイド

正答率が低かった分野に応じて、以下の学習資料に戻ってください。

弱点分野	関連問題	復習リソース
SLO / SLI / SLA / エラーバジェット	1, 2, 19	`../02_学習資料/06_運用卓越性/02_応用.md` §「SRE 用語」「エラーバジェット」
Observability（Monitoring / Logging / Trace / Profiler）	3, 11, 12, 13	`../02_学習資料/06_運用卓越性/02_応用.md` §「Observability 4 大柱」「Managed Prometheus」
アラート戦略（Multi-burn / Forecast）	4, 5, 20	`../02_学習資料/06_運用卓越性/02_応用.md` §「アラート戦略」
Audit Logs / コンプラ	6, 13, 16	`../02_学習資料/06_運用卓越性/02_応用.md` §「Audit Logs」「Assured Workloads」
信頼性検証（Load / Chaos / Pentest）	7, 8, 9	`../02_学習資料/06_運用卓越性/02_応用.md` §「Chaos Engineering」「Load Test」「Pentest」
インシデント対応（ICS）	10	`../02_学習資料/06_運用卓越性/02_応用.md` §「Incident Command System」
デプロイ管理（Feature Flag / Approval）	15	`../02_学習資料/06_運用卓越性/02_応用.md` §「デプロイ戦略」「Cloud Deploy」
ポリシー強制（Policy Controller / Org Policy）	16, 17	`../02_学習資料/06_運用卓越性/02_応用.md` §「Policy Controller」「Organization Policy」
Gemini Cloud Assist（運用 AI）	14, 18	`../02_学習資料/06_運用卓越性/02_応用.md` §「Gemini Cloud Assist」

推奨復習サイクル

誤答した問題のみを翌日に再演（メタ認知の強化）
3 日後に全 20 問を再演（記憶定着確認）
1 週間後に模擬試験で総合演習 → ../04_模擬試験/ 配下

3 セクション問題集完了 → 全 60 問の総合復習後、../04_模擬試験/ で本番形式 50 問演習へ進む。