はじめに

Google Cloud Professional 認定試験全 8 資格を取得しました。

この記事では、実際の受験経験をもとに求められる学習ポイントや試験対策についてざっくりとまとめておきます。

受けようと思っている試験があれば覗いてみてください。

試験の難易度

個人的には、以下のような難易度感と取得順序をおすすめします。

難易度は、難易度低（★☆☆☆☆）から難易度高（★★★★★）の 5 段階で評価しています。

認定試験	難易度	おすすめの取得順序
Professional Cloud Architect	★★☆☆☆（2）	1
Professional Cloud Developer	★★☆☆☆（2）	2
Professional Data Engineer	★★★☆☆（3）	3
Professional Cloud Database Engineer	★★★☆☆（3）	4
Professional Cloud DevOps Engineer	★★★☆☆（3）	5
Professional Cloud Security Engineer	★★★★☆（4）	6
Professional Cloud Network Engineer	★★★★★（5）	7
Professional Machine Learning Engineer	★★★★★（5）	8

Professional Cloud Architect（PCA）

Google Cloud 上でのエンタープライズアーキテクチャの設計と運用を行う能力を証明する資格です。

ケーススタディが中心になっていて、ビジネス要件を満たす Google Cloud ソリューションを適切に選択する能力が問われます。

PCA では Google Cloud ソリューションを幅広く取り上げており、他の Professional 認定試験を包括した内容になっています。Professional 認定試験の中では 取得しやすい部類 に入るため、Google Cloud を初めて学ぶ人や認定試験の入門としては最適です。

問われる内容

組織管理と IAM・ポリシ設計
- Organization Policy、IAM ロール設計、サービスアカウントと Workload Identity、監査設計（Cloud Audit Logs）
ネットワーク設計と接続性
- VPC、サブネット、Cloud NAT、Cloud DNS、負荷分散（L4、L7、Global、Regional、Internal、External）、Cloud VPN、Cloud Interconnect、VPC Peering
コンピュートとデプロイ戦略
- Compute Engine、GKE、Cloud Run、Cloud Functions、App Engine、デプロイ方式（Blue/Green、Canary）、アーティファクト管理（Artifact Registry）
データ層の選定と移行
- Cloud Storage、Cloud SQL、Spanner、Bigtable、Firestore、BigQuery の使い分け、バックアップと PITR、Database Migration Service（DMS）
Observability と運用設計
- Cloud Monitoring、Cloud Logging、Alerting、インシデント運用、Log Routing と自動処理（Pub/Sub 連携）
セキュリティと統制
- IAM ロール（最小権限の原則）、Cloud KMS と CMEK、Cloud Armor、Binary Authorization、Cloud DLP、VPC Service Controls、Secret 管理
コスト最適化と可用性
- Autoscaling、Committed Use、リソース適正化（Recommender）、高可用性構成、マルチリージョンや DR の設計

求められる知識

可用性・一貫性・レイテンシ・コスト・運用負荷のトレードオフの理解
Organization Policy、最小権限の IAM 設計、サービスアカウントの運用、監査ログの活用
VPC とルーティング、L4 と L7 の使い分け、Global と Regional の選択、VPN と Interconnect の選択基準
Cloud SQL / Spanner / Bigtable / Firestore / BigQuery の違い、DB バックアップと PITR、代表的な移行パターン
GCE / GKE / Cloud Run / Functions / App Engine の選択軸、Blue/Green デプロイメントや Canary リリース、コンテナセキュリティ（Binary Authorization）
メトリクスとログの設計、アラートとオンコール（Cloud Monitoring / Alert Policy）運用、ログエクスポートと自動処理、IaC と CI/CD（Cloud Build / Terraform 等）の基本

抑えておくべきポイント

要件ドリブンで設計を決める

PCA はケーススタディが中心になる。ビジネス要件を読み解いた上で、何を最優先にするか（可用性・レイテンシ・コスト）を決定して最適なソリューションを選択する。

最小権限と VPC 境界での保護

IAM は常に最小権限の原則（PoLP）に基づいて設計する。階層型アクセス制御を理解し、組織ポリシで一貫したポリシを適用、IAM ロールでリソース単位で権限を設定。

ネットワーク経路は Cloud Armor やファイアウォールで制御し、暗号化や PII 要件には CMEK や Cloud DLP を活用。

実行基盤の選定

ステート管理やスケール要件に合わせて GCE、GKE、Cloud Run、Functions、App Engine を選択する。運用負荷を下げたいならマネージドやサーバレスソリューションが優先になる。

データベースのユースケース

トランザクションは Cloud SQL、グローバル強整合は Spanner、高スループットなキーアクセスは Bigtable。

DevOps と Observability

CI/CD と IaC 関連では Cloud Build / Cloud Deploy、Observability では Cloud Monitoring / Logging / Trace / Profiler の Alert Policy や Error Reporting を理解しておく。「最小限の運用コスト」といった要件では、手動作業より Google Cloud のマネージドサービスが推奨される。

Professional Cloud Developer（PCD）

