Professional Cloud DevOps Engineer — シラバス詳細

公式 Exam Guide（2025年改訂版）を日本語で完全翻訳・補足したものです。 各 Considerations（ブレットポイント）は試験で問われる具体的な観点 なので、項目ごとに「何ができるべきか」を明示しています。

試験全体像

Section 1: Bootstrapping and maintaining a Google Cloud organization (~20%)

Google Cloud 組織を 正しい姿で立ち上げ、維持する スキル。リソース階層・ネットワーク・IAM・IaC・CI/CD 基盤・マルチ環境管理・開発者環境セットアップの 5 軸。

1.1 Designing the overall resource hierarchy for an organization

学習ポイント: 組織 → フォルダ → プロジェクトの設計、複数プロジェクト横断のネットワーク／ログ／モニタリング、IAM ロールと組織ポリシー、サービスアカウント運用、データレジデンシー要件。

Considerations:

• Organizing resources — アプリケーション中心 vs ライフサイクル中心、プロジェクト/フォルダの粒度
• Shared networking — Shared VPC、VPC Network Peering、Private Service Connect の使い分け
• Multi-project monitoring and logging — Logging sink の集約、Monitoring の Metrics Scope
• IAM roles and organization-level policies — 事前定義/カスタムロール、組織ポリシー（Constraint）
• Creating and managing service accounts — キー管理回避（Workload Identity / WIF）
• Data residency — リージョン制限、Org Policy で gcs/compute のロケーション制限

典型問題パターン:

• 「複数 BU をどう分けるか」→ フォルダ階層 + Org Policy
• 「キーレス認証」→ Workload Identity Federation
• 「全プロジェクトのログを 1 箇所に」→ aggregated sink at Organization

1.2 Managing infrastructure

学習ポイント: IaC ツール選定、ブループリント／ベストプラクティス、スクリプトでの自動化。

Considerations:

• IaC tooling and managed services — Infrastructure Manager（Terraform マネージド版）、Cloud Foundation Toolkit (CFT)、Config Connector、GitOps、Terraform、Helm
• Making infrastructure changes using Google-recommended practices and blueprints — Cloud Foundation Fabric、Terraform Modules for Google
• Automation with scripting — Python / Go（GCP クライアントライブラリ）

典型問題パターン:

• 「Terraform を GCP マネージドで」→ Infrastructure Manager
• 「Kubernetes から GCP リソース管理」→ Config Connector
• 「組織ベースラインの IaC」→ CFT / Cloud Foundation Fabric

1.3 Designing a CI/CD architecture stack in Google Cloud, hybrid, and multi-cloud environments

学習ポイント: CI と CD を分離し、各ステージのツール選定とセキュリティ設計を行えること。

Considerations:

• CI with Cloud Build — Buildpacks、private pool、worker pool、IAM
• CD with Cloud Deploy — Kustomize、Skaffold、リリースパイプライン、Targets、Phases
• Artifact Registry configuration — Docker / Maven / npm / Python / Helm、リージョン選定、Remote/Virtual Repository
• Widely used third-party tooling — Git、Jenkins、Argo CD、Packer、kpt
• Security of CI/CD tooling — Cloud Build SA 権限最小化、Artifact Registry IAM、Workload Identity for GKE runners

典型問題パターン:

• 「マルチクラウドへ K8s デプロイ」→ Cloud Deploy + Skaffold（GKE / Anthos）
• 「Jenkins を残したい」→ Cloud Build と併用、Artifact Registry を共有
• 「OCI イメージのプロモーション」→ Artifact Registry + Cloud Deploy

1.4 Managing multiple environments (e.g., staging, production)

学習ポイント: Dev/Staging/Prod の隔離と一貫性、エフェメラル環境、構成・ポリシー管理、GKE フリート、安全なパッチ／アップグレード。

Considerations:

• Managing ephemeral environments — プルリク毎のプレビュー環境（Cloud Run revisions / GKE namespace）
• Managing configuration and policy — Config Sync、Policy Controller、Anthos Config Management
• Managing GKE clusters across an enterprise — Fleets（旧 Environs）、Multi-cluster Ingress、Multi-cluster Services
• Safe and secure patching and upgrading practices — GKE auto-upgrade、release channels（Rapid/Regular/Stable）、Surge / Blue-Green Node Pool upgrades

典型問題パターン:

• 「PR ごとのプレビュー」→ Cloud Run preview revision + traffic 0
• 「全クラスタ共通ポリシー」→ Policy Controller (Gatekeeper)
• 「安全なノードアップグレード」→ Blue-Green node pool

