PCDE 模擬試験 1（本番形式・50 問）

試験: Google Cloud Professional Cloud DevOps Engineer (PCDE) 対応版: 2024-2025 改訂版（Infrastructure Manager GA / Cloud Workstations GA / Cloud Service Mesh / Software Delivery Shield / Managed Service for Prometheus / Gemini Code Assist & Cloud Assist 反映）

形式について

本模擬試験は 本番の出題形式と時間配分を可能な限り忠実に再現 したものです。

項目	値
制限時間	120 分（2 時間）
問題数	50 問
1 問あたり想定時間	約 144 秒
合格基準（目安）	35 問以上（70%）正答
問題形式	4 択 / 5 択 / 複数選択（3 つ選びなさい等）
ケーススタディ	各問題内に独立シナリオが提示される（固定 PDF はなし）

出題比重

#	セクション	比重	問題数
1	Bootstrapping & maintaining a Google Cloud organization	~20%	10 問
2	Building and implementing CI/CD pipelines	~25%	13 問
3	Applying site reliability engineering practices	~18%	9 問
4	Implementing observability and troubleshooting	~25%	12 問
5	Optimizing performance and managing cost	~12%	6 問
	合計	100%	50 問

受験ルール（推奨）

静かな環境で 120 分のタイマー をセットし、中断なしで解く
1 問ごとに 解説 (<details>) を開かない。全 50 問を解き終えてから採点
自信のない問題には 付箋（マーク） を付け、残り時間で見直す
計算問題は紙とペンを使い、暗算に頼らない（特に SLO / Error Budget）
「最も Google 推奨」「最も低コスト」「最も少ない運用負荷」 を問う問題では、複数選択肢が技術的に動作する可能性があることに注意

自己採点ルール

1 問 1 点、合計 50 点
複数選択問題は 全選択肢が一致 した場合のみ 1 点（部分点なし）
採点後、末尾の「セクション別正答率自己採点表」に記入し、弱点を特定する

問題本体

問題 1

シナリオ: グローバル小売チェーン Cymbal Retail は、新たに Google Cloud Organization を立ち上げ、北米・欧州・アジアの 3 リージョンで本番ワークロードを展開する計画です。各リージョンには production / non-production / development の環境が必要で、共通の Shared VPC / 監査 Sink / Org Policy を中央 Platform チームで管理したいと考えています。Foundation を Google 推奨のベストプラクティス で短期間に構築したいです。

質問: 最も適切な実装はどれですか。

選択肢:

A. すべてのリソースを 1 つのプロジェクトに集約し、リージョン分離のみ実施する
B. Cloud Foundation Toolkit（terraform-example-foundation）を Infrastructure Manager にデプロイし、Folder 階層 / Shared VPC / Aggregated Sink / Org Policy を一括展開する
C. Folder を作らず、すべてのプロジェクトを Organization 直下に配置し、Org Policy で個別制御する
D. Deployment Manager で Foundation を構築し、各環境ごとに手動で Org Policy を適用する

解答と解説

正解: B

解説:

B が正解: Cloud Foundation Toolkit（CFT） + Infrastructure Manager は Google 推奨の新規 Organization ブートストラップ手法。terraform-example-foundation ブループリントが Folder / Shared VPC / Aggregated Sink / Org Policy / KMS / Billing を一括展開します。
A: 1 プロジェクト集約は IAM / 課金 / Quota 境界が破綻。
C: Folder なしは Org Policy 継承・人事異動・IAM 委譲が破綻し、エンタープライズで非推奨。
D: Deployment Manager は非推奨（2025 年に近い将来廃止予定）。新規は Infrastructure Manager を使用。

ひっかけポイント: 「Deployment Manager で IaC」は古いベストプラクティス。現在は Infrastructure Manager（Terraform マネージド実行） が公式推奨。

関連: §1 組織と基盤 — Foundation Blueprint

問題 2

シナリオ: ベルリンに本社を置く決済 SaaS Lumen Pay は、EU 域外（特に US リージョン）に顧客データを保存することを禁じる規制下にあります。複数の開発者が誤って us-central1 にリソースを作成するインシデントが続いており、技術的に防止したい一方、本番 Folder への適用前に 既存リソースへの影響を見える化 してから本適用したいです。

質問: 最も適切な実装はどれですか。

選択肢:

A. VPC Service Controls 境界で US リージョンを除外する
B. Org Policy gcp.resourceLocations を Folder に Dry Run モード で適用し、違反ログを Cloud Logging で確認後、Enforce モードに切り替える
C. Cloud Asset Inventory の Schedule Export で違反を検知し、Cloud Function で自動削除する
D. IAM Conditional Role で compute.regions.create を US リージョンに対して拒否する

解答と解説

正解: B

解説:

B が正解: gcp.resourceLocations は データ常駐性の正攻法。Dry Run モードで違反を Audit Log に記録するだけで実 Enforce はせず、影響範囲を把握してから Enforce 切替できます。
A: VPC SC は API レベルのデータ流出防止であり、リソース作成位置を強制する仕組みではない。
C: 検知 + 削除は反応的で、誤削除リスク高。
D: compute.regions.create という IAM permission は存在しない（regions は読み取りのみ）。

ひっかけポイント: 「データ常駐」= gcp.resourceLocations + Dry Run。VPC SC と混同しない。

関連: §1 Org Policy / データ常駐

問題 3

シナリオ: 医療系スタートアップ MediCare は、GitHub Actions から Google Cloud の本番 GKE クラスタへ自動デプロイを行いたいと考えています。社内セキュリティ部門は 「SA キー JSON を一切使用してはならない」 と要求しており、iam.disableServiceAccountKeyCreation Org Policy も適用予定です。

質問: 最も Google 推奨の認証方式はどれですか。

選択肢:

A. GCP Service Account を作成し、JSON キーを GitHub Secrets に保存し短期間でローテーションする
B. Workload Identity Federation Pool を作成し、GitHub OIDC Provider を登録、attribute-condition で特定リポジトリ / ブランチに限定する
C. GitHub Actions Runner を GCE VM 上にセルフホストし、metadata server から SA トークンを取得する
D. GitHub Personal Access Token で Cloud Build をトリガーし、Cloud Build から GKE にデプロイする

解答と解説

正解: B

解説:

B が正解: Workload Identity Federation（WIF） が外部 ID（GitHub / GitLab / AWS / Azure）から GCP 認証する正解。attribute-condition で repository == "org/repo" && ref == "refs/heads/main" のように限定できます。
A: SA キー禁止に違反。
C: 動作はするが、セルフホスト Runner の運用負荷とセキュリティ管理が増える。WIF が公式推奨。
D: Cloud Build 経由でも GitHub 側認証に PAT を使うなら漏洩リスクは残る。

ひっかけポイント: 「キーなしで外部 CI から GCP 認証」= WIF 一択。

問題 4

シナリオ: 製造業 Toyobashi Industries は、複数の工場（オンプレ）と Google Cloud を Dedicated Interconnect で接続し、共通 Shared VPC で運用しています。Platform チームは「サブネットレンジを工場跨ぎで重複させない」「人事異動に強い IAM 設計」「監査ログを Org レベルで集約」を実現したいです。

質問: 3 つ を選んでください（複数選択）。

選択肢:

A. Shared VPC ホストプロジェクトを common Folder に配置し、各工場プロジェクトをサービスプロジェクトとしてアタッチする
B. IAM 付与は個人ユーザー単位ではなく Google Group 経由とし、Group メンバーシップ変更で権限を管理する
C. Organization レベルで Aggregated Sink を作成し、--include-children で全プロジェクトの Audit Log を中央プロジェクトの Log Bucket / BigQuery に集約する
D. 各工場プロジェクトに個別の Cloud Logging Sink を手動作成する
E. 個人ユーザーに直接 roles/owner を付与し、退職時に削除する

解答と解説

正解: A, B, C

解説:

A: Shared VPC ホスト集中管理が正解。
B: Group ベース付与は人事異動に強い IAM 設計の基本。
C: Aggregated Sink + --include-children が Org 横断 Audit Log 集約の公式パターン。
D: プロジェクト単位 Sink は管理コスト爆発・新規プロジェクトで漏れる。
E: Basic Role（owner / editor / viewer）の直接付与は禁止。

ひっかけポイント: 「人事異動に強い」= Group ベース。「全社ログ集約」= Aggregated Sink + --include-children。

関連: §1 IAM 設計原則 / Aggregated Sink

問題 5

シナリオ: SaaS 企業 Stratosphere は、GKE Standard クラスタで顧客の機微情報を扱うサービスを運用しています。CIO から次の要件が出されました：(1) データ暗号化鍵をユーザー側で管理、(2) FIPS 140-2 Level 3 相当の HSM レベル、(3) 鍵をローテーションした場合に即時アクセス停止が可能。

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

選択肢:

A. Google-managed encryption keys（デフォルト）を使用する
B. CMEK with Cloud KMS（Software 保護レベル）を有効化する
C. CMEK with Cloud HSM を使用し、PV / etcd の暗号化に適用する
D. CMEK with Cloud EKM を使用し、AWS KMS の鍵を参照する

解答と解説

正解: C

解説:

C が正解: FIPS 140-2 Level 3 を満たすのは Cloud HSM 保護レベル。鍵を無効化すれば暗号化リソースへのアクセスを即時停止できます。
A: Google-managed は CMEK 要件を満たさない。
B: Software 保護は FIPS 140-2 Level 1 相当。
D: EKM は鍵をクラウド外保管する用途で、FIPS Level は外部 KMS 依存。HSM 要件には Cloud HSM が直接解。

ひっかけポイント: 「FIPS 140-2 Level 3」= Cloud HSM が即答。

関連: §1 データ常駐性 / Cloud KMS 保護レベル

問題 6

シナリオ: ヘルスケア SaaS Vitalink は、Infrastructure as Code を GCP マネージド で運用したく、Terraform State の管理・ロック・履歴を自社で運用したくありません。Apply の実行は GitHub PR マージで自動化し、変更レビューも残したいです。

質問: 最適なサービスはどれですか。

選択肢:

A. Terraform Cloud（HashiCorp 提供）を契約し、GitHub と統合する
B. Infrastructure Manager を使い、Terraform 構成を Git リポジトリで管理して deploy する
C. Cloud Build で terraform apply を実行し、State を GCS バケットに手動配置する
D. Config Connector で Kubernetes YAML として記述する

解答と解説

正解: B

解説:

B が正解: Infrastructure Manager は GCP マネージドの Terraform 実行サービス。State 管理 / ロック / 履歴を自動管理。
A: 動作するが GCP マネージド要件を満たさない（外部 SaaS）。
C: 自前運用相当で運用負荷高。
D: Config Connector は K8s CRD 経由で GCP リソース管理。Terraform を選んでいる前提と合わない。

ひっかけポイント: 「GCP マネージド Terraform」= Infrastructure Manager。Cloud Build + GCS の自前 State は古い手法。

問題 7

シナリオ: Cymbal Trading は GKE Fleet で複数クラスタ（dev / staging / prod）を運用し、Git を信頼源としたデプロイ（GitOps） を実装したいです。Platform チームはクラスタ全体の共通リソース（Namespace / Role / NetworkPolicy）を、アプリチームは自分の Namespace 内のリソースをそれぞれ管理したいです。

質問: 最も適切な実装はどれですか。

選択肢:

A. すべてのチームが kubectl apply を直接実行する
B. Argo CD を自前運用し、App-of-Apps パターンで管理する
C. Config Sync を導入し、Platform チームは RootSync、アプリチームは Namespace 単位の RepoSync を使う
D. Cloud Build から kubectl apply を pipe-line で実行する Push 型 GitOps を採用する

解答と解説

正解: C

解説:

C が正解: Config Sync の RootSync（クラスタ全体）+ RepoSync（Namespace 単位）はマルチテナント GitOps の公式パターン。
A: GitOps 要件を満たさず手動。
B: 動作するが GKE Fleet 統合の Google マネージドな選択肢は Config Sync。
D: Push 型は監査性・宣言性が GitOps（Pull 型）に劣る。

ひっかけポイント: RootSync = Platform、RepoSync = Namespace（アプリチーム）。

関連: §1 複数環境管理 / Config Sync

問題 8

シナリオ: ある SaaS 企業はマイクロサービスを 30+ 個運用しており、サービス間 mTLS、トラフィック分割、リトライ、メトリクス収集を実装したいです。アプリのコード変更は最小限 にしたいです。GKE / Cloud Run / VM が混在しています。

質問: 最適なソリューションはどれですか。

選択肢:

A. 各サービスに gRPC リトライ / mTLS を個別実装する
B. Cloud Service Mesh（旧 Anthos Service Mesh）を導入し、サイドカー Envoy で mTLS / トラフィック管理 / メトリクスを提供する
C. Apigee X を全マイクロサービス間に挟む
D. Cloud Load Balancing の Backend Service で個別ポリシーを設定する

解答と解説

正解: B

解説:

B が正解: Cloud Service Mesh（旧 ASM）は Istio + Envoy ベース。コード未改修で mTLS / トラフィック管理 / 4 Golden Signals が取れる のが最大の売り。
A: 30 サービスに重複実装で運用破綻。
C: Apigee は北南トラフィック（外部 API）向け。サービス間（東西）は Service Mesh が定石。
D: GLB はサービス間ではなく外部公開向け。

ひっかけポイント: 旧名 Anthos Service Mesh → 新名 Cloud Service Mesh。

問題 9

シナリオ: 新興フィンテック Mintech のエンジニア 50 名は在宅・出社混在で開発します。開発環境に次の要件があります：(1) ブラウザだけで本格 IDE が使える、(2) 社内 VPC 内の Cloud SQL にプライベートアクセス、(3) CMEK でディスク暗号化、(4) Gemini Code Assist 統合。

質問: 最も適切な開発環境はどれですか。

選択肢:

A. Cloud Shell + Cloud Shell Editor を全員に配布
B. Cloud Workstations を Private Cluster 内に配置し、Workstation Config で CMEK / Gemini Code Assist を有効化
C. 個人 PC に VS Code をインストールし、Cloud SQL Auth Proxy を使う
D. GCE VM に Code-Server を立てて IAP 経由で接続する

解答と解説

正解: B

解説:

B が正解: Cloud Workstations はマネージドのブラウザ IDE。Private Cluster で VPC 内アクセス、Workstation Config で CMEK / Gemini Code Assist を統合できる。
A: Cloud Shell は試しコマンド / 教育向け。VPC 内 Private リソースアクセス / CMEK は範囲外。
C: 個人 PC の管理コスト・統制が困難。
D: 自前運用で運用負荷大。Cloud Workstations が公式推奨。

ひっかけポイント: 軽い試し = Cloud Shell、本格開発 + VPC 内 = Cloud Workstations。

問題 10

シナリオ: Cymbal Insurance の SRE チームは、GCP Console 上で AI による運用支援（メトリクスチャートの自然言語説明、ログ要約、アラートの根本原因仮説提示）を活用したいです。一方、開発チームは IDE（VS Code）内でコード補完・PR レビュー支援を受けたいです。

質問: 適切な組み合わせはどれですか。

選択肢:

A. SRE: Gemini Code Assist、開発者: Gemini Cloud Assist
B. SRE: Gemini Cloud Assist、開発者: Gemini Code Assist
C. SRE: Gemini CLI、開発者: Gemini Cloud Assist
D. SRE: Vertex AI Search、開発者: Cloud Workstations

解答と解説

正解: B

解説:

B が正解:
- Gemini Cloud Assist = GCP Console 内で AI 運用支援（Investigations / Explain this chart / Log Summary）
- Gemini Code Assist = IDE（VS Code / JetBrains / Cloud Workstations）内でコーディング支援 / PR レビュー
A: 役割が逆。
C: Gemini CLI はターミナル向けエージェント。

ひっかけポイント: Console = Cloud Assist、IDE = Code Assist、CLI = Gemini CLI の 3 区分を確実に。

問題 11

シナリオ: 金融系 SaaS Atlas Finance は本番 GKE クラスタへのデプロイで「承認者と作成者を必ず分離する」職務分掌を実施したいです。さらに、本番には署名検証されたコンテナイメージのみデプロイを許可したいです。

質問: 3 つ 選んでください（複数選択）。

選択肢:

A. release 作成者には roles/clouddeploy.releaser、承認者には roles/clouddeploy.approver を別グループで付与する
B. Binary Authorization ポリシーを有効化し、attestor が署名した attestation を持つイメージのみ許可する
C. すべての本番デプロイは Cloud Deploy 経由で行い、requireApproval: true を target に設定する
D. release 作成者と承認者を同じユーザーに付与し、self-approval を許可する
E. Cloud Deploy を経由せず kubectl apply で直接デプロイする

解答と解説

正解: A, B, C

解説:

A: releaser（作成）と approver（承認）を分離するのが Cloud Deploy IAM の職務分掌パターン。
B: Binary Authorization の attestor + attestation でデプロイ前の署名検証を実装。
C: target の requireApproval: true で本番昇格に承認必須を強制。
D: self-approval は職務分掌違反。
E: パイプライン迂回は監査性 / Binary Auth 統合を破壊。

ひっかけポイント: clouddeploy.releaser ≠ clouddeploy.approver。

関連: §2 Cloud Deploy IAM / Binary Authorization

問題 12

シナリオ: あるアプリチームは、本番への新リリースを 「最初の 10% ユーザーに 30 分間配信し、エラー率が許容内なら 50% に、さらに問題なければ 100% に拡大」 という段階的デプロイを実装したいです。各段階で自動 verify ジョブを実行し、メトリクス検証が失敗したら自動ロールバックさせたいです。

質問: Cloud Deploy で最適な strategy はどれですか。

選択肢:

A. standard（一括デプロイ）
B. canary strategy with percentages: [10, 50, 100] and verify: true
C. blueGreen strategy
D. recreate strategy

解答と解説

正解: B

解説:

B が正解: Cloud Deploy の canary strategy で percentages 配列を指定し、各 phase で verify ジョブが失敗したら自動ロールバック。
A: standard は一括で段階性なし。
C: Blue/Green は 2 環境並列で即時切替（段階性なし）。
D: Recreate は全削除→全作成。段階性なし。

ひっかけポイント: 段階的 + メトリクス検証 = Canary + verify。即時切替 = Blue/Green。

問題 13

シナリオ: EC サイト Hayama Mart の Cloud Build パイプラインは、プライベート GKE クラスタ内の Cloud SQL（Private IP のみ） に対してマイグレーションテストを実行する必要があります。デフォルトの Cloud Build では接続できません。

質問: 最適な解決策はどれですか。

選択肢:

A. Cloud SQL に Public IP を付与し、Authorized Networks に Cloud Build の IP レンジを許可する
B. Cloud Build Private Pool（Worker Pool） を作成し、自社 VPC とピアリングして Cloud SQL Private IP に到達できるようにする
C. Cloud Function を間に挟み Public 経由で接続する
D. Cloud SQL Auth Proxy を Public IP 経由で利用する

解答と解説

正解: B

解説:

B が正解: Cloud Build Private Pool は VPC 内で動作し、ピアリングで Private IP リソース（Cloud SQL / 内部 GKE / オンプレ）にアクセス可能。
A: Public IP 露出は Org Policy sql.restrictPublicIp 違反 / セキュリティリスク。
C: 不要な複雑化。
D: Public IP に依存し A と同じ問題。

ひっかけポイント: 「プライベートリソースにビルドからアクセス」= Cloud Build Private Pool 一択。

関連: §2 Cloud Build / トラブル即答

問題 14

シナリオ: DevOps チームは Artifact Registry に毎日 100+ の Docker イメージを push しており、ストレージコストが急増しています。古いイメージは自動削除したいが、本番で使用中（tag prod-*）のイメージは絶対に削除されてはなりません。

質問: 最適な実装はどれですか。

選択肢:

A. Cloud Scheduler + Cloud Function で日次バッチ削除する
B. Artifact Registry の Cleanup Policies を作成し、KEEP ルールで prod-* を保持、DELETE ルールで古い untagged イメージを削除する
C. Cloud Storage Lifecycle Rule を Artifact Registry に適用する
D. 古いリポジトリを手動削除する

解答と解説

正解: B

解説:

B が正解: Artifact Registry の Cleanup Policies は KEEP（保持優先）/ DELETE（削除）ルールで宣言的に管理。prod-* タグを KEEP すれば誤削除を防ぐ。
A: 自前実装は誤削除リスク・運用コスト大。
C: GCS Lifecycle は Artifact Registry に適用不可。
D: 手動削除は非スケーラブル。

ひっかけポイント: 「古いイメージ自動削除」= Cleanup Policies。

問題 15

シナリオ: Cymbal Bank のセキュリティ部門は 「SLSA Level 3 相当」 のサプライチェーン保証を達成したいです。具体的には：(1) ビルドが分離・改ざん不可な環境で実行される、(2) 署名付き Provenance が自動生成される、(3) デプロイ時に署名検証される、(4) デプロイ後も継続的に検証される。

質問: 最も適切な組み合わせはどれですか。

選択肢:

A. Cloud Build（Private Pool）+ Artifact Registry + Artifact Analysis + Binary Authorization + Continuous Validation
B. GitHub Actions（self-hosted）+ Docker Hub + Trivy
C. Cloud Build（default pool）+ Container Registry + 手動レビュー
D. Cloud Deploy + Cloud Run + IAM 制限のみ

解答と解説

正解: A

解説:

A が正解: これが Software Delivery Shield の標準構成。Cloud Build が SLSA L3 相当の 署名付き Provenance を自動生成、Artifact Analysis で CVE / SBOM、Binary Authorization で attestation 検証、Continuous Validation でデプロイ後も継続検証。
B: SLSA L3 を満たす保証なし。
C: Container Registry は廃止（→ Artifact Registry）、手動レビューは SLSA L4 の要件。
D: 署名検証 / Provenance がない。

ひっかけポイント: SLSA L3 の鍵 = hermetic / isolated build + 改ざん不可 Provenance。Cloud Build 標準が L3 達成。

関連: §2 SLSA / Software Delivery Shield

問題 16

シナリオ: オンライン教育 SaaS EduPlus は GKE Autopilot で本番運用しています。Cloud Run も使っている顧客向け Web は、突発トラフィック対応のため コールドスタートを最小化 したいです。また、WebSocket でリアルタイム通知を配信する Cloud Run サービスもあります。

質問: 2 つ 選んでください（複数選択）。

選択肢:

A. 顧客向け Web の Cloud Run に min-instances ≥ 1 を設定する
B. WebSocket 配信 Cloud Run に CPU always allocated を設定する
C. 全 Cloud Run サービスを concurrency=1 に設定する
D. Cloud Run を Cloud Functions Gen 1 に置き換える
E. すべての Cloud Run を min-instances=0 に維持しコスト最優先する

解答と解説

正解: A, B

解説:

A: min-instances ≥ 1 でコールドスタートを回避（待機分は課金されるが応答即時）。
B: WebSocket / gRPC ストリーミング / バックグラウンド処理は CPU always allocated が必須（request 時のみ CPU では接続維持中に CPU が停止する）。
C: concurrency=1 はインスタンス数爆発でコスト高、用途次第。
D: Gen 1 は古く Cloud Run functions（旧 Gen 2）が新標準。
E: コールドスタート最小化要件に反する。

