PCDE 合格対策

📝 PCDE 問題演習（30 問・自動採点）

公式試験ガイド（2025 年改訂）準拠で全 5 セクションから厳選した 30 問。出題比重に合わせて S1=6 問、S2=8 問（★最大ウェイト）、S3=5 問、S4=8 問（★最大ウェイト）、S5=3 問。選択肢を選んで「採点する」を押すと、その場で正誤判定とポイント解説が表示されます。

📝 30 問 ⏱ 目安 50 分 🎯 合格圏 70%+ 🔁 リセット可 ✅ 自動採点
💡 使い方① 各問で選択肢を選ぶ（複数選択は指定数だけ）→ ② 「採点する」で自動採点 → ③ 解説の「なぜ他の選択肢がダメか」まで読む。目標は 70% 以上。本番同様、迷ったら消去法で。チップ：📘 基礎 🔧 応用 🎯 発展 複数選択

📑 セクション別ジャンプ

S1

組織と基盤

20% / 6 問

 S2 ★

CI/CD パイプライン

25% / 8 問

 S3

SRE プラクティス

18% / 5 問

 S4 ★

可観測性

25% / 8 問

 S5

FinOps

12% / 3 問
🔑 本番試験での解答テクニック

セクション 1：組織と基盤の Bootstrap（20% / 6 問）

出題範囲：リソース階層 / Shared VPC / IaC（Infrastructure Manager / CFT / Config Connector）/ Workload Identity Federation / GKE Fleet / Config Sync / Policy Controller / Cloud Workstations / Gemini。

Q1S1🔧単一選択

シナリオ：Cymbal Bank は地方銀行 50 社の共同利用型基盤を GCP に構築。各銀行ごとに独立した課金・IAM 境界を持ちつつ、共通の VPC 基盤・監査ログ集約・Org Policy を中央 Platform チームが制御したい。1 銀行あたり 5〜10 プロジェクト、将来 100 社まで拡張予定。サブネット範囲は重複させたくない。

質問：最も適切なリソース階層・ネットワーク設計はどれですか。

正解：C
銀行ごとの課金・IAM 境界（プロジェクト分離）を保ちつつ、中央 Platform チームが Shared VPC のホストプロジェクトでサブネット範囲・ファイアウォール・Interconnect を統制できる。Google Enterprise Foundations Blueprint の標準パターン。
❌ A：課金・IAM・Quota が銀行間で混ざり規制上 NG。❌ B：Organization を分けると Shared VPC が使えない（同一 Org 限定）。❌ D：NCC はオンプレ・他クラウド含む WAN 統合向け。同一 Org 内集中管理は Shared VPC が第一選択。
Q2S1🎯単一選択

シナリオ：SaaS 企業 LedgerPro は GitHub Actions から GCP にデプロイ。CISO 監査で「SA キーが GitHub Secrets に保管されている」ことが指摘され、6 か月以内にキー廃止が要求された。特定リポジトリの main ブランチからのワークフローのみ本番 SA を使用可能にしたい。

質問：最小権限で SA キーを廃止する設定として最も適切なのは。

正解：A
Workload Identity Federation で OIDC ベースの STS 認証を行い、principalSet の Attribute Condition で「特定リポジトリ × 特定ブランチ」のみ SA Impersonation を許可するのが Google 推奨。SA キー完全廃止が可能。
❌ B：Self-hosted Runner はインフラ管理負担増。❌ C：要件は「GitHub Actions からデプロイ」を維持。❌ D：SA キー自体が存在し続け、漏洩リスクと監査指摘は解消しない。
Q3S1📘単一選択

シナリオ：GameStudio ZeroOne は新規 GCP プロジェクトで IaC を導入。要件は (1) GCP 専用、(2) Terraform を使いたい、(3) State 管理・Lock 制御の運用負担を最小化、(4) Cloud Build から IAM ベースで実行したい。マルチクラウド要件はない。

質問：最も適合する IaC ツールはどれですか。