Google Cloud 上でのクラウドネイティブアプリケーション開発を行う能力を証明する資格です。

Cloud Build 等を使用した CI/CD、GKE やその他コンピューティング系プロダクトにフォーカスが当たり、多くのエンジニアにとって馴染みのあるトピックが豊富に出題されます。

PCA ではビジネスの要件から最適なソリューションを選択する能力が問われますが、PCD ではより技術的な内容に踏み込んでいます。PCA よりも具体的な技術を扱いますが、Professional 認定試験の中では 比較的取得しやすい部類 に入るため、PCA と合わせて最初に受験するのをお勧めします。

問われる内容

実行基盤の選定と設計
- Cloud Run、Cloud Functions、GKE、App Engine、Compute Engine、ステートレス化とスケーリングの使い分け
API 設計と公開
- Cloud Endpoints、Apigee、認証と認可、ルーティング、CORS、レート制限
アイデンティティとシークレット管理
- IAM、サービスアカウント、Workload Identity、Secret Manager
CI/CD
- Cloud Build、Artifact Registry、ビルド構成とプライベートプール、デプロイ戦略（Blue/Green、Canary、Rolling）
Observability と運用
- Cloud Logging、Cloud Monitoring、Cloud Trace、Cloud Profiler、アラートとインシデント運用
メッセージングとデータアクセス
- Pub/Sub、Cloud Storage、Cloud SQL、Firestore、Bigtable、Serverless VPC Access と接続設計

求められる知識

サービスアカウントの付与、ロールの最小化、キーファイルではなくアタッチ運用、GKE は Workload Identity を優先
バージョニング、契約の互換性、429 と 5xx への指数バックオフ、冪等リトライ、レート制限とクォータ
Blue/Green、Canary、Rolling の違いとロールバック方針、トラフィック分割、ヘルスチェックと段階解放
Cloud Build のステップ設計、Artifact Registry の脆弱性スキャン、署名と Binary Authorization による未署名イメージの拒否
Secret Manager で保管、バージョン管理とローテーション、ランタイム注入、環境別設定の扱い
構造化ログ出力、指標とアラートの設計、分散トレースでのボトルネック特定、プロファイルでの最適化
Pub/Sub の Pull と Push、デッドレターキュー、順序と重複の前提、バックプレッシャと再試行ポリシ

抑えておくべきポイント

マネージドサービスとステートレス設計を基本に考える

Google Cloud の開発では、Cloud Run や Cloud Functions を代表とするマネージドな実行環境を使い、自前でインフラを抱えず、スケーリングや障害対応を Google に任せる設計が推奨される。アプリケーションはステートレスであるべきで、セッション情報や一時データは Cloud Storage や Firestore、Memorystore などの外部に逃がす設計が問われる。設問では「アプリの負荷に応じたスケーリング」「インフラ運用を最小化したい」といった文脈から、適切な基盤を選べるかがポイント。

サービス間認証は「キー認証」より「ID 認証」を使う

長期保存されるサービスアカウントキーは基本的に非推奨な方法。Workload Identity（GKE）や Cloud Run の組み込み認証を活用し、IAM 権限だけで認証を完結させることがベストプラクティスとなる。試験では「認証情報を安全に管理したい」「キーファイルを配布したくない」といった要件から、Secret Manager + サービスアカウントの IAM 組み合わせを正しく選べるかが問われる。

段階的なリリース戦略とロールバック経路を確保する

Cloud Run や GKE、App Engine などは複数のリビジョンを同時に持てる環境を活かして、Blue/Green や Canary デプロイが可能。試験では「ユーザ影響を抑えて安全に切り替えるには？」「異常時にすぐ戻すには？」という設問に対し、トラフィック分割やタグ付きリビジョンを活用した設計を選択できるかが求められる。

非同期処理と冪等性でシステムを壊れにくくする

Pub/Sub や Eventarc を使った非同期処理では、一時的な障害・遅延・重複を前提とした設計が重要になる。指数バックオフ、冪等性の担保（例：処理済み ID の記録、リトライ前提のトランザクション設計）を行い、一回だけ成功すればよい処理としてモデル化する。問題文に「同じイベントが複数届く可能性がある」とあれば、これにどう備えるかが問われる。

Observability とセキュリティは後付けではなく最初から考慮しておく

開発者は、Cloud Logging や Monitoring だけでなく、Trace や Profiler を使ったパフォーマンス分析まで含めた観測できるコードを実装することが求められる。

CI/CD パイプライン内で Artifact Registry の脆弱性スキャンや署名（Attestation）を行い、Binary Authorization によって未署名のイメージはデプロイを拒否する仕組みを設ける。試験では「信頼できるアーティファクトだけを本番に流すには？」といったような設問が出題される。

Professional Data Engineer（PDE）

Google Cloud でのデータ処理システムの設計、構築、運用を行う能力を証明する資格です。