ひっかけポイント: WebSocket = CPU always allocated。コールドスタート対策 = min-instances。

関連: §3 Cloud Run / §5 Cloud Run 最適化

問題 17

シナリオ: モバイルアプリ Snapfeed の SRE は、API の月次 SLO を 99.9% 可用性 に設定したいです。今月、サービス開始から 7 日が経過した時点で 1 時間の障害が発生しました。

質問: この時点での月次 Error Budget の残量は何 % ですか（月を 30 日 = 720 時間として概算）。

選択肢:

A. 約 95%
B. 約 60%
C. 約 17%（残り約 7 分）
D. すでに枯渇

解答と解説

正解: B

解説:

99.9% SLO の月次 Error Budget = 43 分 12 秒（720h × 0.001 = 0.72h = 43.2 分）
1 時間 = 60 分の障害で 60 / 43.2 ≈ 139% を消費

待ってください、これは枯渇しています。再計算します。

D が正解: 60 分の障害は 43.2 分の Error Budget を超えているため、すでに枯渇（マイナス）。
A / B / C: いずれも消費量が異常に低く、計算誤り。

ひっかけポイント: 99.9% = 月 43 分のダウン許容のみ。1 時間障害は 即枯渇。Error Budget Policy では新機能リリースを停止し、信頼性投資に集中する判断が必要。

正答（修正）: D

関連: §3 ダウンタイム表 / Error Budget Policy

問題 18

シナリオ: SRE チームは、SLO 99.9% のサービスに対して「ノイズの少ない、アクション可能な SLO アラート」を設計したいです。具体的には：(1) 1 時間で月次予算の 2% を消費するペースは即時 PagerDuty、(2) 6 時間で 5% は Slack 通知、(3) 3 日で 10% は Ticket。

質問: 最も適切な実装はどれですか。

選択肢:

A. CPU 使用率 > 80% でアラート
B. 5 分平均エラー率 > 0.5% で固定閾値アラート
C. Multi-window Multi-burn-rate アラート（Fast 14.4x@1h、Medium 6x@6h、Slow 1x@3d）を Cloud Monitoring Service Monitoring で設定
D. すべてのリクエストにアラート

解答と解説

正解: C

解説:

C が正解: SRE Workbook 第 5 章の Multi-window Multi-burn-rate が標準。Burn Rate ベースで誤検知 / 検知漏れを抑制。
- Fast burn 14.4x = 1h / 5min ウィンドウ = 1h で月予算 2% 消費 → PagerDuty
- Medium burn 6x = 6h / 30min ウィンドウ = 6h で 5% 消費 → Slack
- Slow burn 1x = 3d / 6h ウィンドウ = 3d で 10% 消費 → Ticket
A: 内部 CPU はユーザー影響を反映しない。
B: 固定閾値はノイズ多い。
D: ノイズの極致。

ひっかけポイント: SLO アラート = Multi-burn-rate。CPU しきい値や固定エラー率は時代遅れ。

問題 19

シナリオ: あるサービスで突然 5xx エラー率が急増しました。SRE チームの最初のアクションとして 最も適切 なものは何ですか。同サービスでは Feature Flag システム、Cloud Deploy ロールバック、追加リージョンへの redirect が利用可能です。30 分前に新機能を Feature Flag で 5% に有効化したことが判明しています。

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

選択肢:

A. ログを詳細に調査して根本原因を特定する
B. 影響緩和を最優先し、まず Feature Flag を OFF にする（最速の影響停止）
C. Postmortem を書く
D. Cloud Profiler でメモリリークを調査する

解答と解説

正解: B

解説:

B が正解: SRE 原則「Mitigate first」。新機能が原因の可能性高いため、最速の影響停止である Feature Flag OFF（秒単位）を実施。
A: 原因究明は後（インシデント解消後の Postmortem で実施）。
C: 解決後。
D: 解決後の深堀り。

ひっかけポイント: 障害対応の順序 = Mitigate → Capacity → Rollback → Root Cause。

問題 20

シナリオ: あるレガシー Java アプリは、突発的にレイテンシ p99 が悪化します。CPU 使用率は通常、メモリ使用量も安定。SRE はマルチスレッド処理の Mutex 待ち（ロック競合） を疑っています。

質問: 最適な調査ツールはどれですか。

選択肢:

A. Cloud Profiler の Contention profile
B. Cloud Profiler の Heap profile
C. Cloud Profiler の CPU time profile
D. Cloud Trace の waterfall view

解答と解説

正解: A

解説:

A が正解: Contention profile は Mutex 待ち / ロック競合の特定専用。Java で対応。
B: Heap は メモリリーク 用。
C: CPU time は CPU バウンド処理用。
D: Trace はサービス間ボトルネック特定（サービス境界）であり、コード内ロック競合は不可。

ひっかけポイント: Mutex 待ち = Contention。I/O 待ち含む経過時間 = Wall time。メモリリーク = Heap。

問題 21

シナリオ: Cymbal Logistics は アプリのコード変更なしで 各マイクロサービスの SLO（Availability、Latency）を計測したいです。サービス数は 40 個、すべて GKE 上で稼働しています。

質問: 最適な実装はどれですか。

選択肢:

A. 各サービスに OpenTelemetry SDK を組み込み、メトリクスを Cloud Monitoring に送信する
B. Cloud Service Mesh（旧 ASM） を導入し、istio_requests_total / istio_request_duration_milliseconds から Cloud Monitoring の Service Monitoring で SLO を作成する
C. アプリの 5xx 数を log-based metric で抽出し、SLO を作成する
D. Cloud Run に移行する

解答と解説

正解: B

解説:

B が正解: Cloud Service Mesh のサイドカー Envoy が自動で istio_requests_total / istio_request_duration_milliseconds を Cloud Monitoring に送信。アプリ未改修で 4 Golden Signals + SLO が実現。
A: コード変更不要要件に反する。
C: ログ依存は不正確 / 高コスト。
D: 移行は要件外。

ひっかけポイント: アプリ未改修 + SLO = Cloud Service Mesh。

関連: §3 / §4 Cloud Service Mesh SLO

問題 22

シナリオ: データ分析企業 Tableo は、毎週末の 4 時間 ML 学習に 8 台の A100 GPU を必要としますが、平日は不要です。On-Demand では確保できないことが多く、長期 Reservation はコスト過剰です。

質問: 最適な選択肢はどれですか。

選択肢:

A. On-Demand で都度起動する
B. 1 年 CUD で A100 を予約する
C. Dynamic Workload Scheduler（DWS）の Calendar mode で開始日時を指定して予約する
D. Spot VM の A100 を使う

解答と解説

正解: C

解説:

C が正解: DWS Calendar mode は最大 90 日、開始日時指定で GPU/TPU を予約。週末バッチに最適。
A: 確保困難の前提に反する。
B: 1 年 CUD は平日使わない時間も課金、過剰。
D: Spot は中断あり、4 時間連続学習に向かない。

ひっかけポイント: DWS Calendar mode = 開始日時指定 / 最大 90 日、Flex-start = 7 日まで（待てるバッチ）。

問題 23

シナリオ: ある E コマースの GKE クラスタで、Black Friday に向けて Pod 数自動増減を実装したいです。さらに、メモリ要求が誤って過剰に設定されている Pod が多く、適正値も自動で調整したいです。

質問: 最も適切な組み合わせ はどれですか。

選択肢:

A. HPA（CPU 70%）+ VPA（メモリ、同一 Deployment に CPU と同じメトリクス）+ Cluster Autoscaler
B. HPA（CPU/RPS）+ VPA（メモリのみ、CPU は HPA に委ねる）+ Cluster Autoscaler
C. VPA のみ（垂直スケール）
D. すべて手動でスケール

解答と解説

正解: B

解説:

B が正解: HPA（Pod 数）+ VPA（Pod size）+ Cluster Autoscaler（Node 数）の組み合わせ。HPA と VPA を同じメトリクス（CPU）で同時利用は衝突するため NG。メモリは VPA、CPU は HPA に分担する。
A: HPA + VPA を同じ CPU メトリクスで使うと衝突。
C: 水平スケールがないとピーク捌けない。
D: 自動化要件違反。

ひっかけポイント: HPA + VPA 同メトリクスは NG。

問題 24

シナリオ: SRE チームは Postmortem の運用を標準化したいです。次のうち、Postmortem に必須 な要素はどれですか。3 つ 選んでください。

選択肢:

A. Blameless（個人を責めない）
B. Timeline（検知→対応→復旧）
C. Action Items（担当者と期限）
D. 責任者の個人特定と人事評価への反映
E. 役員のみへの非公開共有

解答と解説

正解: A, B, C

解説:

A: Blameless は SRE Postmortem の 第一原則。
B: Timeline は学びの基盤。
C: Action Items（担当・期限）なしの Postmortem は意味なし。
D: Blameless 原則に違反。
E: Postmortem は 社内公開 が原則（学びの共有）。

ひっかけポイント: 責任追及・非公開は Postmortem 文化の否定。

問題 25

シナリオ: Cymbal Telecom は Compliance 要件で 「誰がどのデータを読んだか」 をすべて Audit Log として記録し、7 年間保管しなければなりません。デフォルトでは記録されていません。

質問: 2 つ 選んでください（複数選択）。

選択肢:

A. Cloud Audit Logs の Data Access Logs（DATA_READ サブカテゴリ）を IAM Policy で 明示的に有効化 する
B. すべての Admin Activity Logs を有効化する（デフォルト有効）
C. Aggregated Sink を Org レベルで作成し、Cloud Storage Archive class へ Lifecycle 付きで 7 年保管 する
D. 各プロジェクトの _Default バケットの保持期間を 7 年（2555 日）に設定する
E. Trace を 7 年間保持する

解答と解説

正解: A, C

解説:

A: Data Access Logs はデフォルト無効。Compliance なら明示有効化が必須。
C: 7 年保管の最安は Cloud Storage Archive class + Lifecycle。
B: Admin Activity は記録対象外（操作監査のみ、データ読書ではない）。
D: _Default の最大保持は 3650 日（10 年）まで設定可能だが、ログ保管コストが GCS Archive より高い。Compliance 安価最適化なら C。
E: Trace は別物。

ひっかけポイント: Data Access ログは デフォルト無効。Compliance なら必ず明示有効化。

問題 26

シナリオ: SRE チームはアラート発生時、Gemini Cloud Assist の Investigations 機能を活用して 根本原因の仮説提示 を受けたいと考えています。具体的には、アラート発生時に最近のデプロイ・構成変更・トラフィック異常を相関分析させたいです。

質問: 最も適切な実装はどれですか。

選択肢:

A. Cloud Trace のみで分析する
B. Gemini Cloud Assist Investigations をアラートにリンクし、最近のデプロイ・変更を相関させた根本原因仮説を自動生成させる
C. すべてのログを Cloud Functions で AI 解析する自前実装
D. Vertex AI Search を Logging に接続する

解答と解説

正解: B

解説:

B が正解: Gemini Cloud Assist Investigations はアラートから根本原因仮説を AI が提示する MTTR 短縮機能。最近のデプロイ / 構成変更 / トラフィック異常を相関分析。
A: Trace 単独では構成変更相関は不可。
C: 自前実装は運用負荷大。
D: Vertex AI Search は文書検索向け、Observability 用途ではない。

ひっかけポイント: AI で MTTR 短縮 = Gemini Cloud Assist Investigations。

問題 27

シナリオ: OSS Prometheus を運用している企業が GKE に新規移行します。Prometheus の PromQL 互換性を保ちつつ、自社で Prometheus サーバの HA / スケール / 24 ヶ月の長期保持を管理したくありません。

質問: 最適なサービスはどれですか。

選択肢:

A. Cloud Monitoring のカスタムメトリクスのみ使う
B. OSS Prometheus を GKE Pod としてセルフ運用
C. Managed Service for Prometheus（GMP） Managed Collection を使う
D. Datadog に乗り換える

解答と解説

正解: C

解説:

C が正解: Managed Service for Prometheus（GMP） は PromQL 100% 互換 + 自動スケール + 最大 24 ヶ月保持。新規 GKE は Managed Collection（推奨）、OSS Prometheus 移行は Self-deployed Collection。
A: PromQL 互換不要要件に反する（カスタムメトリクスは PromQL 非対応）。
B: 自己運用要件と矛盾。
D: GCP ネイティブ選択肢が優先。

ひっかけポイント: 新規 GKE = GMP Managed Collection、既存 OSS 移行 = Self-deployed Collection。

関連: §4 Managed Service for Prometheus

問題 28

シナリオ: ある SaaS は Cloud Run（HTTPS）+ GKE + Cloud Functions のマルチサービスで構成されています。エンドユーザーの 1 リクエストが「Cloud Run → Pub/Sub → Cloud Functions → GKE Service」と複数のサービスを横断しており、どこで時間がかかっているか を特定できません。

質問: 最適なツールはどれですか。

選択肢:

A. Cloud Logging の grep で時刻を辿る
B. Cloud Trace の Waterfall view + OpenTelemetry で W3C Trace Context を全サービスに伝播
C. Cloud Profiler の Wall time profile
D. VPC Flow Logs

解答と解説

正解: B

解説:

B が正解: 分散トレース = Cloud Trace + OpenTelemetry SDK + W3C Trace Context ヘッダ伝播。Waterfall でサービス境界の遅延を可視化。
A: ログから手動辿りは現実的でない。
C: Profiler はコード行ホットスポット用（サービス境界ではない）。
D: VPC Flow Logs は L3/L4 ネットワーク、アプリ層トレースではない。

ひっかけポイント: マイクロサービス間遅延ボトルネック = Cloud Trace。W3C Trace Context が OTel 標準伝播。

問題 29

シナリオ: あるサービスのログ取り込みコストが先月 $5,000 に急増しました。原因は debug ログを誤って INFO レベルで全 Cloud Logging に送信していたためです。緊急にコストを下げたい一方、本番運用は止められません。

質問: 最も即効性のあるコスト削減 はどれですか。

選択肢:

A. Log Retention を 30 日から 7 日に短縮
B. Log Router で Exclusion filter を作成し、debug ログの ingestion 自体を 0 にする
C. Sink を BigQuery に追加して逃がす
D. Cloud Logging を停止する

解答と解説

正解: B

解説:

B が正解: Exclusion filter は取り込み課金そのものを 0 にする最強手段。即効性 No.1。
A: Retention 短縮はストレージ課金のみ削減（ingestion 課金が支配的なら効果薄）。
C: Sink 追加は重複課金（BQ も課金、ingestion 課金は変わらず）。
D: 本番運用停止は不可。

ひっかけポイント: ログコスト削減順位 = Exclusion > Sampling > Retention 短縮。Sink 追加は 重複課金トラップ。

問題 30

シナリオ: ある Python アプリでメモリ使用量が時間とともに増加し、最終的に OOMKilled で再起動します。Cloud Profiler でメモリリーク調査したいですが、組み込み後 Heap profile が取得できません。

質問: 最も適切な対処はどれですか。

選択肢:

A. Python の Cloud Profiler を Heap profile に切り替える
B. Python は Cloud Profiler の Heap profile に非対応のため、tracemalloc + Cloud Monitoring カスタムメトリクスで代替
C. アプリを Go に書き直す
D. Cloud Trace を導入する

解答と解説

正解: B

解説:

B が正解: Cloud Profiler の Python サポートは CPU / Wall time のみで、Heap は非対応。Python ではアプリ内 tracemalloc でメモリスナップショットを取り、Cloud Monitoring カスタムメトリクスに送るのが現実解。
A: 機能なし。
C: 過剰対応。
D: Trace はメモリリーク調査用ではない。