正解：B
Infrastructure Manager は GCP マネージド Terraform 実行サービス。State 管理・Lock 制御を GCP が肩代わり。IAM ベースで API 呼び出し可能、Cloud Build から実行できる。要件 (1)(2)(3)(4) を全て満たす。
❌ A：State Bucket・Lock の運用を自前管理する必要があり要件 (3) を満たしにくい。❌ C：既存 K8s クラスタが必要。❌ D：CFT はブループリント集であり実行手段ではない。
Q4S1🔧単一選択

シナリオ：IoT 企業 SensorWave は GKE 運用基盤を持ち K8s 文化が浸透。CI/CD は ArgoCD で GitOps を実装済。GCP リソース（Cloud SQL、Pub/Sub、GCS）も同じ GitOps フローで「マニフェスト → kubectl apply → 反映」したい。Terraform 新規導入は学習コスト高で避けたい。

質問：最も適合する IaC アプローチはどれですか。

正解：B
Config Connector は GCP リソースを Kubernetes CRD として定義し kubectl apply で作成・更新できる。ArgoCD の GitOps フローに自然統合され、K8s リコンシリエーションで差分修正も自動化。「K8s 文化が強い組織が GCP リソースも K8s で管理したい」要件の Google 標準解。
❌ A：Terraform 新規導入は要件と矛盾。❌ C：Infrastructure Manager は ArgoCD ネイティブ統合ではない。❌ D：Cloud Deploy はアプリのデプロイが主用途。
Q5S1🎯単一選択

シナリオ：グローバル SaaS の OmniSync は東京・米国・欧州・オンプレ（GKE on bare metal）で合計 12 GKE クラスタを運用。すべてのクラスタに同一の Network Policy、PodSecurity ポリシー、Namespace 構成を Git から自動同期したい。さらに team ラベル必須・特権コンテナ禁止などのポリシー違反を検出・拒否したい。

質問：最も適切な GCP サービス組み合わせは。

正解：B
GKE Fleet はマルチクラスタ管理の論理単位。Config Sync で Git → Fleet 内全クラスタへマニフェスト一括同期、Policy Controller（OPA/Gatekeeper）で Constraint Template によるポリシー強制が可能。オンプレ含むハイブリッド構成にも対応（GKE Enterprise）。
❌ A：個別 Argo CD は集中管理にならず運用負担増。❌ C：Terraform は静的、リコンシリエーションがない。❌ D：Cloud Deploy はアプリデプロイ用、ポリシー強制機能なし。
Q6S1🎯複数選択（3 つ選べ）

シナリオ：グローバル製造業 FactoryNet は GCP に 200 プロジェクトを持ち、SOC2 監査で「監査ログ（Admin Activity / Data Access）を 10 年保管」「Org 全体で 1 か所に集約」「BigQuery で SQL 分析」「セキュリティ重大度の高いものは即時 Pub/Sub 通知」が要求されている。Logging の _Required バケットは 400 日固定で要件を満たさない。

質問：この要件を満たす Logging アーキとして最も適切な組み合わせを 3 つ選びなさい。

正解：A, C, D
A：Org Aggregated Sink + --include-children で配下全プロジェクトの監査ログを一括集約。GCS は長期保管・低コスト（10 年保管に最適）。C：BigQuery で SQL 分析。D：重大度フィルタ Sink を Pub/Sub に流しリアルタイム通知。
❌ B：200 プロジェクトで個別 Sink は運用負荷大。Aggregated Sink が正解。❌ E：_Required バケットは 400 日固定で変更不可。誤答誘発の典型ひっかけ。

セクション 2：CI/CD パイプラインの構築と実装（★25% / 8 問）

出題範囲：Cloud Build / Cloud Deploy / Artifact Registry / Binary Authorization / Workload Identity Federation / SLSA / Software Delivery Shield / Secret Manager。試験で最大ウェイト。

Q7S2🔧単一選択