BigQuery を中心に、データの収集、変換、可視化、機械学習モデルの構築といったデータエンジニアリングの基本的な概念と Google Cloud のサービスに関する知識が問われます。昨今では ML モデルに関する話題からデータの利活用を促進するデータエンジニアリング領域に重心がシフトしているみたいです。

この辺りから専門的な内容が多くなり、PDE は PCA や PCD と比較して 中程度の難易度 に位置します。Google Cloud を使ってデータエンジニアリングに従事する人であれば、実践的なナレッジの習得にも役立つ資格だと思います。

問われる内容

データ取り込み設計
- ソース特性（頻度、順序、重複、スキーマ変化）に応じた取り込み方式の選定
- Datastream（CDC、Replication）、BigQuery External Table、FastExport（Teradata → BigQuery）、Cloud Storage 経由取り込み
ストレージ選定とレイアウト
- 目的・SLA・コストに適した保管先と物理設計（分割、並び、履歴）の判断
- BigQuery（Partitioning、Clustering、Time Travel、Materialized View）、BigLake、Omni、Bigtable（スキーマ、Garbage Collection）、Cloud Storage
データ処理（バッチ, ストリーム）
- イベントの時刻と取り込みの時刻の区別、集計枠（Tumbling Window、Sliding Window、Hopping Window、Session Window）と遅延到着の扱い、Watermark と Reshuffle の方針を設計
- Dataflow（関数群：PCollection、PTransform、ParDo・DoFn）、Dataproc（Spark、Hadoop、Serverless）、Dataprep、Data Fusion（GUI 変換・統合、Wrangler）
データ品質・メタデータ・運用
- 品質基準の自動検証、変更影響の追跡、依存関係・再試行・スケジュール管理の設計
- Dataform（ELT 処理、Assertion）、Dataplex（Metadata、Data Lineage、Data Quality Rules）、Cloud Composer（Airflow、DAG）
セキュリティ・ガバナンスと共有
- 最小権限、鍵管理、匿名化を前提に、安全で追跡可能なデータ共有の設計
- CMEK、Cloud DLP（検出、マスキング）、Analytics Hub

求められる知識

ソース特性に基づく選択、CDC とバッチの使い分け、冪等性、重複排除、スキーマ進化への対応
BigQuery の Partitioning、Clustering、Time Travel、Materialized Views、Bigtable の Row Key 設計と Garbage Collection、BigLake 連携の理解
イベント発生時刻と取り込み時刻の区別、Windowing と Watermark の設計、遅延到着と再計算の方針
スキャン削減の設計、事前集計と再利用の戦略、同時実行とリソース管理、コスト見積もりと監視
Data Quality Rules と Assertions の自動検証、隔離と是正の手順、Data Lineage による影響範囲追跡、DAG に基づく依存管理と再試行、冪等再実行
最小権限、CMEK による鍵管理、Cloud DLP による検出とマスキング、Analytics Hub を用いた最小開示と監査可能性

抑えておくべきポイント

鮮度・正確性・コストの 3 つの観点

どのくらい新しいデータを、どのくらい正確に、どのくらいの費用で扱うかを最初に決めて、以降の設計をその方針に揃える。

アクセスパターン起点のデータ設計

どの軸で絞込・結合するのか（時間・地域・顧客・イベント）を先に決めて、Schema・Partitioning、Clustering・集約単位をその利用実態に合わせる。

時間の扱いでバッチとストリームを切り分ける

イベントが発生したタイミングとそれを処理するタイミングを分けて考え、集計の枠と遅れて来るデータの扱いを決定してどの時点の数値を正とするかを定める。

データ品質とリネージを運用の中心に置く

一意性や欠損等のチェックを自動化し、問題が出たら止めて、原因と影響を追跡して直す流れを用意する。

Secure by Design という考え方

権限は最小限にし、暗号化や匿名化を前提にする。共有はコピーではなく参照で行い、必要な人に必要な範囲だけ見せる。

Professional Cloud Database Engineer（PCDE）

Google Cloud のデータベースソリューションの設計、構成、運用を行う能力を証明する資格です。

この試験では、Google Cloud の全てのデータベースソリューションが登場します。最近では Spanner や AlloyDB に関する内容が増えているイメージです。

データベースの特徴（NoSQL、RDBMS、Columnar）を理解していることが前提となっており、ユースケースや要件に応じた構成・配置方法について問われます。データベースの移行に関する問題も登場するため、Google Cloud 以外のデータベースサービス（Oracle、SQL Server、Amazon Aurora）についても軽く押さえておいたほうが良いと思います。

問題範囲は Google Cloud のデータベースソリューションに集中しており、抑えておくべきポイントも局所化しているので、内容としては 中程度の難易度 に位置します。

PCDE の日本語版試験は無いので、最低限英語の読解力は必要になります。

問われる内容

