Section 4 問題集: 可観測性の実装とトラブルシュート

試験出題比率: 約 25%（PCDE 試験で最大ウェイト ★最重要） 試験ガイド対応: 2024 年改訂版（Gemini Cloud Assist / GMP / Cloud Service Mesh 反映） 収録問題数: 25 問

学習方針

このセクションは PCDE 試験で最大の比重を占める「可観測性とトラブルシュート」を扱います。 4.1 テレメトリ計装 / 4.2 ログ管理 / 4.3 メトリクス・ダッシュボード・アラート / 4.4 分散トレース / 4.5 トラブルシュートの 5 領域から幅広く出題されます。

学習の進め方

まず通しで解く — 制限時間 50 分 / 25 問（1 問 120 秒）
採点して弱点把握 — 末尾の「正答率早見表」に記入
間違えた問題は学習資料 ../02_学習資料/04_可観測性とトラブルシュート/ に戻る
1 週間後に再挑戦 — 90% 以上を目指す（最重要セクションのため繰り返し必須）

正答率の目安

正答率	評価	次のアクション
90% 以上	合格圏	次セクションへ進む
80-89%	合格ライン	間違えた領域だけ復習
70-79%	要復習	`02_応用.md` を再読
70% 未満	基礎不足	`01_基礎.md` から学び直す

難易度配分

★（基礎）: 3 問
★★（応用）: 15 問
★★★（発展）: 7 問

出題範囲対応表

試験ガイド項目	該当問題
4.1 テレメトリ計装（Ops Agent / OTel / Audit Logs / VPC Flow / Service Mesh / GMP / synthetic）	問題 1, 2, 3, 4, 5, 6, 7
4.2 ログ管理（Logs Explorer / LQL / Sink / PII / Gemini）	問題 8, 9, 10, 11, 12, 13
4.3 メトリクス・ダッシュボード・アラート（PromQL / SLO / 通知連携 / Gemini）	問題 14, 15, 16, 17, 18
4.4 分散トレース（OTel / waterfall / trace ID 紐付け / Gemini）	問題 19, 20, 21
4.5 トラブルシュート（インフラ / CI/CD / アプリ / 観測 / 性能）	問題 22, 23, 24, 25

問題

問題 1 （難易度: ★）

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

質問: 推奨されるエージェント構成はどれですか。

選択肢:

A. Legacy Logging Agent と Legacy Monitoring Agent を継続使用する
B. Ops Agent（fluentbit + OpenTelemetry 統合）へ移行する
C. 各 VM に OpenTelemetry Collector を独自に構築・配布する
D. Cloud Logging API と Cloud Monitoring API を直接アプリから呼ぶ

解答と解説

正解: B

解説:

B が正解: Ops Agent はログ（fluentbit）とメトリクス（OpenTelemetry）を統合した次世代の単一エージェントで、Google Cloud の推奨です。Legacy エージェントは新機能の追加が停止しています。
A: Legacy エージェントは非推奨。新規 OS バージョンや新機能（OTel メトリクス等）のサポートが期待できません。
C: 自前 Collector 運用は管理コストが増え、Ops Agent の利点を捨てることになります。
D: VM のシステムメトリクス（CPU/メモリ/ディスク等）まで自前計装するのは非現実的です。

試験のひっかけポイント: 「Legacy vs Ops Agent」は頻出。Ops Agent 一択と覚える。

問題 2 （難易度: ★★）

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

質問: Collector に設定すべきサンプリング戦略はどれですか。

選択肢:

A. SDK 側で Head-based（probabilistic）1% サンプリングを設定する
B. SDK 側で 100% 取得し、Collector の Tail-based sampling Processor でエラー span と高レイテンシ span を全保持、それ以外を低レートで採取する
C. すべてのトレースを Cloud Trace に送信し、保持期間を短くする
D. SDK 側で Always-on サンプラーを使い、Collector の Batch Processor だけ設定する

解答と解説

正解: B

解説:

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

試験のひっかけポイント: 「エラー trace を必ず保持」「価値ある trace を残しコスト削減」→ Tail-based sampling (Collector) が反射で出るように。

問題 3 （難易度: ★★）

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

質問: 追加で有効化が必要な Cloud Audit Logs はどれですか。

選択肢:

A. Admin Activity logs
B. Data Access logs
C. System Event logs
D. Policy Denied logs

解答と解説

正解: B

解説:

B が正解: Data Access logs だけがデフォルトで無効（BigQuery 除く）です。HIPAA / PCI / SOX 等のコンプラ対応では明示的に有効化する必要があります。
A: Admin Activity（IAM 変更等）は常時有効、無効化不可、無料です。
C: System Event は GCP 内部イベント。常時有効、無効化不可。
D: Policy Denied は VPC SC / IAM 拒否。常時有効、無効化不可（ただし課金あり）。

試験のひっかけポイント: 「Data Access のみデフォルト無効」が最頻出キーフレーズ。_Required バケットに保管される Admin Activity / System Event は 400 日固定、_Default に保管される Data Access / Policy Denied は 30 日（変更可）。7 年保管なら Sink で BQ / GCS Archive へエクスポート。

問題 4 （難易度: ★★）

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

質問: 最初に使用すべきツールはどれですか。

選択肢:

A. VPC Flow Logs を有効化し、TCP の RST パケットを探す
B. Connectivity Tests（Network Intelligence Center）で 2 点間到達性を分析する
C. Performance Dashboard でパケットロス率を確認する
D. Firewall Insights で未使用ルールを削除する

解答と解説

正解: B

解説:

B が正解: Connectivity Tests は実トラフィックを送らず、VPC のルート / FW / NAT / Private Google Access / PSC 等の構成を解析し、到達性とブロック箇所を特定します。
A: VPC Flow Logs は実フロー記録なので、まず構成解析で当たりをつけるのが定石。
C: Performance Dashboard はインフラのパケットロス / レイテンシ全体傾向、特定経路の到達性は対象外。
D: Firewall Insights は FW ルールの使用状況分析。到達性診断ではありません。

試験のひっかけポイント: 「2 点間到達性」「構成解析」→ Connectivity Tests。「全体のパケットロス」→ Performance Dashboard。「使ってない FW ルール」→ Firewall Insights。NIC 配下ツールの使い分けは必修。

問題 5 （難易度: ★★）

シナリオ: Cloud Service Mesh（旧 Anthos Service Mesh）を GKE クラスタに導入しました。アプリ側にコード変更を加えずに 4 Golden Signals（Latency / Traffic / Errors / Saturation）を観測したいです。

質問: Cloud Service Mesh が自動で送信するテレメトリの送信先の組み合わせとして正しいものはどれですか。

選択肢:

A. Metrics → Cloud Logging、Access logs → Cloud Trace、Traces → Cloud Monitoring
B. Metrics → Cloud Monitoring（GMP 互換）、Access logs → Cloud Logging、Traces → Cloud Trace
C. すべて Cloud Storage にエクスポートされる
D. すべて Pub/Sub へ送られ、ユーザーが Dataflow で振り分ける

解答と解説

正解: B

解説:

B が正解: Envoy サイドカーが istio_requests_total 等のメトリクスを Cloud Monitoring（および GMP / Prometheus 互換）へ、Envoy access logs を Cloud Logging へ、サイドカー間の trace を Cloud Trace へ自動送信します。コード変更なしで 4 Golden Signals が取れるのが Service Mesh の最大の売り。
A: 送信先が逆転しています。
C, D: Service Mesh はマネージドなので、ユーザーが Pub/Sub / GCS にルーティングする必要はありません。

試験のひっかけポイント: Cloud Service Mesh の自動収集 = Metrics / Access logs / Traces の 3 種類。Istio の PromQL クエリ例 histogram_quantile(0.99, sum by (le, destination_workload) (rate(istio_request_duration_milliseconds_bucket[5m]))) も覚えておく。

問題 6 （難易度: ★★）

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

質問: 最適な構成の組み合わせはどれですか。

選択肢:

A. 既存 = Cloud Monitoring エージェントで再実装、新規 = OSS Prometheus を自前デプロイ
B. 既存 = GMP の Self-deployed Collection（既存 Prometheus 構成を踏襲）、新規 = GMP の Managed Collection
C. 既存 = BigQuery にメトリクスを書き換える、新規 = Cloud SQL に保存
D. 既存 = Datadog に移行、新規 = AWS CloudWatch

解答と解説

正解: B

解説:

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 を管理する方式（新規推奨）。
A: OSS 自前運用の負荷を解消したい要件に反します。
C, D: 要件から外れた選択肢。

試験のひっかけポイント: 「既存 Prometheus がある → Self-deployed」「新規 GKE → Managed」が暗記キー。GMP は MQL ではなく PromQL 一択。