シナリオ：Cymbal Bank の SRE チームは、毎晩深夜の脆弱性スキャン結果を Pub/Sub に publish している。CVE が HIGH 以上で検出されたコンテナイメージを自動的に再ビルド・再デプロイするパイプラインを構築したい。GKE 上で稼働、Cloud Build を CI、Cloud Deploy を CD に使用。

質問：このイベント駆動の自動再ビルドを最も適切に実現する Cloud Build トリガー設定は。

正解：B
Cloud Build の Pub/Sub トリガーは、Pub/Sub トピックにメッセージが届くたびにビルドを起動できる。--substitutions='_IMAGE=$(body.message.data.image)' のように Pub/Sub メッセージ本文の値を substitution として取り込めるため、CVE 検出 → メッセージ送出 → 再ビルドの自動化に最適。
❌ A：スケジュールではイベント駆動にならず無駄が発生。❌ C：Pub/Sub → CF → Webhook と中継が増え不必要に複雑。❌ D：手動承認は自動化要件を満たさない。
Cloud Build には 7 種類のトリガー（push / PR / tag / manual / webhook / pubsub / scheduled）がある。
Q8S2🔧単一選択

シナリオ：Altostrat Retail はマイクロサービス 30 個を GKE で運用。各サービスは個別のパイプラインを持ち、リリース時に dev → staging → prod という 3 段階を経て、prod は米国・欧州・アジアの 3 リージョンに同時並列デプロイしたい。

質問：Cloud Deploy で、最後の prod ステージのみ 3 リージョン並列展開する最も適切な構成は。

正解：B
Cloud Deploy の multiTarget は、複数の子 target を同時並列に展開する公式機能。1 つの Release から 3 リージョンへ並列デプロイが可能で、いずれかが失敗すれば multi-target rollout 全体が FAILED になる。
❌ A：3 本のパイプラインに分けると Release の一貫性が保てない。❌ C：Multi-Cluster Ingress はトラフィック制御で CD の並列実行とは別レイヤ。❌ D：customCanary は同一ターゲット内のトラフィック比率制御で、リージョン分割の手段ではない。
Q9S2🔧単一選択

シナリオ：EHR Healthcare（医療 SaaS、HIPAA 規制下）の社内ポリシーで「本番デプロイは main ブランチからのみ・要承認・複数人レビューが必須」と定められている。リリースを作る人と承認する人を別人物にしなければならない。

質問：Cloud Deploy で職務分掌（separation of duties）を実装する最も適切な IAM 設計は。

正解：B
Cloud Deploy には専用ロール roles/clouddeploy.releaser（release 作成・promote）と roles/clouddeploy.approver（承認のみ）が用意されている。Target 定義に requireApproval: true を入れることで prod デプロイは PENDING_APPROVAL で停止し、別人物の承認が必須になる。
❌ A：admin を両方に付けると職務分掌が崩れる。❌ C：GitHub PR レビューはソースコード変更レビューで、Cloud Deploy のデプロイ承認とは別レイヤ。❌ D：viewer は閲覧のみで承認権限がない。
Q10S2🎯単一選択

シナリオ：Shipping Co. のチームは Cloud Build から VPC 内のプライベート GKE クラスタの API サーバとオンプレ DB（Cloud Interconnect 経由）に接続してデプロイ・データマイグレーションを実行する必要がある。現在はデフォルトの Cloud Build プールを使っているが、両方への接続が失敗する。

質問：この問題を解決する最も適切な構成は。

正解：B
デフォルト Cloud Build プールは Google マネージドの共有環境でユーザー VPC にはアクセスできない。Private Pool（Worker Pool）を作成すると VPC ピアリング / PSC で顧客 VPC とつなぎ、プライベート GKE エンドポイント・Cloud SQL・オンプレ DB（Interconnect 経由）へアクセス可能になる。
❌ A：デフォルトプールに --network オプションは存在しない。❌ C：Cloud Functions は CI ステップの代替にならない。❌ D：プライベート GKE の意味がなくなる。
Q11S2🎯単一選択