高可用性（HA）と災害復旧（DR）の設計
- 同一リージョン内のマルチゾーン HA
- フェイルオーバとフェイルバック
- クロスリージョン Read Replica による DR、バックアップと PITR（Point In Time Recovery）の運用間隔と保持期間
接続方式とセキュリティ
- Private IP 接続（Service Networking、VPC Peering）
- Public IP と Authorized Networks
- Cloud SQL Auth Proxy
- SSL/TLS による経路暗号化
- IAM とロールの設計
- CMEK の適用
マイグレーションとレプリケーション
- Database Migration Service（Homogeneous / Heterogeneous）
- 外部プライマリからの継続レプリケーション、Import / Export、レプリケーション遅延の理解とリード分離
モニタリングとメンテナンス運用
- Cloud Monitoring 指標（CPU、メモリ、ストレージ、接続数、遅延）
- Query Insights によるクエリ分析
- メンテナンスウィンドウ
- キャパシティオートスケーリング
- マシンタイプ変更・ストレージ拡張周りとダウンタイム
プロダクト選定
- Cloud SQL：MySQL / PostgreSQL / SQL Server
- Spanner：水平スケールと強整合性
- Bigtable：高スループット NoSQL
- Firestore：ドキュメント指向 / ネイティブアプリケーション / Datastore モード
- Bare Metal Solution for Oracle の位置づけ

求められる知識

データベース要件を設計に落とし込み、可用性（HA）/ 復旧性（DR）/ ACID / パフォーマンス / コスト / セキュリティを満たす運用ができること
マルチゾーン HA、フェイルオーバ、フェイルバック、クロスリージョン Read Replica、バックアップと PITR、RPO と RTO
Private IP と Public IP の選択、Authorized Networks、Cloud SQL Auth Proxy、SSL/TLS、IAM の最小権限、CMEK
Database Migration Service（DMS）、外部プライマリからの継続複製、Import と Export、レプリケーションラグ、読み取り分離、一貫性モデル（強整合、結果整合）
主要メトリクス監視、Query Insights の活用、インデックスと実行計画、ストレージとマシンタイプの調整、コスト最適化
Cloud SQL のエディション差と制約、Spanner のスキーマ設計とホットスポット回避、Bigtable の Row Key 戦略と Garbage Collection、Firestore のモード選択

抑えておくべきポイント

RPO と RTO を決める

まず、どれだけ失ってよいか（RPO）やどれだけで復旧したいか（RTO）を考える。設問に「数分以内の復旧」や「ゼロダウンタイム」のようなキーワードがあれば、同一リージョン内のマルチゾーン HA やフェイルオーバ、クロスリージョンレプリカによる DR を優先する。誤操作や時点復元のニーズが書かれていれば、バックアップと PITR を組み合わせる選択が妥当策となる。

RPO/RTO をベースに考えることで、HA、DR、バックアップ、レプリカ戦略のどれが必要になるのかを判断しやすくなる。

接続面を最小にする

接続方式は非公開を基本、公開は例外とする。Private IP 経由で接続し、認証や経路暗号化は Cloud SQL Auth Proxy に任せる構成が原則的によりセキュアな方法になっている。その上で最小権限（IAM）と CMEK（顧客管理鍵）を適用できるかを確認します。

Public IP と Authorized Networks を使うのは要件に明記があるときだけ、という優先度で選択肢を比較してみる。

リード負荷の分散

読み取り系の負荷は Read Replica に逃がすという設計意図を読み取る。Read Replica は非同期レプリケーションでラグがあるため、最新性が厳密に必要な参照や書き込みを伴う処理には不向き。

設問で「ダッシュボード」「分析集計」「レポート」のような読み取り中心の用途が示されていればレプリカ活用が有効で、逆に「強い整合性」「最新の残高が必須」ならプライマリ参照を検討する。

垂直スケールと水平スケール

スケーリングの方向を見極める。単一リージョンのトランザクション処理でスケールアップ中心なら Cloud SQL、グローバル分散や強整合と水平スケールが必要なら Spanner、高スループットなキーアクセスが主目的なら Bigtable を選ぶイメージ。

設問中の「グローバルスケール」「強整合」「TB/PB 規模のスループット」「既存の MySQL / PostgreSQL 互換」といったワードがヒントになる。

パフォーマンス最適化とメンテナンス

前提、クエリパフォーマンスの調査は Query Insights（スロークエリの特定や実行計画の確認）、メンテナンスウィンドウ（実施時間の制御）と延期設定について理解しておく。
リソースの変更はマシンタイプやディスク等、何を変更するかによって変わるためダウンタイム（再起動の有無）や影響範囲がどこまであるのかを理解しておく。

データベースのマイグレーションについて「ダウンタイム最小」「できるだけ少ない作業量で」が強調されていれば、Database Migration Service（DMS）がまず第一選択となり、停止が許容できて、かつ小規模なら Export（Dump）/ Import（Restore）での移行を検討する。

Professional Cloud DevOps Engineer（PCDOE）

Google Cloud におけるアプリケーションの継続的運用と信頼性設計を行う能力を証明する資格です。

アプリケーションの開発と運用サイクルを効率化するための Google Cloud のサービスやツールのプラクティスに関する知識が問われます。Kubernetes（GKE）を中心に、CI/CD やリリース戦略、IaC、監視、ロギングといった DevOps の基本的な概念と SRE（SLI/SLO）の知識が求められます。