ひっかけポイント: 「Python のメモリリークに Profiler Heap」は誤り（よくある試験ひっかけ）。

問題 31

シナリオ: ある SaaS の Cloud Run サービスは平日昼間にトラフィックが集中し、夜間はほぼゼロです。コスト最適化のため、夜間はインスタンスをゼロまでスケールイン したいが、昼間の初回ユーザーのコールドスタートは避けたいです。

質問: 最も適切な設定はどれですか。

選択肢:

A. min-instances=10、max-instances=100
B. min-instances=0、CPU always allocated
C. min-instances=0 をベースに、平日昼間のみ Cloud Scheduler 経由で min-instances=2 に動的更新する
D. すべて Cloud Functions に移行する

解答と解説

正解: C

解説:

C が正解: Cloud Run の min-instances を 時間帯で動的更新 する公式パターン。Cloud Scheduler + Cloud Run Admin API で実現。夜間は 0、昼間は 2 でコールドスタート回避とコスト両立。
A: 夜間も 10 インスタンス課金で過剰。
B: min-instances=0 ではコールドスタートが起きる。
D: Cloud Functions 移行は要件外で過剰対応。

ひっかけポイント: 時間帯別の Cloud Run スケール = Scheduler + min-instances 動的更新。

問題 32

シナリオ: あるアプリのインスタンスタイプを 過去 8 日間の実使用 に基づいて適正サイズに自動提案させたいです。VM が過剰スペックで稼働しているケースが多発しています。

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

選択肢:

A. Active Assist の VM Rightsizing Recommender
B. Cloud Monitoring の CPU メトリクスを目視で確認
C. Cloud Trace
D. Cloud Asset Inventory

解答と解説

正解: A

解説:

A が正解: VM Rightsizing Recommender は 過去 8 日 の CPU / メモリ使用量から適正マシンタイプを自動提案。Active Assist の Cost カテゴリ。
B: 手動で非スケール。
C: 別目的。
D: Asset Inventory はリソース棚卸し、提案機能ではない。

ひっかけポイント: Rightsizing 分析期間は過去 8 日（数値暗記）。

問題 33

シナリオ: SRE チームは Cloud Monitoring で distribution 型 log-based metric を作成し、API レイテンシ分布を可視化したいです。各バケットの密度を時系列で見られるグラフ形式は何ですか。

質問:

選択肢:

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

解答と解説

正解: C

解説:

C が正解: Heatmap は distribution metric の各バケット密度を時系列で可視化する標準。
A: Line は単一系列向け。
B: Stacked bar はカテゴリ別積み上げ。
D: Pie は時系列に不適。

ひっかけポイント: distribution metric = Heatmap、分位点取得 PromQL = histogram_quantile。

関連: §4 Monitoring チャート / PromQL

問題 34

シナリオ: 本番 GKE で OPA ベースのポリシー を強制したいです。具体的には：(1) 特定の Namespace 以外で hostPath を禁止、(2) latest タグの Image を禁止、(3) リソース request / limit 未指定 Pod を拒否。マルチクラスタで一貫適用したいです。

質問: 最適なサービスはどれですか。

選択肢:

A. PodSecurityPolicy（PSP）
B. Policy Controller（旧 Anthos Policy Controller、OPA / Gatekeeper ベース）+ Config Sync で配布
C. Network Policy
D. IAM Conditional Role

解答と解説

正解: B

解説:

B が正解: Policy Controller は OPA / Gatekeeper ベース、Config Sync 配布でマルチクラスタ一貫ポリシー強制が実装可能。
A: PSP は GA 廃止（v1.25 で削除）。代替は Pod Security Admission または Policy Controller。
C: Network Policy は L3/L4 通信制御、用途違い。
D: IAM はリソース API レベル、K8s manifest 内容検証は不可。

ひっかけポイント: OPA / Gatekeeper = Policy Controller。PSP は廃止。

関連: §1 複数環境管理 / Policy Controller

問題 35

シナリオ: あるサービスは月次 SLO 99.95% で運用しています。今月 1 週間（7 日 = 168 時間）が経過し、累計 5 分のダウンタイムが発生しました。

質問: 現時点での Error Budget 消費率はおよそ何 % ですか？

選択肢:

A. 約 5%
B. 約 23%
C. 約 50%
D. 約 100%（枯渇）

解答と解説

正解: B

解説:

99.95% SLO の月次 Error Budget = 21 分 36 秒（720h × 0.0005 = 0.36h = 21.6 分）
5 分 / 21.6 分 = 約 23.1% 消費
残量約 77%、まだ通常リリース可能（Error Budget Policy で 100-75% は新機能リリース自由）

ひっかけポイント: 99.95% = 月 21 分 36 秒（暗記）。

関連: §3 ダウンタイム表 / Error Budget Policy

問題 36

シナリオ: ある GKE クラスタで、CI/CD パイプライン経由でデプロイされる Pod は すべて Binary Authorization で署名検証 されています。攻撃者が kubectl run --image=evil-image のような 手動デプロイで攻撃イメージを投入 しようと試みました。

質問: Binary Authorization が実際に検証拒否したことを 証跡として確認 するには、どの Audit Log を確認すべきですか。

選択肢:

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

解答と解説

正解: C

解説:

C が正解: Binary Authorization の拒否ログは Policy Denied（cloudaudit.googleapis.com/policy）に記録。デフォルト有効。
A: Admin Activity はリソース変更操作。
B: Data Access はデータ読書（デフォルト無効、要明示）。
D: System Event は GCP 内部イベント。

ひっかけポイント: 「Binary Auth 拒否」 / 「VPC SC 拒否」 / 「IAM 拒否」 = Policy Denied。

問題 37

シナリオ: SRE チームはトレースサンプリングで「エラーや遅い trace は 100% 保持しつつ、正常 trace は低レートに」したいです。SDK 側ではなく Collector 側で実装したいです。

質問: 最適な実装はどれですか。

選択肢:

A. SDK 側で Probabilistic sampling 1%
B. OpenTelemetry Collector で Tail-based sampling を構成し、エラー / 遅延 trace を優先保持
C. Cloud Trace のデフォルトサンプリング（0.1 req/s）
D. すべての trace を 100% 保持

解答と解説

正解: B

解説:

B が正解: Tail-based sampling は Collector 側でトレース完了後にエラー / 遅延を判定し、優先保持する手法。Head-based は SDK 側で開始時に判定するため、エラー時の保持保証ができない。
A: SDK 側 / 確率的 = エラー保持保証なし。
C: デフォルトは賢くない。
D: コスト爆発。

ひっかけポイント: エラー trace を必ず保持 = Tail-based sampling（Collector 側）。

関連: §4 OpenTelemetry サンプリング

問題 38

シナリオ: あるサービスの 2 つの VPC 間で Connection が確立できない という障害が発生しました。原因として FW ルール、Route、Network Tag、Service Account の可能性があります。手動で全構成を確認するのは時間がかかります。

質問: 最適な診断ツールはどれですか。

選択肢:

A. VPC Flow Logs
B. Network Intelligence Center の Connectivity Tests（2 点間到達性診断）
C. Performance Dashboard
D. Firewall Insights

解答と解説

正解: B

解説:

B が正解: Connectivity Tests は 2 点間の構成解析を自動実行し、FW / Route / VPN / Peering の阻害箇所をピンポイント特定。
A: Flow Logs は実トラフィックの 5-tuple 記録、設定問題の自動解析は不可。
C: Performance Dashboard は GCP インフラ内パケットロス / レイテンシ用。
D: Firewall Insights は使われていない FW ルール検出。

ひっかけポイント: 2 点間到達性 = Connectivity Tests、不要 FW ルール = Firewall Insights、GCP インフラ性能 = Performance Dashboard、VPC 全体可視化 = Network Topology。

問題 39

シナリオ: ある会社は 「グローバル LB が必要、世界中のユーザーに最速配信」 の Web サービスを運用しており、別に 「同一リージョン内のバッチ転送で最大限コスト削減」 したい用途もあります。

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