問題 7 （難易度: ★★）

シナリオ: ECsite のチェックアウト機能（ログイン → 商品検索 → カート追加 → 決済 → 注文確認）が全ユーザー視点で正常に動くかを 5 分ごとに能動監視したい。単純な HTTP ステータスチェックでは不十分で、複数ステップとセッション維持、JSON レスポンス検証が必要です。

質問: 最適な機能はどれですか。

選択肢:

A. Uptime Checks（HTTP）
B. Synthetic Monitor（Cloud Functions ベース）
C. Cloud Run ジョブで自前スクリプトを cron 実行
D. VPC Flow Logs で TCP 接続を追跡

解答と解説

正解: B

解説:

B が正解: Synthetic Monitor は Cloud Functions（Node.js）で複数ステップのシナリオを記述でき、Cloud Monitoring に成功率・レイテンシメトリクスを送ります。
A: Uptime Checks は単一エンドポイントの単純チェックのみ。
C: 自前運用は Synthetic Monitor の利点（メトリクス自動登録・ダッシュボード・アラート連携）を捨てることになります。
D: 観測対象が違います。

試験のひっかけポイント: 「複数ステップ」「シナリオ」「Cloud Functions」→ Synthetic Monitor。「単一 URL の死活」→ Uptime Checks。

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

シナリオ: 組織には 200 プロジェクトがあり、SecOps が全プロジェクトの Admin Activity ログを 1 か所に集約して SIEM（Splunk）にリアルタイム送信する必要があります。新規プロジェクトが追加されても自動で対象に含めたいです。

質問: 最適な構成はどれですか。

選択肢:

A. 各プロジェクトに個別の Sink を作り、宛先を共通の Cloud Storage バケットにする
B. 組織レベルの Aggregated Sink を --include-children 付きで作成し、宛先を Pub/Sub トピックに設定して Splunk Dataflow テンプレートで取り込む
C. プロジェクトごとに BigQuery へ Sink し、Splunk から JDBC で接続する
D. Cloud Logging Web UI から手動で 7 日ごとにエクスポートする

解答と解説

正解: B

解説:

B が正解: Aggregated Sink（組織 / フォルダ単位、--include-children で配下プロジェクトを自動包含）+ 宛先 Pub/Sub（リアルタイム配信）+ Splunk Dataflow テンプレートが、新規プロジェクト自動取り込みとリアルタイム SIEM 連携の組み合わせとして公式推奨です。
A: GCS はバッチ向けでリアルタイム性に欠ける。
C: BigQuery はリアルタイムではなく、Splunk の入力ソースとしても不適切。
D: 手動運用は論外。

試験のひっかけポイント: 「組織全体集約 → Aggregated Sink + --include-children」「リアルタイム SIEM → Pub/Sub Sink」の組み合わせが頻出。GCS は「最安アーカイブ」用途。

問題 9 （難易度: ★★）

シナリオ: Cloud Logging の月額ログ取り込み課金が想定の 3 倍に膨らみ、財務から即時にコスト削減を求められています。サービス無停止で、最も効果が大きく、最も迅速に課金削減できる手段はどれですか。

質問: 最初に取るべきアクションはどれですか。

選択肢:

A. Log Bucket の保持期間を 30 日から 7 日に短縮する
B. Log Router で Exclusion フィルタを設定し、不要な高ボリュームログ（DEBUG / アクセスログ等）の取り込みを停止する
C. すべてのログをサンプリングで 10% に減らす
D. Cloud Logging API クォータを下げる

解答と解説

正解: B

解説:

B が正解: 課金は取り込み量ベースなので、Exclusion で取り込み自体を 0 にするのが最速・最大効果。優先順位は Exclusion > Sampling > Retention 短縮 > Bucket 整理。
A: Retention はストレージ課金のみに効くが、_Required を除けば取り込み課金の方が大きいため効果限定。
C: Sampling は Exclusion より緩い手段で、必要なログまで間引くリスク。
D: クォータ削減はアプリ側 429 エラーや書き込み失敗を招く。

試験のひっかけポイント: 「ログコスト緊急削減」→ Exclusion。順序は反射で出るように。

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

シナリオ: ヘルスケア企業が、アプリログに含まれる患者氏名や保険番号（PII/PHI）を Cloud Logging に書き込む前に必ず除去したい。ログ運用チームへの依存を最小化し、最も確実な手段を取りたい。