シナリオ：金融 FinTrust は GKE 上でアプリを運用。本番デプロイは「Cloud Build で署名されたイメージのみ許可」「未署名イメージはデプロイブロック・監査ログ出力」「gcr.io/google_containers/* は例外」という方針。SOC2 監査でサプライチェーンの完全性を示す必要がある。

質問：最も適切な GCP サービス組み合わせは。

正解：B
Binary Authorization はデプロイ前にイメージの署名・属性検証を行う Admission Controller。evaluationMode: REQUIRE_ATTESTATION で署名必須、enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG でブロック＋監査ログ、admissionWhitelistPatterns で例外指定が公式パターン。
❌ A：Vulnerability Scanning は脆弱性検出であり署名検証ではない（Artifact Analysis の機能）。❌ C：NetworkPolicy は Pod 間通信制御で署名検証ではない。❌ D：Cloud Deploy verify はデプロイ後のテスト実行用で Admission 制御ではない。
Q12S2🔧単一選択

シナリオ：SaaS の WorkTrack は本番 Web アプリを GKE で運用。デプロイは現在 kubectl rollout 一括で、リリース後にエラー率増加に気づくケースがあった。今後は「最初 5% トラフィック → 10 分間メトリクス検証 → 25% → 検証 → 100%」という段階的リリース・自動検証・自動ロールバックを GCP マネージドで実現したい。

質問：最も適切な実装は。

正解：B
Cloud Deploy の Canary 戦略は percentages で段階的にトラフィック移行、verify: true で自動検証ステップを挟み、失敗時は自動ロールバックが可能。GKE / Gateway API / Service Mesh と統合済み。
❌ A：自前実装は再現性・運用負担が大きくマネージド要件と矛盾。❌ C：GCP マネージド要件のためサードパーティ Argo Rollouts は不適。❌ D：GKE から Cloud Run へのアーキ変更は要件外。
Q13S2🔧複数選択（3 つ選べ）

シナリオ：EC の RetailJet は Artifact Registry に Java（Maven）、Node（npm）、コンテナイメージを保管している。コスト調査で 3 年分のイメージが溜まりストレージ費が月 USD 4,000 に。古いイメージは利用されていない。さらに開発チームから「DockerHub レートリミットでビルド失敗」「同じ URL で本番用と開発用イメージを切り替えたい」という要望がある。

質問：この要件を満たす Artifact Registry の機能の組み合わせとして正しいものを 3 つ選びなさい。

正解：A, B, C
A：Cleanup Policies は条件（age / keep latest N 等）で古いイメージを自動削除しストレージ削減。B：Remote Repository は DockerHub / Maven Central 等を AR がキャッシュする方式でレート制限回避とビルド高速化を実現。C：Virtual Repository は複数の upstream（Remote / Standard）を 1 つの URL で公開でき本番・開発の切替を URL を変えずに行える。
❌ D：リージョン移行はコスト解決ではない。❌ E：Container Registry は新規利用不可（deprecated）、ダウングレードは禁忌。
Q14S2🎯単一選択

シナリオ：サプライチェーン信頼性監査で、ビルドアーティファクトについて「誰が・いつ・どのソースから・どのビルダーで作ったか」を示す改ざん防止メタデータが要求された。さらに hermetic build（外部依存を排除した再現可能ビルド）の証拠も必要。

質問：この要件を満たす最も適切な仕組みは。

正解：C
Cloud Build は SLSA Level 3 相当の provenance.json を自動生成し、Artifact Registry のイメージにメタデータとして付与する。これにより hermetic build + 改ざん防止 provenance + 認証済みビルドサービスの 3 要件を満たす。Binary Authorization の attestor で provenance を検証してデプロイ判定。
❌ A：Level 1 は文書化のみで改ざん防止なし。❌ B：SBOM は部品表で provenance とは別概念。❌ D：コミットハッシュだけではビルドの真正性は示せない。

セクション 3：SRE プラクティスの適用（18% / 5 問）

出題範囲：SLI / SLO / SLA / Error Budget / Multi-burn-rate / Service Lifecycle / Quotas / Reservations / DWS / オートスケール / インシデント緩和。

Q15S3📘単一選択

シナリオ：Cymbal Bank の決済 API チームは SLI / SLO / SLA を初めて整理。マーケティングは「99.9% を顧客契約に書く」、開発リーダーは「内部の判断基準として 99.95% を持ちたい」、SRE は「実測は過去 28 日 99.97% だった」と発言。

質問：SLI / SLO / SLA の数値関係として適切に整列している組み合わせは。

正解：B
SLI（実測）が最も高く、SLO（内部目標）は SLI 実績にバッファを持たせて低めに、SLA（顧客契約）はさらに下に置くのが SRE Book の原則。実測 99.97% > 内部目標 99.95% > 契約 99.9% の順。
❌ A：SLI < SLA になっている時点で誤り（実測が契約を下回ると返金事案）。❌ C/D：順序が逆。
Q16S3🔧単一選択

シナリオ：あなたの API は SLO 99.9%（30 日 rolling）で運用。今月の 15 日時点で累計ダウンタイムは 22 分。

質問：残りのエラーバジェットは何分？ 残期間（15 日間）で同じ消費ペースを続けた場合、月末時点で SLO は達成できるか。

正解：A
月の総時間 = 30 × 24 × 60 = 43,200 分 / Error Budget = 0.1% × 43,200 = 43.2 分/月 / 15 日時点で 22 分消費 → 残予算 = 43.2 − 22 = 21.2 分 / 半月で 22 分使ったペース → 月末で 44 分消費見込み → 43.2 分を 0.8 分超過 → SLO 違反。
❌ B：43.2 分は月初時点の予算。❌ C：月末で 44 分消費見込みなのに「予算内」は計算誤り。❌ D：残予算 10 分は誤り。
Q17S3🎯単一選択

シナリオ：SLO 99.9%（30 日 rolling）の API があり、Cloud Monitoring で Multi-window multi-burn-rate アラートを設定したい。SRE Workbook の推奨に従って「Fast burn（クリティカル：Budget の 2% を 1 時間で消費するペース）」を設定する場合。

質問：推奨される Fast burn アラートの設定値は。

正解：C
SRE Workbook Ch.5「Alerting on SLOs」の推奨は Fast burn = 14.4x / long 1h / short 5m。1 時間で予算の 2% を消費するペース（14.4 × 1h × 0.1% ≈ 2% × 43.2 分）に相当。long window で長期傾向、short window で誤検知防止の AND 条件。
❌ B：Medium burn（6x / 6h / 30m）。❌ A：Slow burn（1x / 3d / 6h）に近い。❌ D：60x ではアラートが遅すぎる。
Q18S3🔧単一選択

シナリオ：SLO 99.9% の API を運用中、過去 5 分間で 10,000 リクエスト中 600 件が 5xx だった。

質問：この期間の Burn rate はいくつ？ Fast burn alert（threshold 14.4x）は発火する？

正解：C
エラー率 = 600 / 10,000 = 6% / Error Budget = 1 − SLO = 1 − 0.999 = 0.1% / Burn rate = エラー率 / (1 − SLO) = 6% / 0.1% = 60x / 60x > 14.4x なので Fast burn alert は発火。
Burn rate の式 = エラー率 / (1 − SLO) を即答できること。「Burn rate 1x = SLO 期間（30 日）でちょうど予算を使い切る速度」「60x = 約 12 時間で予算枯渇」の感覚を持つ。
Q19S3🔧単一選択

シナリオ：新しいリコメンデーション API の SLI を設計中。チームから候補：(1) Pod の平均 CPU 使用率、(2) クラスタの Node 数、(3) HTTP 5xx エラー率、(4) p99 レスポンスタイム。

質問：SRE Workbook の SLI 選定原則（ユーザーに影響する指標を選ぶ）に最も合致する SLI の組み合わせは。

正解：B
SLI は ユーザーが直接気にする指標 を選ぶ原則。HTTP 5xx 率（成功/失敗）と p99 レイテンシは、ユーザー体験を直接反映する。
❌ CPU 使用率や Node 数は内部リソース指標であり、ユーザー体験を直接表さない。CPU が 90% でもユーザーが問題なく応答を受けていれば SLO は満たしている。
SRE Workbook Ch.2 の SLI 選定 4 原則：(1) ユーザーが気にする、(2) 集計可能、(3) シンプル、(4) 構造化。

セクション 4：可観測性の実装とトラブルシュート（★25% / 8 問）

出題範囲：Ops Agent / OpenTelemetry / Cloud Logging / LQL / Sink / Cloud Monitoring / GMP / PromQL / Cloud Trace / Cloud Profiler / Cloud Service Mesh / Gemini Cloud Assist。試験で最大ウェイト。

Q20S4📘単一選択

シナリオ：Cymbal Retail は約 800 台の Compute Engine VM 上でレガシーモノリスを稼働。これまで Legacy Logging Agent（fluentd ベース）と Legacy Monitoring Agent（collectd ベース）を個別にインストールしていた。SRE チームはエージェント管理を統合し、Google が今後機能追加する基盤に揃えたい。

質問：推奨されるエージェント構成は。

正解：B
Ops Agent はログ（fluentbit）とメトリクス（OpenTelemetry）を統合した次世代の単一エージェントで Google Cloud の推奨。Legacy エージェントは新機能の追加が停止。
❌ A：Legacy は非推奨。❌ C：自前 Collector 運用は管理コスト増。❌ D：VM のシステムメトリクスまで自前計装するのは非現実的。
Q21S4🔧単一選択

シナリオ：GKE 上で動くマイクロサービス群があり、OpenTelemetry SDK で計装済み。アプリは大量のトレースを生成するが、エラーや遅い trace は確実に保持しつつコストは抑えたい。OTel Collector を Sidecar / DaemonSet で導入する設計。

質問：Collector に設定すべきサンプリング戦略は。

正解：B
Tail-based sampling はトレース完了後に内容を見て判断するため、エラーや高レイテンシなど「価値の高い trace」を 100% 保持できる。これは OTel Collector でしか実現できない（SDK 側 = Head-based では trace 開始時に判定するため不可能）。
❌ A：Head-based の確率サンプリングではエラー trace が捨てられるリスク。❌ C：コストが下がらない。❌ D：Batch Processor は送信のバッチ化用でサンプリングではない。
Q22S4🔧単一選択

シナリオ：医療系 SaaS の Cymbal Health は HIPAA 監査対応として「誰が患者データを読んだか」「誰が IAM ポリシーを変更したか」「誰のアクセスが VPC Service Controls で拒否されたか」を 7 年間保管する必要がある。

質問：追加で有効化が必要な Cloud Audit Logs は。

正解：B
Data Access logs だけがデフォルトで無効（BigQuery 除く）。HIPAA / PCI / SOX 等のコンプラ対応では明示的に有効化する必要がある。
❌ A：Admin Activity（IAM 変更等）は常時有効、無効化不可、無料。❌ C：System Event は GCP 内部イベント。常時有効、無効化不可。❌ D：Policy Denied は VPC SC / IAM 拒否。常時有効、無効化不可。
_Required バケット（Admin Activity / System Event）は 400 日固定、_Default（Data Access / Policy Denied）は 30 日（変更可）。7 年保管なら Sink で BQ / GCS Archive へエクスポート。
Q23S4🔧単一選択

シナリオ：ネットワーク管理者が「特定の VM から Cloud SQL に接続できない」報告を受けた。原因が VPC 設定（ルート / FW / NAT / Private Service Connect 等）にあるのかを、トラフィックを発生させずに構成解析だけで特定したい。

質問：最初に使用すべきツールは。

正解：B
Connectivity Tests は実トラフィックを送らず、VPC のルート / FW / NAT / Private Google Access / PSC 等の構成を解析し到達性とブロック箇所を特定する。
❌ A：VPC Flow Logs は実フロー記録。構成解析で当たりをつけるのが先。❌ C：Performance Dashboard はインフラのパケットロス全体傾向。❌ D：Firewall Insights は FW ルールの使用状況分析。
Q24S4🔧単一選択

シナリオ：既存 OSS Prometheus + Grafana を運用していたが、シャーディング・HA・長期保持の運用負荷が高く、PromQL は維持しつつマネージドに移行したい。さらに新規 GKE クラスタには Day 1 から Google 推奨の構成で導入したい。

質問：最適な構成の組み合わせは。

正解：B
Managed Service for Prometheus (GMP) は OSS Prometheus と PromQL 100% 互換で最大 24 ヶ月保持、自動スケール・HA を提供。Self-deployed Collection は既存の prometheus.yml / Operator をそのまま使いつつバックエンドだけ GMP に切り替える方式、Managed Collection は GKE Add-on で Google が Collector を管理する方式（新規推奨）。
「既存 Prometheus がある」→ Self-deployed、「新規 GKE」→ Managed が暗記キー。
Q25S4🔧単一選択

シナリオ：EC プラットフォーム ShopWave の月次請求書を確認したところ、Cloud Logging Ingestion 課金が先月の 3 倍（USD 18,000）に増えていた。原因を調査すると、GKE クラスタの Liveness/Readiness Probe（User-Agent: kube-probe/1.27）のヘルスチェックログが大量に取り込まれていることが判明。本番運用上、これらのログを残す必要はない。ingestion 課金を直接削減したい。

質問：最も効果が大きい対策は。

正解：B
課金は取り込み量ベースなので、Exclusion で取り込み自体を 0 にするのが最速・最大効果。優先順位は Exclusion > Sampling > Retention 短縮 > Bucket 整理。
❌ A：別 Sink 追加は課金増。❌ C：Retention はストレージ課金のみに効くが、取り込み課金の方が大きいため効果限定。❌ D：クォータ削減はアプリ側 429 エラーや書き込み失敗を招く。
Q26S4🎯単一選択

シナリオ：GKE で稼働する HTTP サービスについて、Managed Service for Prometheus にメトリクス http_request_duration_seconds_bucket{service, le} が記録されている。サービス別に p99 レイテンシをダッシュボードに表示したい。

質問：正しい PromQL クエリは。

正解：C
Prometheus の histogram は _bucket カウンタを rate() してから le ラベルを残しつつ集約し、histogram_quantile(0.99, ...) で p99 を算出。サービス別表示は sum by (le, service) で service を残す。
分位点の定型句：histogram_quantile(q, sum by (le, <group_labels>) (rate(*_bucket[range])))。le を集約から落とすと壊れる。
❌ A：rate だけでは分位点にならない。❌ B：bucket の値を avg するのは数学的に無意味。❌ D：topk は別用途。
Q27S4🎯単一選択

シナリオ：SRE オンコール担当者が「先週 1 時間あたり 5xx エラーが急増したサービスを特定したい」「特定アラートが鳴った根本原因の仮説を素早く欲しい」と考えている。Logs Explorer / Metrics Explorer に詳しくない経験浅めのエンジニアでも対応できる仕組みを導入したい。

質問：最も効果が大きい新機能は。

正解：C
Gemini Cloud Assist（2024 GA）は (1) 自然言語からの LQL/PromQL 生成、(2) アラート起点の Investigations（最近のデプロイ・変更を相関し根本原因仮説を提示）、(3) Explain this chart（メトリクス解釈）、(4) Summarize trace / log を提供し MTTR を大きく短縮。
❌ A：MQL は非推奨で PromQL に統一されつつある。❌ B：Looker Studio は BI 用で MTTR 短縮には直結しない。❌ D：スキル習得は時間がかかる。

セクション 5：パフォーマンス & コスト最適化（12% / 3 問）

出題範囲：Cloud Profiler / Trace / APM / Active Assist / Recommender / Spot / CUD / SUD / Network Tier / FinOps。

Q28S5🔧単一選択

シナリオ：ゲーム配信スタートアップ ArenaCast は Go 製のマッチメイキングサービスを GKE で運用。SRE から「p95 レイテンシが 250ms から 800ms に悪化したが、CPU 使用率は 30% のまま変化していない」と報告。Cloud Monitoring で確認しても CPU・メモリは正常、Cloud Trace では「アプリ内部の処理時間」が伸びていることだけ判明。コード行レベルでボトルネックを特定したい。

質問：Cloud Profiler で最初に確認すべきプロファイル種別は。

正解：C
Wall-clock time は I/O 待ち・ロック待ち・外部 API 待ちを含む経過時間を測るため、「CPU は低いがレイテンシが長い」症状の第一選択。DB 呼び出しや外部 HTTP 待ち、sync.Mutex の待機などが見える。Go は Wall-clock を goroutine プロファイル経由で完全サポート。
マッピング：「レイテンシ長 + CPU 低」= Wall-clock、「CPU 高」= CPU、「メモリ膨張」= Heap。
❌ A：CPU 使用率が低い症状では薄い。❌ B：Heap は OOM やメモリ膨張用。❌ D：Goroutine 数のリーク調査用。
Q29S5📘単一選択

シナリオ：グローバル SaaS の InsightCorp は Org 配下に 300 プロジェクト。FinOps チームは「全プロジェクト横断で節約見込み額が大きい順にコスト最適化推奨を確認し、毎週 Slack に Top 10 を投稿したい」。手動で各プロジェクトの Console を巡回するのは非現実的。

質問：最も適切な実装アプローチは。

正解：B
Recommender API の BigQuery Export を有効化すると、全プロジェクト・全カテゴリの推奨が recommendations_v1 テーブルに集約され、primary_impact.cost_projection.cost.units（節約は負の値）で順位付け可能。Cloud Scheduler（cron）→ Cloud Functions → Pub/Sub → Slack が Google 公式パターン。Recommendation Hub を Org スコープで開くと UI でも横断確認可能。
Recommender は API / BigQuery Export / Recommendation Hub の 3 経路でアクセス可能。「組織横断 + 自動化」が条件のときは BigQuery Export + Pub/Sub パターン。
Q30S5🔧単一選択

シナリオ：セキュリティ監査で「サービスアカウントに過剰な IAM 権限が付与されている」と指摘を受け、Cymbal Bank はラテラルムーブメント（権限を踏み台にした横断的攻撃）リスクの可視化と是正を求められた。「何が事実か（現状）」と「何をすべきか（処方箋）」を分けて報告する必要がある。

質問：Active Assist の機能の使い分けとして最も適切なものは。

正解：B
Active Assist は Insights（事実）と Recommendations（処方箋）の二段構成。Lateral movement insight は SA 間の過剰権限による横断的攻撃可能性を検出（事実）、IAM Recommender（Policy Recommender）が過剰権限を実使用ベースで削減提案（処方箋）。Insight が「血液検査の結果」、Recommendation が「処方箋」の関係。
❌ A：Idle VM Recommender は Cost カテゴリで、Security 要件とずれる。❌ C：SCC の脆弱性スキャンは CVE 検出で IAM 過剰権限の最適化ではない。❌ D：VPC SC は境界制御で IAM 権限の最適化機能ではない。
Recommender 5 カテゴリ（Cost / Security / Performance / Manageability / Reliability）の即答が必要。
🔑 採点後のアクション

📚 セクション別の追加問題

各セクションの問題集（MD 版）にはさらに詳細な問題があります（計 105 問）：

S1

組織と基盤

20 問・制限時間 30 分

 S2 ★

CI/CD パイプライン

25 問・制限時間 40 分

 S3

SRE プラクティス

20 問・制限時間 30 分

 S4 ★

可観測性

25 問・制限時間 50 分

 S5

FinOps

15 問・制限時間 25 分

 模試

模擬試験 (100 問)

本番形式・2 時間 × 2 回
用語集で復習 → ロードマップ ← ホームへ