選択肢:

A. Web: Standard / バッチ: Premium
B. Web: Premium / バッチ: Standard
C. 両方 Premium
D. 両方 Standard

解答と解説

正解: B

解説:

B が正解: グローバル LB が必要なら Premium Network Tier 必須（Standard は Regional LB のみ対応）。リージョン内バッチで安く済ませるなら Standard（25-50% 安い）。
A: 役割が逆。
C / D: コスト or 機能で片方が不利。

ひっかけポイント: グローバル LB / SLA 99.99% = Premium。リージョン内 / コスト最優先 = Standard。

問題 40

シナリオ: 監査要件で、本番プロジェクトに対して kubectl exec のような データレイヤーへのアクセス をすべて記録したいです。コストは多少かかってもよいです。

質問: 2 つ 選んでください。

選択肢:

A. Cloud Audit Logs の Data Access Log を IAM Policy で明示的に有効化する（DATA_READ / DATA_WRITE / ADMIN_READ）
B. Data Access Log は デフォルト無効 のため、有効化しなければ記録されない
C. Admin Activity Log だけあれば十分
D. System Event Log を有効化する
E. Cloud Trace でカバーする

解答と解説

正解: A, B

解説:

A: 監査要件達成のため明示有効化が必要。
B: Data Access はデフォルト無効（試験頻出ファクト）。
C: Admin Activity は構成変更のみで、データ操作は記録しない。
D: System Event は GCP 内部イベント。
E: Trace はパフォーマンス分析用。

ひっかけポイント: 「データ操作監査」= Data Access ログ明示有効化 が必須。

問題 41

シナリオ: あるサービスの月次バッチ処理が 24 時間連続で動作 し、コストを最大限抑えたいです。中断されても自動再起動で対応できる設計です。

質問: 最適な選択肢はどれですか。

選択肢:

A. オンデマンド VM
B. Preemptible VM（24h 上限あり）
C. Spot VM（24h 上限なし、最大 91% OFF）
D. 1 年 CUD

解答と解説

正解: C

解説:

C が正解: Spot VM は最大 91% OFF / 24h 上限なし。中断通知 30 秒前。中断耐性設計なら最安。
A: 高コスト。
B: 旧 Preemptible は 24h 上限あり。Spot が後継。
D: 24 時間 / 月のみの稼働で 1 年 CUD は過剰。

ひっかけポイント: Preemptible は 24h 上限あり / Spot は上限なし（Preemptible は旧、Spot が新標準）。

問題 42

シナリオ: ある SaaS は GKE Standard で Namespace 単位の課金可視化 を実現したいです。各チームに自分の Namespace のコストを ChargeBack したいです。

質問: 最適な実装はどれですか。

選択肢:

A. 各 Namespace を別プロジェクトに分ける
B. GKE Cost Allocation を有効化し、Billing を BigQuery Export して Namespace ラベル別に集計
C. 手動で kubectl top pod を集計
D. Cloud Monitoring のカスタムメトリクスで CPU 時間を測る

解答と解説

正解: B

解説:

B が正解: GKE Cost Allocation + Billing BigQuery Export で Namespace / Label 単位のコスト集計が公式パターン。Looker Studio で可視化。
A: クラスタ分離は運用過剰。
C: 非スケール / 不正確。
D: コスト直接計算ではない。

ひっかけポイント: GKE Namespace 別コスト = GKE Cost Allocation + BigQuery Billing Export。

問題 43

シナリオ: ある企業の本番 GKE クラスタは、ノードの計画的メンテナンス時に Pod が一斉停止 して可用性低下が発生しました。再発防止策として、ノードドレイン時に最低でも 2 Pod は維持 したいです。

質問: 最適な実装はどれですか。

選択肢:

A. HPA で minReplicas=2 を設定
B. Pod Disruption Budget（PDB）で minAvailable: 2 を設定
C. NodePool を 1 つに統一
D. Deployment の replicas=2 を設定

解答と解説

正解: B

解説:

B が正解: PDB（Pod Disruption Budget）は 計画的中断時に最低稼働 Pod 数を保証。kubectl drain / アップグレード時に尊重される。
A: HPA は scale-out / in、drain 時の保証ではない。
C: NodePool 統一は無関係。
D: replicas は通常時の数で、drain 時に同時退避を防げない。

ひっかけポイント: 計画的中断時の Pod 保証 = PDB。

問題 44

シナリオ: SRE チームは Cloud Run で TLS 証明書を Google が自動更新 する Web サービスを公開したいです。証明書の更新作業を運用から完全に排除したいです。

質問: 最適なサービスはどれですか。

選択肢:

A. Cloud KMS
B. Secret Manager
C. Certificate Manager（Google-managed certificate）
D. Parameter Manager

解答と解説

正解: C

解説:

C が正解: Certificate Manager は TLS 証明書のマネージドサービス。Google-managed certificate は自動更新。
A: KMS は暗号鍵、TLS 証明書管理ではない。
B: Secret Manager は値の保管、証明書ライフサイクル管理ではない。
D: Parameter Manager は非機密構成値。

ひっかけポイント: TLS 証明書 = Certificate Manager。

問題 45

シナリオ: ある会社は Compliance 要件で 「アプリのログから個人情報（PII）を確実に取り除いてから保管」 する必要があります。Cloud Logging に既に PII が含まれた状態で送信されることを防止したいです。

質問: 最も推奨される実装はどれですか。

選択肢:

A. Cloud Logging の Log Router で Exclusion filter を作成
B. アプリケーション層で Sensitive Data Protection（旧 Cloud DLP）API を呼び出し、構造化ログ送信前にリダクション
C. BigQuery に送ってから手動マスキング
D. Audit Log で監視

解答と解説

正解: B

解説:

B が正解: アプリ層で Sensitive Data Protection（DLP）API でリダクション が最確実。Logging 取り込み前に PII を除去。
A: Exclusion は完全削除であり、必要な部分も失う。
C: 既に PII が永続化されてしまう。
D: 監視のみで除去にならない。

ひっかけポイント: PII 除去 = アプリ層で Sensitive Data Protection（DLP）API。

問題 46

シナリオ: あるサービスは Cloud Run 上で稼働し、X-Cloud-Trace-Context ヘッダで自動的に Trace ID と紐付けられます。SRE が 構造化ログから Trace へワンクリックジャンプ できるようにしたいです。

質問: ログに含めるべき構造化フィールドはどれですか。

選択肢:

A. trace_id カスタムフィールド
B. logging.googleapis.com/trace（値: projects/PROJECT_ID/traces/TRACE_ID）
C. traceparent
D. X-B3-TraceId

解答と解説

正解: B

解説:

B が正解: Cloud Logging と Cloud Trace の紐付け公式フィールドは logging.googleapis.com/trace（フル形式: projects/PROJECT_ID/traces/TRACE_ID）、加えて logging.googleapis.com/spanId、logging.googleapis.com/trace_sampled。
A: カスタム名では Logs Explorer の Trace ジャンプ動作しない。
C: traceparent は HTTP ヘッダ（W3C Trace Context）、ログ内フィールド名ではない。
D: B3 形式は Zipkin / Istio 用、Cloud Logging の連携キーではない。

ひっかけポイント: trace 紐付けは logging.googleapis.com/trace という特定フィールド名。

問題 47

シナリオ: ある SaaS は Cloud Deploy で複数リージョン（us-central1 / asia-northeast1 / europe-west1）へ 同時並列デプロイ したいです。各リージョンへの rollout を 1 つの release で起動し、進行状況を統一管理したいです。

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

選択肢:

A. 各リージョンに別 Delivery Pipeline を作成し、手動で release を 3 つ作る
B. Cloud Deploy の Multi-target Pipeline（複数 target を 1 つの release で並列 rollout）
C. Cloud Run の Traffic Splitting で複数リージョンに分散
D. Cloud Functions で並列デプロイをトリガー