質問: 最も推奨されるアプローチはどれですか。

選択肢:

A. Cloud Logging に書き込んだ後、Log Sink を BigQuery に流し、定期 SQL で更新する
B. Logs Explorer で PII を含むログを手動削除する
C. アプリケーション層で Sensitive Data Protection (DLP) API（旧 Cloud DLP）を呼び、PII を de-identify した後に Cloud Logging へ書き込む
D. ログを暗号化して書き込み、検索時に復号する

解答と解説

正解: C

解説:

C が正解: 書き込み前のリダクションが最も確実です。Sensitive Data Protection (DLP) API は PII 検出 + マスキング / トークナイズ / 暗号化（DLP の infoType を活用）を提供します。Cloud Run / Cloud Functions のサイドカー的にも組み込めます。
A: BigQuery に書き込んだ時点でCloud Logging には残ったまま = HIPAA / GDPR 不適合。
B: 手動削除は到底スケールしません。
D: 暗号化は閲覧者を絞るのみで、PII の存在自体は残ります。

試験のひっかけポイント: 「PII を確実に除去」「コンプラ対応」→ Sensitive Data Protection (DLP) をアプリ層で書き込み前に適用。Log Sink 後の処理では遅い。

問題 11 （難易度: ★★）

シナリオ: GKE で稼働する API ゲートウェイのログから「過去 5 分の HTTP 5xx 件数を取得し、Cloud Monitoring のメトリクスとしてアラート評価したい」というニーズがあります。レイテンシ等の分布解析は不要で、件数だけが必要です。

質問: 作成すべき log-based metric の種類はどれですか。

選択肢:

A. Counter 型 log-based metric（マッチしたログ行数）
B. Distribution 型 log-based metric（数値抽出して分布化）
C. Gauge 型 metric を直接 Monitoring API に書く
D. SLO ベースの error budget metric

解答と解説

正解: A

解説:

A が正解: 件数なら Counter。LQL でフィルタ（例 httpRequest.status>=500）を書き、Cloud Monitoring 上で rate() 相当を評価できます。
B: Distribution はレイテンシ等の数値分布用。可視化は Heatmap、分位点は histogram_quantile。
C: log-based metric は既存ログから派生させるべきで、二重計装は不要。
D: SLO は別概念。

試験のひっかけポイント: Counter vs Distribution の使い分けは頻出。「件数 = Counter」「数値の分布 = Distribution」。

問題 12 （難易度: ★★）

シナリオ: コンプライアンス対応として、Audit ログを最も安価に7 年間アーカイブする必要があります。日常的に検索する用途はなく、年 1 回程度の監査時のみ参照できれば良いです。

質問: 最適な Sink 宛先と設定はどれですか。

選択肢:

A. Log Bucket の保持期間を 2555 日に延長
B. BigQuery に Sink し、Long-term storage に置く
C. Cloud Storage Sink、ストレージクラス Archive、Object Lifecycle で自動階層化、Bucket Lock で改ざん防止
D. Pub/Sub Sink でファンアウトし、各チームが個別に保管

解答と解説

正解: C

解説:

C が正解: Archive クラスは GB あたり月額約 $0.0012（GA リージョン）と最安。Bucket Lock + Retention Policy で WORM 化し改ざん防止、Object Lifecycle で Standard → Archive 自動移行も可能。コンプラ向けの定石。
A: Log Bucket は最大 3650 日まで保持可能だが、Archive クラス GCS よりかなり高価。
B: BigQuery は分析用途のコストに優れるが、Archive 用途では割高。
D: Pub/Sub は配信用で長期保管はできない（最大 7 日）。

試験のひっかけポイント: 「最安 7 年アーカイブ」→ Cloud Storage Archive + Bucket Lock。「SQL 分析」→ Log Analytics or BQ。「リアルタイム配信」→ Pub/Sub。

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

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

質問: 最も効果が大きい新機能はどれですか。

選択肢:

A. Cloud Logging の旧 MQL を Web UI で書く
B. Looker Studio でアドホックダッシュボードを作る
C. Gemini Cloud Assist（Investigations / Query 生成 / Explain this chart）を活用する
D. 全エンジニアに正規表現研修を実施する

解答と解説

正解: C

解説:

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: スキル習得は時間がかかり、AI 支援の代替にはなりません。