SRE や Platform Engineering に従事している人にとっては比較的馴染みのある内容になっていますが、一から学ぶ人にとってはノウハウや概念の習得から必要になるため 中〜高程度の難易度 に位置すると思います。

言ってしまえば PCDOE は PCD をより突き詰めた試験です。

問われる内容

サービス信頼性設計（SRE 原則）
- SLI、SLO、Error Budget、トイル削減、ポストモーテム、インシデント対応、Root Cause Analysis（RCA）
Observability とメトリクス設計
- Cloud Monitoring、Cloud Logging、Cloud Trace、Cloud Profiler、OpenTelemetry、Scoping Project、アラート・ダッシュボード設計
継続的デリバリと変更管理
- Cloud Build、Cloud Deploy、Artifact Registry、Blue/Green / Canary / Rolling デプロイ、リリース戦略とロールバック
CI/CD パイプラインのセキュリティ
- Binary Authorization、Attestation、脆弱性スキャン、Secret 管理、シフトレフト（Shift Left）
コンテナ運用とスケーリング
- GKE の HPA（Horizontal Pod Autoscaler）/ VPA（Vertical Pod Autoscaler）/ Cluster Autoscaler、Workload Identity、Network Policy、Spot VM の活用
コストとリソース管理
- 確約利用割引（CUD）、Spot VM、Recommender、SLA 設計、IaC

求められる知識

SLI / SLO / Error Budget の意味と役割、可用性目標に対する変更・障害・トイルのバランス
IC（Incident Commander）/ OL（Operations Lead）/ CL（Communications Lead）の役割、Blameless ポストモーテム、MTTD / MTTR の定義
Cloud Monitoring / Logging, メトリクスの種類（GAUGE / DELTA / CUMULATIVE）、カスタムメトリクス、ログベースメトリクス、アラート設計
Cloud Build のステップ構成とトリガ、Artifact Registry の脆弱性スキャン、署名と Binary Authorization、シークレット管理のベストプラクティス
Blue/Green、Canary、Rolling デプロイの違い、Cloud Deploy による段階的リリースと自動ロールバック設計
GKE のスケーリング技術（HPA、VPA、Cluster Autoscaler）、Spot VM、Cloud Recommender によるリソース調整、確約利用割引（CUD）の活用

抑えておくべきポイント

SLO を軸にした判断がすべての起点になる

「どれが SLO を守る構成か」「SLO を侵害した場合どうすべきか」といった SRE に関連する内容が登場する。SLO の定義を起点に、変更速度・安定性・自動化のバランスを取る設計が求められる。Error Budget の使い方（消費しすぎ / しなさすぎ）も含めて、SRE 思考の判断基準を持っておくことが重要になる。

監視は改善まで考えて設計する

単にメトリクスを可視化するのではなく、Alerting、Tracing、Profiling、Logging、エラー集計を活用して改善につながる観測を行うことが求められる。SLI はユーザ視点で定義されているか、アラートはノイズになっていないか、など見るべき情報をどう絞るかが試験でも問われる。

デプロイは段階的、かつ即座に戻せる設計にする

Blue/Green, Canary デプロイを使って影響範囲を限定し、即座にロールバック可能な構成を選ぶのが基本方針になる。Cloud Deploy や GKE、Cloud Run のリビジョン管理、トラフィック分割機能を活用する設問が出題され、変更の安全性をどう担保するかが問われる。

トイルは検知し、コードで排除する

「人手の介入が必要な繰り返し作業」はトイル（Toil）にあたる。（定義は細かいので以下を読んでください）

Cloud Scheduler による自動実行、Cloud Functions による通知処理、Terraform や Deployment Manager による構成管理など、トイルに該当する運用タスクは自動化すべき。試験では「週に 1 回手動で対応している」といったような明らかに人の手が継続的に必要、かつそこから得られる利益が薄い場合、自動化を検討する。（ただし、ひっかけ問題的な感じで、稀に人が介入しなければならないものもあるので注意すること！）

インシデントは人ではなく組織で対応する文化を理解する

インシデント時は、役割分担（IC / OL / CL）と組織対応の原則に基づいた構成が問われる。ポストモーテムは「責任追及ではなく学びを残す」文化がベースであり、記録の共有まで含めた設計が求められる。試験では「誰が何をすべきか」「どんな手順で振り返るか」が問われるため、SRE 本の対応原則を理解しておくと良い。

Professional Cloud Security Engineer（PCSE）

Google Cloud でのセキュアなインフラの設計、構築、保護を行う能力を証明する資格です。

サービス間認証、ネットワークセキュリティ、組織や IAM の管理、データ暗号化等、業務上様々なロールのあらゆるセキュリティ関連の話題を網羅的に扱います。問題の傾向として、とにかく似たような回答が羅列されているため、何が課題で何を解決するプラクティスを講じるのかを適切に判断する必要があり、セキュリティプロダクトの深い理解が求められます。