解答と解説

正解: B

解説:

B が正解: Cloud Deploy の Multi-target（Parallel Deployment）は複数 target に 1 release で同時 rollout が可能。リージョン並列デプロイの公式パターン。
A: 手動運用で監査性低下。
C: Cloud Run の単体機能で Cloud Deploy 連携ではない。
D: 自前実装で過剰。

ひっかけポイント: マルチリージョン並列 = Cloud Deploy Multi-target。

関連: §2 ハイブリッド・マルチクラウド早見表

問題 48

シナリオ: ある会社は Cloud Build で 「外部 OSS 公式 Docker Hub のイメージを社内全ビルドで再利用」 するため、毎回 Docker Hub に直接 pull するのを避けたいです（rate limit / レイテンシ / 可用性）。

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

選択肢:

A. 各ビルドでイメージを再ビルドする
B. Artifact Registry の Remote Repository を Docker Hub のキャッシュとして作成
C. GCS バケットに docker save した tar を保管
D. Container Registry に手動で push

解答と解説

正解: B

解説:

B が正解: Artifact Registry の Remote Repository は外部 OSS（Docker Hub / Maven Central / npm 等）の 透過的キャッシュ。初回 pull で AR にキャッシュされ、以降は高速・rate limit 回避。
A: 重複ビルド。
C: 手動運用。
D: Container Registry は廃止予定。

ひっかけポイント: 外部リポジトリキャッシュ = Remote Repository、複数リポジトリ統合 = Virtual Repository。

問題 49

シナリオ: ある E コマースで深夜帯に Cloud Run が突然 5xx 急増しました。SRE は GCP Console で メトリクスチャートに表示された異常スパイクの意味を自然言語で説明 させたいです。

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

選択肢:

A. Cloud Profiler の Wall time profile
B. Gemini Cloud Assist の Explain this chart
C. Cloud Trace の Waterfall view
D. Cloud Logging の grep 検索

解答と解説

正解: B

解説:

B が正解: Gemini Cloud Assist の "Explain this chart" 機能は Cloud Monitoring チャートを自然言語で解説。スパイクの意味、相関する他メトリクス、過去類似事例を提示。
A: Profiler はコード行ホットスポット。
C: Trace はサービス境界遅延。
D: ログ検索は手動。

ひっかけポイント: メトリクスチャート自然言語解説 = Gemini Cloud Assist Explain this chart。

問題 50

シナリオ: ある会社は GKE Autopilot で Pod に必要なノードリソースが既存 Node Pool に無い 場合、自動で新規 Node Pool を生成させたいです（例: GPU 要求 Pod を投入したら GPU Node Pool を自動作成）。

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

選択肢:

A. Cluster Autoscaler のみ
B. HPA
C. Node Auto-Provisioning（NAP）
D. Vertical Pod Autoscaler

解答と解説

正解: C

解説:

C が正解: Node Auto-Provisioning（NAP） は Node Pool 自体を自動生成 する機能。Pod の要求リソース（GPU / Memory / Local SSD）に応じて新規プールを動的作成。Autopilot ではデフォルト機能。
A: Cluster Autoscaler は既存 Node Pool 内でのノード数増減のみ。
B: HPA は Pod 数。
D: VPA は Pod の requests/limits 調整。

ひっかけポイント: Cluster Autoscaler = 既存プール内ノード増減、NAP = プール自体を新規作成。

関連: §3 / §5 GKE オートスケール

解答一覧（早見表）

#	正答	セクション
1	B	1
2	B	1
3	B	1
4	A, B, C	1
5	C	1
6	B	1
7	C	1
8	B	1
9	B	1
10	B	1
11	A, B, C	2
12	B	2
13	B	2
14	B	2
15	A	2
16	A, B	2
17	D	3
18	C	3
19	B	3
20	A	3
21	B	3
22	C	3
23	B	3
24	A, B, C	3
25	A, C	4
26	B	4
27	C	4
28	B	4
29	B	4
30	B	4
31	C	5
32	A	5
33	C	4
34	B	1
35	B	3
36	C	4
37	B	4
38	B	4
39	B	5
40	A, B	4
41	C	5
42	B	5
43	B	3
44	C	2
45	B	4
46	B	4
47	B	2
48	B	2
49	B	4
50	C	5

セクション別正答率自己採点表

セクション	該当問題番号	問題数	正答数	正答率
1. Bootstrapping & maintaining GCP org	1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 34	11	__	__ %
2. CI/CD pipelines	11, 12, 13, 14, 15, 16, 44, 47, 48	9	__	__ %
3. SRE practices	17, 18, 19, 20, 21, 22, 23, 24, 35, 43	10	__	__ %
4. Observability & troubleshooting	25, 26, 27, 28, 29, 30, 33, 36, 37, 38, 40, 45, 46, 49	14	__	__ %
5. Performance & cost	31, 32, 39, 41, 42, 50	6	__	__ %
合計	—	50	__	__ %

上記の「問題数」は実際の比重再現に伴う見直し配分です（問 34 は §1 / 問 44 は §2 / 問 33, 45, 46, 49 は §4 等、設問内容に基づきセクション最終分類）。比重ターゲット（§1=20%, §2=25%, §3=18%, §4=25%, §5=12%）にほぼ準拠しています。

合否判定の目安

合計正答率	評価
90% 以上	余裕で合格圏
80-89%	合格圏
70-79%	合格ライン（本番では油断禁物）
60-69%	要復習（弱点セクションを集中学習）
60% 未満	基礎再学習を推奨

弱点セクション別の復習リンク

正答率が低かったセクションは、以下の学習資料に戻って復習してください。

セクション	要点復習	基礎	応用	問題集
1. 組織と基盤	`../02_学習資料/01_組織と基盤/03_要点と暗記.md`	`../02_学習資料/01_組織と基盤/01_基礎.md`	`../02_学習資料/01_組織と基盤/02_応用.md`	`../03_問題集/section1_問題集.md`
2. CI/CD パイプライン	`../02_学習資料/02_CICDパイプライン/03_要点と暗記.md`	`../02_学習資料/02_CICDパイプライン/01_基礎.md`	`../02_学習資料/02_CICDパイプライン/02_応用.md`	`../03_問題集/section2_問題集.md`
3. SRE プラクティス	`../02_学習資料/03_SREプラクティス/03_要点と暗記.md`	`../02_学習資料/03_SREプラクティス/01_基礎.md`	`../02_学習資料/03_SREプラクティス/02_応用.md`	`../03_問題集/section3_問題集.md`
4. 可観測性とトラブルシュート	`../02_学習資料/04_可観測性とトラブルシュート/03_要点と暗記.md`	`../02_学習資料/04_可観測性とトラブルシュート/01_基礎.md`	`../02_学習資料/04_可観測性とトラブルシュート/02_応用.md`	`../03_問題集/section4_問題集.md`
5. パフォーマンスとコスト	`../02_学習資料/05_パフォーマンスとコスト/03_要点と暗記.md`	`../02_学習資料/05_パフォーマンスとコスト/01_基礎.md`	`../02_学習資料/05_パフォーマンスとコスト/02_応用.md`	`../03_問題集/section5_問題集.md`

次のステップ

35 問以上正解 → 模擬試験 2 へ進み、本番形式の演習を継続
35 問未満 → 弱点セクションの 要点と暗記 を 3 周ループしてから再挑戦
計算問題（Q17, Q35）で失点 → ダウンタイム表（99.9% = 43 分 / 99.95% = 21.6 分 / 99.99% = 4 分 / 99.999% = 26 秒）を 手書きで再現できる まで暗記

模擬試験 2 へ: ./模擬試験2.md（未作成の場合は次のステップで作成）

次回受験のメモ: 本模擬試験は 2 週間〜1 ヶ月後に再挑戦し、90% 以上を目指してください。同じ問題で 90% に届かない場合、暗記が定着していません。