試験のひっかけポイント: 「AI が根本原因仮説を提示」「MTTR 短縮 with AI」→ Gemini Cloud Assist Investigations。2024-2025 新機能として頻出予定。

問題 14 （難易度: ★★）

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

質問: 正しい PromQL クエリはどれですか。

選択肢:

A. rate(http_request_duration_seconds_bucket[5m])
B. avg by (service) (http_request_duration_seconds_bucket)
C. histogram_quantile(0.99, sum by (le, service) (rate(http_request_duration_seconds_bucket[5m])))
D. topk(99, http_request_duration_seconds_bucket)

解答と解説

正解: C

解説:

C が正解: Prometheus の histogram は _bucket カウンタを rate() してから le ラベルを残しつつ集約し、histogram_quantile(0.99, ...) で p99 を算出します。サービス別表示は sum by (le, service) で service を残す。
A: rate だけでは分位点になりません。
B: bucket の値を avg するのは数学的に無意味。
D: topk は別用途。

試験のひっかけポイント: 分位点の定型句: histogram_quantile(q, sum by (le, <group_labels>) (rate(*_bucket[range])))。le を集約から落とすと壊れる。

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

シナリオ: SLO 99.9% / 28 日ローリングのサービスを運用しています。SRE Workbook 第 5 章に基づき、ノイズの少ない multi-burn-rate アラートを構築したい。Critical（即時 Page）と Warning（チケット）を適切に設計したいです。

質問: 代表的な multi-burn-rate アラート設計として正しいものはどれですか。

選択肢:

A. 単一しきい値で「エラー率 0.1% 超過」が 1 分続いたら Page
B. Fast: 1h ウィンドウ + Burn rate 14.4x で Page、Slow (Page): 6h ウィンドウ + Burn rate 6x で Page、Medium (Ticket): 24h ウィンドウ + Burn rate 3x、Slow (Ticket): 3d ウィンドウ + Burn rate 1x
C. 1 分ウィンドウで Burn rate 1x のみ
D. SLO とは無関係に CPU 80% で Page

解答と解説

正解: B

解説:

B が正解: SRE Workbook 推奨。Fast（1h, 14.4x ≒ 2 日でバジェット全消費）と Slow Page（6h, 6x ≒ 4.7 日全消費）を AND するとノイズ削減効果が高い。Ticket は 24h（3x）と 3d（1x）。
A: 単一しきい値は瞬間スパイクで誤発火する典型例。
C: 1 分ウィンドウは過敏すぎ。
D: 症状ベースでなく原因ベース（CPU）はアクション可能性に欠ける。

試験のひっかけポイント: 14.4x / 6x / 3x / 1x の組み合わせを暗記。SLO ベース + Multi-burn-rate は「症状ベース、アクション可能」の代名詞。

問題 16 （難易度: ★）

シナリオ: オンコール体制を PagerDuty で運用しており、Cloud Monitoring の Critical アラートが発火したら自動でオンコール担当を呼び出し、未応答時はエスカレーションさせたい。

質問: 適切な Notification Channel はどれですか。

選択肢:

A. Email
B. Slack
C. PagerDuty / Rootly（または Webhook 経由でのインシデント管理ツール連携）
D. Pub/Sub

解答と解説

正解: C

解説:

C が正解: Critical / オンコール / エスカレーションが要件なら PagerDuty / Rootly（または Webhook 経由のインシデント管理）。
A: Email は非緊急サマリー向け。
B: Slack はチーム共有・Warning レベル向け。
D: Pub/Sub はプログラム処理用（Functions / Run）。

試験のひっかけポイント: Notification Channel の使い分け: Critical / Page → PagerDuty・Rootly、Warning → Slack・Teams、Notice → Email、プログラム連携 → Pub/Sub / Webhook。

問題 17 （難易度: ★★）

シナリオ: Distribution 型 log-based metric「API レイテンシ」を Cloud Monitoring のダッシュボードに表示したい。しきい値超過の偏りを時系列で視覚的に把握したいです。

質問: 最適なチャートタイプはどれですか。

選択肢:

A. Line chart
B. Stacked bar
C. Heatmap
D. Scorecard

解答と解説

正解: C

解説:

C が正解: Heatmap は時系列 × バケットの密度を色濃度で表現でき、Distribution / histogram の分布把握に最適。
A: Line は単一値の推移用。
B: Stacked bar はカテゴリ別積み上げ用。
D: Scorecard は単一現在値表示用。SLO 残量等に。