1.5 Enabling secure cloud development environments

学習ポイント: クラウド開発環境とブートストラップ、AI 支援。

Considerations:

• Cloud development environments — Cloud Workstations（マネージド IDE）、Cloud Shell
• Bootstrapping environments — カスタムイメージ、IDE 拡張、Cloud SDK
• Leveraging AI — Gemini Code Assist（IDE）、Gemini Cloud Assist（運用）、Gemini CLI

典型問題パターン:

• 「組織標準の開発環境」→ Cloud Workstations + カスタムイメージ
• 「IDE 内コード生成・レビュー」→ Gemini Code Assist
• 「Cloud Console での運用支援」→ Gemini Cloud Assist

Section 2: Building and implementing CI/CD pipelines (~25% ★ 最重要)

パイプラインの設計、実装・管理、構成／シークレット管理、サプライチェーンセキュリティの 4 軸。PCDE で最頻出。

2.1 Designing pipelines

学習ポイント: アプリ／インフラ／ML のパイプライン設計、アーティファクト管理、ハイブリッド／マルチクラウド配備、トリガー、承認フロー。

Considerations:

• CI/CD of applications and infrastructure — Terraform CI、terraform plan を PR チェックに
• Artifact management with Artifact Registry — タグ運用（immutable tag）、SBOM、署名
• Deployment to hybrid and multi-cloud environments (e.g., GKE) — Anthos、Cloud Deploy multi-target
• CI/CD pipeline triggers — push / PR / tag / schedule / Pub/Sub event
• Configuring deployment processes (e.g., approval flows) — Cloud Deploy の Manual approval、ロールベース承認

典型問題パターン:

• 「prod デプロイ前に承認」→ Cloud Deploy approval
• 「Terraform の安全なパイプライン」→ plan を PR コメント、apply を merge 後
• 「ML モデル更新パイプライン」→ Vertex AI Pipelines + Cloud Deploy

2.2 Implementing and managing pipelines

学習ポイント: デプロイの監査・追跡、各種デプロイ戦略、トラブルシューティング。

Considerations:

• Auditing and tracking deployments — Artifact Registry のメタデータ、Cloud Build history、Cloud Deploy release/rollout、Cloud Audit Logs (Data Access logs)
• Deployment strategies — canary、blue/green、rolling、traffic splitting、feature flags、ML パイプライン telemetry に基づく成功指標
• Troubleshooting and mitigating deployment issues — Cloud Deploy rollback、Cloud Build retry、Skaffold debug

典型問題パターン:

• 「新バージョンを 5% で評価」→ Cloud Run traffic splitting or Cloud Deploy canary
• 「リリース失敗時に即座に戻す」→ Cloud Deploy rollback / GKE Deployment rollback
• 「フィーチャーフラグ」→ Firebase Remote Config / Cloud Run env var + revision

2.3 Managing pipeline configuration and secrets

学習ポイント: 鍵・シークレット管理、ビルド時 vs ランタイムの注入。

Considerations:

• Key management — Cloud KMS、CMEK、HSM
• Configuration and secret management — Secret Manager、Certificate Manager、Parameter Manager、Workload Identity Federation
• Build vs runtime secret injection — Cloud Build の availableSecrets、Cloud Run の Secret 環境変数 / ボリュームマウント

典型問題パターン:

• 「ビルドログにシークレットが出ない方法」→ Secret Manager + availableSecrets
• 「キーローテーション自動化」→ Secret Manager の version + rotation
• 「External に GCP サービスアカウント不要で認証」→ Workload Identity Federation

2.4 Securing the deployment pipeline

学習ポイント: 脆弱性スキャン、ソフトウェアサプライチェーン保護、環境ベース IAM。

Considerations:

• Artifact Analysis and vulnerability scanning — Artifact Registry の自動スキャン、Container Analysis API
• Software supply chain security — Binary Authorization（GKE / Cloud Run / Anthos）、SLSA framework（Levels 1-4）、Software Delivery Shield
• IAM policies based on environment — dev SA / prod SA を分離、CI 用 SA は最小権限

典型問題パターン:

• 「許可されたイメージのみ deploy」→ Binary Authorization policy
• 「SLSA Level 3 達成」→ provenance attestation + hermetic build
• 「prod だけ強い承認」→ 環境別 IAM + Binary Authorization の attestor

Section 3: Applying site reliability engineering practices (~18%)