普段からセキュリティソリューションに触れていないとイメージすら持ちずらいものも登場するため、難易度は高め で、Google Cloud のセキュリティに関する専門的な知識が要されます。

通常、Professional 認定試験は 50 問ですが、PCSE のみ 40 問と少なめです。各セクションで一定割合 Pass しなければならないことを考えると 1 問あたりの重みが大きくなります。

問われる内容

アイデンティティ管理とアクセス管理
- IAM（ロール設計 / 条件付き IAM）、組織ポリシ、Context-Aware Access、IAP、SSO、OIDC、Workforce Identity
データ保護と鍵管理
- Cloud KMS、Cloud HSM、Cloud EKM、エンベロープ暗号（DEK / KEK）、Key Access Justifications（KAJ）
ネットワーク境界の強化
- VPC Service Controls（Service Perimeter / Access Context Manager / Location Policy）、Private Google Access、Private Service Access
ワークロード保護
- Cloud Armor、Cloud IDS、Binary Authorization、GKE（Workload Identity / Network Policy）
監査と可視化
- Cloud Audit Logs（Admin / Data Access / System / Policy Denied）、Security Command Center（SCC）、Cloud Security Posture Management（CSPM）
コンプライアンス / データ分類
- Cloud DLP、レイテンション、キー・データの位置制御、PII 保護
運用と自動化
- 階層型アクセス制御、最小権限の原則（PoLP）、インシデント対応とエスカレーションプラクティス、Logging、Alerting

求められる知識

ゼロトラストの分解思考
- ユーザ属性・端末状態・ネットワーク位置・アプリケーション・データ分類を条件として組み合わせて必要最小のアクセスを許可する
鍵とデータのライフサイクル
- 生成 → 使用 → ローテーション → 失効 → 破棄を運用可能性と可監査性込みで設計
- CMEK を基準に、要件次第で HSM / EKM
境界の多層化
- アイデンティティ境界（IAM / Context）、サービス境界（VPC Service Controls）、ネットワーク境界（Private Access）、アプリ境界（IAP / Cloud Armor）を重ねて漏洩経路を塞ぐ
監査可能性と是正のループ
- Audit Logs と SCC を中核に、検知 → 調査 → 是正を自動化
- 通知・チケット化・ポリシ補強
最小の解を選ぶ姿勢
- 要件が「暗号化」なのか「アクセス抑制」なのかを見極め、過剰設計を避けつつ実効性の高い最短構成を提案する

抑えておくべきポイント

「何を守るか」を分類して制御面に割り振る

データ、アイデンティティ、ワークロード、経路といった守る対象を切り分け、データなら暗号化と境界、アクセスなら IAM、経路なら Private Access や VPC Service Control、ワークロードなら Binary Authorization や Cloud Armor といったように、要件から必要なプラクティスを選定する。

鍵管理は CMEK を基準に要件次第で HSM / EKM を利用

とにかくたくさんの鍵管理オプションが出てくる。

デフォルトは GMEK、制御要件があれば CMEK というのが基準になる。
FIPS（Federal Information Processing Standards）やハードウェア境界が必要なら Cloud HSM、鍵をクラウド外に置きたい（内部者リスクを含めて遮断したい）なら Cloud EKM + KAJ 等、より強い制御が必要になる。

エンベロープ暗号では DEK を KEK（CMEK / EKM）で保護し、KEK の可用・不可用がデータ可用性に直結する点まで理解しておく。

適切な Audit Logs の収集

Audit Logs による監査は次に分類されるので、どのような事象に対して何のログを調査すべきかを理解しておく。

ログタイプ	説明	デフォルト有効
Admin Activity Log	リソースの構成変更や、設定の変更等を行う API コールのログを記録	有効
Data Access Log	リソースの読み取りや変更等、ユーザデータへのアクセスを記録	無効（明示的な設定が必要）
System Event Log	Google または Google Cloud インフラにより生成されたシステム関連イベントを記録	有効
Policy Denied Log	ポリシ（IAM、組織ポリシ等）により拒否されたリクエストを記録	有効

これらを SCC に集約して脆弱性・脅威検出（ETD / KTD / VTD）と合わせて、検知 → 是正の運用設計に関する内容も問われる。

最小権限の原則

IAM ロールの付与は必ず最小権限の原則（PoLP）に設定する。

基本ロールではなく、事前定義ロールやカスタムロールを中心に、条件付き IAM（IP アドレス、時間、リソース属性）ロールの使用をまず検討する。

階層型アクセス制御

Google Cloud では階層型アクセス制御によって、組織、フォルダ、プロジェクト、リソースの各レベルで IAM ポリシを設定できる。許可ポリシが子リソースに対してどのように継承・伝搬されるのかを理解した上で、適切なレベルで IAM ポリシを設定する。

親レベルで一括制御すると管理負担は軽減されるが、特定の要件では柔軟性に欠ける。子リソースで個別に設定すると柔軟性は増すが、統一化されたポリシ運用が難しくなる。

Professional Cloud Network Engineer（PCNE）