試験のひっかけポイント: 「distribution metric の可視化」→ Heatmap を反射で。

問題 18 （難易度: ★★）

シナリオ: 複数チームが共通のメトリクス命名で、PromQL を書きにくい属性が混入しています。例えば up{instance="10.0.0.5:9100"} のメトリクスを host ラベル（10.0.0.5）でグルーピングしたいです。

質問: 適切な PromQL の関数はどれですか。

選択肢:

A. topk()
B. irate()
C. label_replace()
D. histogram_quantile()

解答と解説

正解: C

解説:

C が正解: label_replace(up, "host", "$1", "instance", "([^:]+):.*") のように既存ラベルから新規ラベルを抽出 / 変換できます。
A: 上位 k 件抽出。
B: 直近 2 サンプルの瞬間レート。
D: 分位点。

試験のひっかけポイント: label_replace の正規表現キャプチャは PromQL でも出やすい。rate / increase / sum by / avg by / histogram_quantile / label_replace / topk / irate の機能対応表は暗記必須。

問題 19 （難易度: ★★）

シナリオ: GKE で OpenTelemetry SDK によりトレースを Cloud Trace に送っています。同じリクエストのログとトレースを 1 クリックで紐付けたいため、構造化ログに必要なフィールドを出力する設計を行います。

質問: ログに付与すべき正しいフィールドはどれですか。

選択肢:

A. request_id / correlation_id
B. logging.googleapis.com/trace（projects/PROJECT_ID/traces/TRACE_ID）、logging.googleapis.com/spanId、logging.googleapis.com/trace_sampled
C. X-Request-ID ヘッダをそのままログに書く
D. traceparent ヘッダの 32 文字 ID のみ

解答と解説

正解: B

解説:

B が正解: Cloud Logging はこの 3 フィールドを認識して Logs Explorer から Trace へ自動リンクします。trace は projects/PROJECT_ID/traces/TRACE_ID 形式が必須。
A: 独自 ID は自動紐付けされません。
C: ヘッダ転記だけでは自動リンクされません。
D: フィールド名が違うので無効。

試験のひっかけポイント: logging.googleapis.com/trace のフィールド名・値フォーマットは暗記必須。Cloud Run / Cloud Functions は X-Cloud-Trace-Context ヘッダから自動紐付けするが、GKE / GCE は明示出力が必要。OTel 標準 propagation は W3C Trace Context (traceparent)。

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

シナリオ: OpenTelemetry Collector を導入し、複数言語のアプリから OTLP でテレメトリを受信し、属性編集・サンプリングを行ったうえで Cloud Trace と Managed Service for Prometheus に送信したいです。

質問: OTel Collector の各コンポーネントの正しい組み合わせはどれですか。

選択肢:

A. Receiver = googlecloud、Processor = otlp、Exporter = batch
B. Receiver = otlp、Processor = attributes / tail_sampling / batch、Exporter = googlecloud（trace 用）と googlemanagedprometheus（metric 用）
C. Receiver = fluentd、Processor = dlp、Exporter = bigquery
D. Receiver = gke、Processor = prometheus、Exporter = pubsub

解答と解説

正解: B

解説:

B が正解: OTel Collector の 3 段は Receiver → Processor → Exporter。Receiver には otlp（gRPC/HTTP）が主流、Processor で attributes / tail_sampling / batch を組み合わせ、Exporter は googlecloud（Cloud Trace / Cloud Logging / Cloud Monitoring）と googlemanagedprometheus（GMP）を使い分けます。
A: Receiver / Processor / Exporter の役割が逆転。
C: Receiver に fluentd や DLP は OTel ではない。
D: コンポーネント名が架空。

試験のひっかけポイント: Receiver / Processor / Exporter の 3 段構成と、GCP 向け Exporter 名 googlecloud / googlemanagedprometheus は暗記。

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

シナリオ: 複雑なマイクロサービスチェーンで、1 つのリクエストが 30 以上のスパンを含む waterfall を生成します。SRE が trace を全部見ずにボトルネック span と異常 span を素早く要約したいです。さらに自然言語で「最も時間がかかったのはどのスパンか」「呼び出しグラフ上の依存は？」を尋ねたい。

質問: 最適な手段はどれですか。

選択肢:

A. Cloud Trace の Span list をエクスポートして Excel で並び替える
B. Gemini Cloud Assist の Summarize trace 機能を利用する
C. Cloud Profiler の Wall time profile を取る
D. Error Reporting でスタックトレースをグルーピングする

解答と解説

正解: B

解説:

B が正解: Gemini Cloud Assist の Summarize trace は waterfall を要約し、最長 span / 並列化機会 / 異常依存を自然言語で示します。
A: 手動分析は非効率。
C: Profiler はコード行ホットスポット解析で trace 解析ではない。
D: Error Reporting は例外集約用。

試験のひっかけポイント: 「Trace 要約」「waterfall 自動分析」→ Gemini Cloud Assist。Gemini 系は他に Log Summary / Investigations / Explain this chart / Query 生成。

問題 22 （難易度: ★★）

シナリオ: Cloud Build パイプラインが特定のビルドだけ稀に失敗します。GitHub PR トリガーで動いており、CI ログには permission denied らしき断片が見えます。ローカルで CI と同じビルドを再現して原因を特定したいです。

質問: 最も適切な手順はどれですか。

選択肢:

A. Cloud Build トリガーを無効化して PR を手動マージする
B. gcloud builds log で失敗ビルドのフルログを取得 → Logs Explorer で resource.type="build" を絞り込み → ローカルで skaffold build / render / dev を使い同条件で再現
C. プロジェクトのオーナー権限を全エンジニアに付与する
D. Artifact Registry を削除して再作成する

解答と解説

正解: B

解説:

B が正解: CI/CD 障害の定石は (1) Cloud Build / Cloud Deploy logs 確認 → (2) ローカル再現 (Skaffold) の順。gcloud builds log <BUILD_ID> や Logs Explorer の resource.type="build" は必修。Skaffold は Cloud Build と同じビルド設定をローカルで再現できる。
A: 問題の隠蔽でしかありません。
C: 過剰権限付与はセキュリティ違反。
D: 関係ないリソース破壊。

試験のひっかけポイント: CI/CD トラブルシュート初動: Cloud Build → gcloud builds log / Logs Explorer、Cloud Deploy → gcloud deploy rollouts describe、ローカル再現 → skaffold dev。

問題 23 （難易度: ★★）

シナリオ: Java マイクロサービスが徐々にメモリ使用量が増え、24 時間後に OOMKilled される現象が GKE で発生しています。原因がメモリリークか正常な負荷増加かを切り分けたい。本番影響を最小化したいです。

質問: 最も適切なアプローチはどれですか。

選択肢:

A. すべての Pod を再起動し様子を見る
B. Cloud Profiler の Heap profile を本番常時収集し、時間経過でアロケート済みオブジェクトが増えるクラス / 関数を特定する
C. Cloud Trace でリクエストレイテンシを計測する
D. Performance Dashboard でパケットロスを確認する

解答と解説

正解: B

解説:

B が正解: Cloud Profiler は本番常時稼働可能（< 1% CPU オーバヘッド）。Heap profile は現時点でアロケート済みのオブジェクトを示し、時間軸で増え続けるクラスを発見できる → メモリリーク調査の定石。
A: 原因が分からないまま再起動は再発を招く。
C: Trace はリクエスト経路のレイテンシ用でメモリ解析ではない。
D: ネットワーク解析でメモリには無関係。

試験のひっかけポイント: 「メモリリーク → Heap profile」「Mutex 待ち → Contention」「経過時間（IO 含む）→ Wall time」「CPU → CPU time」。Profiler 種別の使い分けは頻出。

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

シナリオ: 本番アプリの p99 レイテンシが昨日から悪化しました。アラートは鳴ったが原因が特定できていません。マイクロサービスチェーン全体のボトルネック span を特定し、その span 内のホットなコード行も併せて見たい。

質問: 最適な調査順序はどれですか。

選択肢:

A. Error Reporting → Logs Explorer → BigQuery
B. Cloud Trace（waterfall でボトルネック span 特定）→ trace ID 経由で構造化ログ確認 → Cloud Profiler（CPU / Wall time で当該サービスのホット関数特定）
C. Network Topology → Connectivity Tests → VPC Flow Logs
D. Synthetic Monitor → Uptime Checks → Pub/Sub Sink

解答と解説

正解: B

解説:

B が正解: パフォーマンス問題の標準手順。(1) Trace で経路全体の遅い span 特定 → (2) trace ID で関連ログ取得 → (3) Profiler で当該プロセスのコード行ホットスポット特定。Trace と Profiler の組み合わせは PCDE 頻出。
A: Error Reporting は例外集約用でレイテンシ調査には不適。
C: ネットワーク調査は別領域。
D: 外形監視ツールの羅列で深掘りにならない。

試験のひっかけポイント: Trace → Profiler の連携でアプリ性能問題を解く。Wall time profile は IO 待ち含む経過時間が見える点も覚える。

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

シナリオ: Cloud Monitoring にいくつかの VM のメトリクスが届かなくなったと運用チームから報告がありました。アラートは沈黙し、ダッシュボードの該当 VM が「No data」になっています。問題が観測可能性側にあることを切り分けるための最初の確認はどれですか。

質問: 最も適切な初動はどれですか。

選択肢:

A. アプリのコードをロールバックする
B. Cloud Monitoring の API クォータを増やす
C. Ops Agent のステータスとログ（google-cloud-ops-agent.service の status / agent log）を確認し、エージェント自体や IAM 権限・ネットワーク到達性を切り分ける
D. プロジェクトを別リージョンに移行する

解答と解説

正解: C

解説:

C が正解: 「メトリクスが届かない」=「観測可能性自体の問題」の典型。**Ops Agent のサービス状態 + agent log + サービスアカウントの roles/monitoring.metricWriter・roles/logging.logWriter 権限 + Egress（Private Google Access / NAT）**を順に確認するのが定石。
A: アプリ側ではなく観測基盤が原因の可能性が高い。
B: クォータ起因なら 429 エラーがログに出るはずでまず agent ログを見るべき。
D: 関係なく破壊的。

試験のひっかけポイント: 「観測可能性自体の問題」5 領域: メトリクス欠落 → Ops Agent / IAM / Network、ログコスト超過 → ソース別ボリューム + Exclusion、アラート鳴らない → Condition / Channel / Snooze 確認。観測の観測（meta observability）の発想を忘れない。

正答率早見表

採点後、以下に記入して弱点を可視化してください。

問題	領域	難易度	正誤
1	4.1 Ops Agent	★	☐
2	4.1 OTel Sampling	★★	☐
3	4.1 Audit Logs 4 種類	★★	☐
4	4.1 / 4.5 NIC / Connectivity Tests	★★	☐
5	4.1 Cloud Service Mesh	★★	☐
6	4.1 GMP	★★	☐
7	4.1 Synthetic Monitor	★★	☐
8	4.2 Aggregated Sink + Pub/Sub	★★★	☐
9	4.2 ログコスト削減	★★	☐
10	4.2 PII / DLP	★★★	☐
11	4.2 log-based metric	★★	☐
12	4.2 GCS Archive Sink	★★	☐
13	4.2 Gemini Cloud Assist	★★★	☐
14	4.3 PromQL histogram_quantile	★★	☐
15	4.3 Multi-burn-rate	★★★	☐
16	4.3 PagerDuty 連携	★	☐
17	4.3 Heatmap	★★	☐
18	4.3 PromQL label_replace	★★	☐
19	4.4 trace 紐付けフィールド	★★	☐
20	4.4 OTel Collector 構成	★★★	☐
21	4.4 Gemini Summarize trace	★★★	☐
22	4.5 CI/CD トラブル	★★	☐
23	4.5 Profiler Heap	★★	☐
24	4.5 Trace + Profiler	★★★	☐
25	4.5 観測可能性自体の問題	★★★	☐

弱点別の復習リンク

もし間違えた領域	復習教材
4.1 テレメトリ計装 / Audit Logs / NIC / Service Mesh / GMP	`../02_学習資料/04_可観測性とトラブルシュート/01_基礎.md`
4.2 ログ管理 / Sink / PII / コスト最適化 / Gemini	`../02_学習資料/04_可観測性とトラブルシュート/02_応用.md`
4.3 PromQL / SLO / burn rate / 通知	`../02_学習資料/04_可観測性とトラブルシュート/02_応用.md`
4.4 OTel / trace 紐付け / Collector	`../02_学習資料/04_可観測性とトラブルシュート/02_応用.md`
4.5 トラブルシュート全般 / Profiler / 観測 meta 問題	`../02_学習資料/04_可観測性とトラブルシュート/03_要点と暗記.md`

次のセクション

Section 5 問題集（Supporting operational services）※存在する場合
全セクション横断は ../03_問題集/README.md を参照