SRE の三本柱：信頼性とリリース速度のバランス、サービスライフサイクル管理、インシデント影響の緩和。

3.1 Balancing change, velocity, and reliability of the service

学習ポイント: SLI/SLO/SLA の定義、エラーバジェットの運用、信頼性のコスト。

Considerations:

• Defining SLIs (availability, latency), SLOs, and SLAs — リクエストベース / ウィンドウベース、適切な SLI 選定
• Error budgets — Cloud Service Mesh の SLO/エラーバジェット、消費時のリリース判断
• Opportunity cost of risk and reliability — 99.9% → 99.99% にすると何が増えるか（コスト・複雑性）

典型公式:

• SLA < SLO < SLI 目標値（SLA は契約上の保証、SLO は内部目標、SLI は実測指標）
• エラーバジェット = 1 - SLO（例：SLO 99.9% → バジェット 0.1%/月 ≒ 約 43.2 分）

典型問題パターン:

• 「信頼性を上げてもユーザは気づかない」→ SLO の見直し、過剰投資の回避
• 「バジェット消費が早い」→ リリース凍結 / 信頼性投資にシフト
• 「決済 API の SLI」→ 「2xx/全リクエスト の比率」+ 「P99 レイテンシ < 300ms」

3.2 Managing service lifecycle

学習ポイント: 計画から退役までのライフサイクル、容量計画、オートスケール。

Considerations:

• Service management — planning、deployment、maintenance、retirement
• Capacity planning — quotas、limits、reservations、Dynamic Workload Scheduler（GPU/TPU）
• Autoscaling — MIG、Cloud Run（concurrency / CPU based）、GKE HPA/VPA/CA

典型問題パターン:

• 「年に1度のセールでスパイク」→ Reservations + 事前ウォームアップ
• 「Cloud Run の最適スケール」→ concurrency 設定 + max instances
• 「GPU をバッチで」→ Dynamic Workload Scheduler

3.3 Mitigating incident impact on users

学習ポイント: インシデント発生時の初動：トラフィックの逃がし、容量追加、ロールバック。

Considerations:

• Draining/redirecting traffic — GLB バックエンドの drain、Cloud DNS の重み付き、リージョン切り替え
• Adding capacity — emergency scale-out、reserved capacity 活用
• Rollback strategies — Cloud Deploy rollback、GKE kubectl rollout undo、Cloud Run revision traffic 100→旧版

典型問題パターン:

• 「特定リージョンが不調」→ Cloud DNS で重みを変更 or Multi-cluster Ingress で割り当て変更
• 「直前リリースで遅延悪化」→ traffic を旧 revision に 100% 戻す
• 「インシデント中に追加デバッグ情報」→ ログサンプリング率を一時上げ

Section 4: Implementing observability practices and troubleshooting issues (~25% ★ 最重要)

計装、ログ管理、メトリクス／ダッシュボード／アラート、分散トレース、トラブルシューティングの 5 軸。Section 2 と並ぶ最重要ドメイン。

4.1 Instrumenting and collecting telemetry

学習ポイント: ログ／メトリクス／合成モニタの収集方法とコスト最適化。

Considerations:

• Collecting and importing logs — Ops Agent、OpenTelemetry、Cloud Audit Logs、VPC Flow Logs、Cloud Service Mesh
• Optimizing logs — フィルタリング、サンプリング、Exclusion filters、コスト管理、ソース別考慮
• Collecting metrics — アプリ／プラットフォーム／ネットワーク／Cloud Service Mesh、Google Cloud Managed Service for Prometheus、ハイブリッド/マルチクラウド
• Creating synthetic monitors — アプリ／ワークフローのプロアクティブな確認
• Creating custom metrics — log-based metrics（counter / distribution）、user-defined metrics

典型問題パターン:

• 「Prometheus を運用フリーで」→ Managed Service for Prometheus
• 「特定 INFO ログを除外してコスト削減」→ Log Exclusion filter
• 「ユーザフロー監視」→ Synthetic monitor（URL/script）

4.2 Managing and analyzing logs

学習ポイント: ログ分析、エクスポート、機密情報の扱い、AI 活用。

Considerations:

• Analyzing logs using Logs Explorer and Logging query language — LQL（旧 advanced filter）、severity・resource.type フィルタ
• Exporting and retaining logs — Routing to BigQuery（分析）、Pub/Sub（リアルタイム連携）、Cloud Storage（長期保管）
• Handling sensitive data — log processor で PII/PHI を redact（Sensitive Data Protection 連携）
• Using Gemini Cloud Assist — AI ログ要約・原因推定