Google Cloud のネットワークアーキテクチャの設計、実装、管理を行う能力を証明する資格です。

TCP/IP やネットワークの基本的な知識が必須で、インフラ・セキュリティ・VPC 構成にある程度精通している人向けの試験です。

試験自体が他の Professional 認定資格と比較して 難しい部類 に入ります。覚えることも多いため、特にネットワークが得意でない場合は、他の試験の 1.5〜2 倍程度の学習時間を見積もっておいた方が良いでしょう。

ネットワークの構築（特に BGP や VPN といった広域ネットワークを経由する経路制御）について基本的な理解がある人は、Google Cloud 特有のプラクティスについて追加でキャッチアップしておけば十分対応できると思います。

問われる内容

VPC 設計とハブアンドスポーク構成
- 組織内プロジェクト間の通信構成における中心的な考え方
オンプレミス接続構成
- Cloud Interconnect、Cloud VPN、Cloud Router、VPC Peering、Cloud DNS、Cloud NAT
- BGP Router、BGP Peering、DNS Resolver、DNS Forwarder、Netfilter
Private アクセス構成の使い分け
- Private Google Access、Private Service Connect、Private Service Access
ネットワークレベルのセキュリティ構成
- Firewall、Firewall Logs、VPC Service Controls、VPC Flow Logs、IAM
ルーティング制御・経路構築
- Static Routing、Dynamic Routing、Policy-based Routing、Route-based Routing
ロードバランサの構成選定と使い分け
- L4 / L7、Global / Regional、Internal / External
階層型制御に基づくリソース管理
- 組織レベル制御、フォルダレベル制御、プロジェクトレベル制御、ネットワークスコープ（サブネット単位）制御

求められる知識

Cloud Router、BGP、MED、Route Priority の仕組みと制御方法
トラフィックの流れ（入口・出口）に応じたルーティングの最適化
VPC 間接続または VPC とオンプレミス DC 間接続における制約やスケーラビリティの理解
IP アドレス設計や RFC1918（プライベート IP アドレスレンジ）の理解
ログベースのトラブルシューティング
各種ロードバランサの動作と用途の判断

抑えておくべきポイント

ハブアンドスポーク構成 👈 基本的に全部コレ

Google Cloud のネットワーク構成では、ハブアンドスポーク型アーキテクチャというのが設計の礎となる考え方。

ネットワークリソースやセキュリティ制御を中央集権で管理しつつ、複数のプロジェクト（スポーク）を紐付ける形で構成する。Shared VPC を使ったホスト・サービスプロジェクトの分離設計は頻出で、どの構成が適切かを問う内容が出題される。

トラフィックの方向ごとのルーティング制御の理解

例えば、トラフィックが VPC からオンプレミス DC に向かう場合（出口）と、オンプレミス DC から VPC に向かう場合（入口）で、制御方法が異なる。

Cloud Router の Route Priority や Google 側がアドバタイズする MED 値の設定方法を理解しておく。設問では「どの方向に向かうトラフィックか」を読み取ったうえで適切な制御手段を選ぶ必要がある。

マネージドサービスへのプライベートアクセスパターンの区別

Private Google Access、Private Service Connect、Private Service Access は似ていますが、これらは用途や対象サービスが異なるので混同しなようにする。

例えば、Private Google Access は VM から Cloud Storage や BigQuery のような Public API にアクセスする用途、Private Service Connect は Internal LB を経由したプライベート通信等、試験では違いを問われるため明確に区別しておく。

IP アドレスレンジや ASN の理解

ここは知っているか否かの領域になる。

特定の機能やサービスで使われる IP レンジや ASN（Autonomous System Number）を把握しておく。

【特に覚えておくと良いもの】

199.36.153.4/30（restricted.googleapis.com）：特定の Google API にアクセスする際に使用される IP アドレスレンジ
199.36.153.8/30（private.googleapis.com）：限定公開の Google アクセスに使用される IP アドレスレンジ
35.199.192.0/19： Cloud DNS がフォワーディング（Private Forwarding Zone）のために使用する IP アドレスレンジ
ASN 15169：Google のパブリックで、主に Google のサービスに直接接続するために使用される
ASN 16550：Partner Interconnect を使用する場合

ロードバランサの種類と選定基準の把握

Google Cloud のロードバランサは多岐にわたる。プロトコル（L4 / L7）、スコープ（Global / Regional）、用途（Internal / Global）によって使い分けが求められる。

設問ではクライアントからのコネクションをどの段階で終端するのか、どのレイヤでの負荷分散が必要なのかを見極める問題が多い。どのタイプの LB がどのユースケースに適しているかを判断する必要がある。

Professional Machine Learning Engineer（PMLE）

Google Cloud での機械学習モデルの設計、構築、運用を行う能力を証明する資格です。

前提として機械学習の基礎知識（モデルの構築・トレーニング・最適化）が必要となりますが、モデルをプロダクトに乗せる上での実装・評価・デプロイ・運用・チューニングセキュリティまで含めた内容が盛り込まれています。

機械学習の実務経験がある方であれば基礎部分の理解はしやすいですが、Vertex AI や MLOps、Leakage 等、Google Cloud 特有の運用観点もキャッチアップする必要があります。

最近では Gemma や Imagen に関する内容が追加されるなど、試験範囲の幅が広がっている印象です。

他の試験とは違った観点での難しさがあり、高レベルな英語の読解力も必要になります。

Google Cloud 認定資格では 最難関 と言われています。

問われる内容

機械学習タスクの分類分類 / 回帰 / 教師あり・なし学習）
正則化、評価指標、前処理、特徴量エンジニアリング
モデル学習・チューニング（XGBoost / TensorFlow / scikit-learn 等）
Vertex AI 全般（Training、Prediction、Pipelines、Feature Store、Model Monitoring）
モデル解釈と説明可能性（Explainable AI）
データ分布変化（Drift / Skew / Leakage）
AutoML の使いどころと制限
再現性（Reproducibility）と Lineage
データ前処理パイプライン（TFX / Dataflow / Transform）
Google Cloud の AI ソリューションと API（Vision / Translation / NLP / Speech）

求められる知識

分類 / 回帰タスクの違い、使用する評価指標（Precision / Recall / F1 / RMSE）
学習パイプラインの構成（ExampleGen → Transform → Trainer → Evaluator → Pusher）
モデル監視（Drift・Skew 検出、Vertex AI Model Monitoring の使い方）
説明可能性（Shapley、Integrated Gradients、Example-based Explanations）
分類・回帰・クラスタリング、表形式データへのモデル適用（AutoML Tabular）
モデルデプロイ戦略（Traffic Split による Canary リリース等）
データフォーマット（TFRecord, CSV）、ストレージ（BigQuery / GCS）
再現性の確保（パイプライン / Metadata / Model Registry / Feature Store）

抑えておくべきポイント

分類と回帰の問題定義と評価指標

評価指標として Precision、Recall、F1、RMSE）は頻出されるイメージ。

誤検知を避けたいのか（Precision 重視）、取り逃しを避けたいのか（Recall 重視）、両者のバランスを見たいのか（F1）、あるいは数値誤差の大きさを評価したいのか（RMSE）。
クラス不均衡なら Accuracy に頼らず、適切な指標を主指標・副指標としてセットで選定。

設問文から分類問題なのか回帰問題なのか、指標選択の妥当性を理解する。

TensorFlow / PyTorch / scikit-learn それぞれの特性と用途を整理

実験初期の表形式データや軽量なベースラインは scikit-learn、研究寄りで迅速な試作や独自モデルは PyTorch、Enterprise のパイプライン統合や大規模学習・推論、Vertex 連携の容易さは TensorFlow が優位というイメージ。

既存資産、推論形態、デプロイ先といった問題文の背景に合わせ、なぜその選択なのかを理解する。

Vertex AI の主要コンポーネント理解

Training（学習）→ Pipelines（再現可能な実行）→ Model Registry（バージョン管理）→ Prediction / Endpoints（提供）→ Model Monitoring（監視）→ Explainable AI（説明）の流れで、設計と運用が循環するイメージを持つ。

個々の機能名を暗記するより、「どのフェーズで何を担保しているか」を因果で理解する。

モデルの劣化要因を探索する方法

Drift / Skew / Leakage は運用時にモデル劣化の要因となる。

Drift は時間経過での分布変化、Skew は学習・本番の分布差、Leakage は本来使えない情報の混入。
検知は監視（分布比較・重要度変化）、緩和はデータガバナンス（特徴量管理・スキーマ検証）、再学習戦略（スケジュール or 閾値値発火）で戦略を立てる。

設問から「どこで起き、どう気づき、どう直すか」を理解する。

AutoML とカスタム学習のトレードオフ

AutoML は手軽さ優先、カスタムトレーニングは制御性優先で使い分ける。

迅速な PoC や標準タスクは AutoML、特殊前処理・独自損失・大規模分散や厳密な最適化が要るならカスタム（TensorFlow / Torch）といったイメージ。

短期価値か長期拡張性かを判断材料にすると良い。

MLOps 技術（TFX / Dataflow / RunInference）はエンタープライズ実装を意識

前処理・学習・評価・提供をコード化し直列化するのが TFX、スケーラブル処理は Dataflow、推論のデータパス近接化は RunInference。

MLOps では人の介入を極力避けて運用を自動化することを主な目的なので、人手を介さずに品質と速度を両立する方法、運用のボトルネックをどの技術で解消するかを考える。

Vertex AI コンソールに触れておく

PMLE で一番登場するマネージドサービスは Vertex AI Platform。Vertex AI と一言で言っても機能が多岐に渡るため、小さなデータで良いので学習 → デプロイ → 監視 → 説明まで回して何のサービスで何が実現できるのかを実際にコンソールに触れて理解しておく。

特に、Pipelines、AutoML、Explainable AI あたりを動かして理解を深めておくことをお勧めする。