典型問題パターン:

• 「ログを長期低コストで保管」→ Cloud Storage Coldline / Archive
• 「BI 分析」→ BigQuery sink
• 「ログから個人情報除外」→ DLP / Sensitive Data Protection の de-identification

4.3 Managing metrics, dashboards, and alerts

学習ポイント: メトリクス分析、ダッシュボード、アラート、サードパーティ連携、AI 活用。

Considerations:

• Metrics Explorer — フィルタ / グルーピング / アライナー / レデューサー
• Dashboards — 作成 / フィルタ / 共有 / playbook（Incident Response 統合）、PromQL クエリ
• Alerting — SLI/SLO ベースアラート、コスト制御アラート、フィルタ条件
• Third-party integration — webhook、PagerDuty、Rootly
• Gemini Cloud Assist — メトリクス解釈支援

典型問題パターン:

• 「Burn rate アラート」→ SLO based alerting policy（fast burn + slow burn）
• 「PromQL でアラート」→ Monitoring の PromQL alerting
• 「PagerDuty 連携」→ Notification channel 設定

4.4 Capturing and analyzing distributed traces

学習ポイント: 分散トレースの計装と分析。

Considerations:

• Tracing frameworks — OpenTelemetry（OTel）、自動計装 + 手動 span
• Trace waterfalls and spans — Cloud Trace UI、ボトルネック特定
• Correlating trace IDs with structured logs — logging.googleapis.com/trace、spanId
• Gemini Cloud Assist — トレース解析支援

典型問題パターン:

• 「マイクロサービス間の遅延原因特定」→ Cloud Trace + OTel
• 「ログとトレース紐付け」→ 構造化ログに trace ID を含める

4.5 Troubleshooting issues

学習ポイント: インフラ／CI/CD／アプリ／可観測性／パフォーマンスの問題切り分け。

Considerations:

• Infrastructure issues — Connectivity Tests、VPC Flow Logs、Firewall Insights
• CI/CD pipeline issues — Cloud Build logs、Cloud Deploy rollout failures
• Application issues — Error Reporting、Cloud Profiler、Logs Explorer
• Observability issues — 欠落メトリクス、ログコスト超過
• Performance and latency issues — Trace、Profiler、Service Mesh metrics

典型問題パターン:

• 「VM から特定 API に届かない」→ Connectivity Tests
• 「アプリの遅い箇所」→ Cloud Profiler (CPU/Heap)
• 「エラー急増」→ Error Reporting で集約 → Trace で詳細

Section 5: Optimizing performance and cost (~12%)

パフォーマンス情報の収集、FinOps プラクティスの実装の 2 軸。

5.1 Collecting performance information in Google Cloud

学習ポイント: アプリ性能監視と Active Assist。

Considerations:

• Application performance monitoring — Cloud Profiler、Cloud Trace、Cloud Monitoring metrics
• Active Assist insights and recommendations — Recommender（IAM、VM サイズ、Idle Resource）

典型問題パターン:

• 「VM が CPU 余ってる」→ Recommender (compute machine type)
• 「Java アプリの GC が遅い」→ Cloud Profiler heap profile

5.2 Implementing FinOps practices for optimizing resource utilization and costs

学習ポイント: 可観測性自体のコスト、Spot VM、ワークロード単位の最適化、CUD/SUD。

Considerations:

• Observability costs — ログ Exclusion、メトリクス取り込み制限、Trace サンプリング
• Spot VMs — 中断許容ワークロード（バッチ、stateless 後段）
• Optimizing resource usage for cost and efficiency — right-sizing、unused リソース削除
• Infrastructure cost planning — Committed Use Discounts (CUD)、Sustained Use Discounts (SUD)、Network Tiers（Premium / Standard）
• Google Cloud recommenders — cost、security、performance、manageability、reliability
• Optimizing individual workload costs — GKE（HPA/VPA/CA、ノードプール混在、Spot pool）、Cloud Run（min instances、CPU always allocated）、Compute Engine（preemptible、custom machine type）

典型問題パターン:

• 「24/7 稼働の安定 VM」→ 3 年 CUD
• 「夜間バッチコスト削減」→ Spot VM + MIG
• 「GKE のコスト分析」→ GKE cost allocation + BigQuery

主要サービス頻出度マトリクス

◎ = 最重要、◯ = 頻出