G-gen の杉村です。 Professional Cloud Architect 試験 は、 Associate Cloud Engineer 試験の上位に位置する Google Cloud (旧称 GCP) の難関認定資格です。本投稿では試験の合格に役立つ、勉強方法や出題傾向などについて解説します。
- はじめに
- 組織と IAM
- オペレーションスイート
- セキュリティ・統制
- Google Kubernetes Engine（GKE）
- データベース・分析
- Cloud Storage
- コンピュートサービス
- CI/CD
- VPC / ネットワーク
- Compute Engine
- その他のプロダクト
はじめに
Professional Cloud Architect 試験 とは
Professional Cloud Architect は、Associate Cloud Engineer 試験の上位に位置する Google Cloud の認定資格です。
IT インフラやアプリケーション開発に関係する Google Cloud サービスの知識のみならず、データ分析、セキュリティ、モニタリングなど幅広い知識が求められます。この試験に合格していることは、Google Cloud を幅広く理解しており、一人前の Google Cloud 技術者である証左だといっても過言ではないでしょう。
試験時間は 120 分、試験問題数は 50〜60 問です。試験は日本語と英語で提供されています。
可能であれば、当試験より先に Associate Cloud Engineer 試験に合格しておくことが望ましいですが、受験にあたり必須要件ではありません。Associate Cloud Engineer 試験については以下の記事もご参照ください。
難易度
当試験の難易度としては 中程度 だと言えます。
IPA の「応用情報技術者試験」程度の基本的な IT 知識があり、かつ Google Cloud をある程度業務で使用した経験があるというのが前提知識として理想的です。試験ガイドでは「3年以上の業界での経験と、1年以上の Google Cloud における経験」が推奨だと記載されていますが、必ずしもこれを満たしていなくても十分合格が狙える資格です。
むしろ普段から Google Cloud の公式ブログやドキュメントのベストプラクティスに目を通し、Google の考えるクラウドらしいクラウドの使い方が何か、という一種のクラウドの哲学を頭にインプットしておくことが重要です。選択肢に迷った時に、最もクラウドらしい選択肢はどれかという思考が助けになります。
これらに加えて、当記事で追加の学習をすれば、合格は難しくないと言えます。
特に Amazon Web Services（AWS）の試験を受けたことがある人であれば気が付きますが、問題文の長さや複雑さは AWS Certified Solutions Architect - Professional 認定のそれと比較すると、短くてシンプルであると感じられます。体感的案難易度は AWS の Professional 試験より低いかもしれません。
推奨の勉強法
- Associate Cloud Engineer を先に取得する
- 試験ガイド を読んで出題範囲を理解する
- 当記事を読み、出題傾向を理解する
- 把握した試験範囲・出題傾向をもとに勉強する
- 模擬試験 を受け、足りない知識を認識して、ギャップを埋める勉強をする
- ケーススタディ を直前に確認する
ドキュメントを読むだけでは理解が進まないサービスも出てきます。こういったときは「書籍を読む」「ブログ記事を検索して読む」「コンソール画面や gcloud で実際に触ってみる」の3つを織り交ぜて学習を進めるのがおすすめです。
特に3つめの「実際に触れる」は重要です。コンソールやコマンドラインを触ると、Google Cloud プロダクトのリソース構成が手にとるように分かり、理解が進みます。リソース構成を把握してからドキュメントに戻ると、理解度が全く違うことがあります。
ケーススタディ
Professional 試験ではケーススタディと呼ばれる、架空の会社をテーマにしたクラウド導入事例が引用されます。
試験中は画面の右半分にケーススタディの内容が表示されるため、内容を覚えておく必要はありませんが、事前に目を通しておきましょう。どんな本番環境でも要求されるような基本的な要件も多く書かれていますが、そのケースで大事にしている（優先すべき）要件に注意しましょう。例えば「コスト vs 全世界からのレイテンシ」というトレードオフからどちらかを選択しなくてはいけない場合、ケーススタディに書かれているビジネス要件や技術要件がヒントになります。
出題傾向
出題範囲のサービスは、Associate Cloud Engineer 試験対策記事に記載されているものと、大半が重複していますので、そちらの記事をご参照ください。
出題範囲は幅広く、多様なサービスを広く理解している必要があります。
当記事ではこれ以降、どのような試験問題が出るか、出題傾向とその内容を解説していきます。公式ドキュメントへのリンク等もできるだけ付記していますので、知らない用語や理解の浅い概念があれば、ドキュメントを読んだり、実際にサービスに触れる等の対策を行ってください。
更新試験
Professional Cloud Architect 試験には、一度合格して更新時期を迎えた人向けの更新試験も用意されています。
更新試験は英語と日本語で提供されており、問題数は通常試験の約半分の25問、試験時間は半分の1時間です。また受験費用は、通常料金の半額の $100 です。
更新試験は通常試験とは出題範囲が異なっており、ケーススタディの内容も、生成 AI ソリューションをテーマとしたものになっています。ケーススタディに関する問題が全体の90%〜100%を占めているとされており、ほとんどが生成 AI 関連の問題と考えられます。最新情報は、公式の更新認定試験ガイドを参照してください。
組織と IAM
組織のポリシー
組織のポリシーでは、さまざまな制約を組織全体に課すことができます。
ここでの設定は IAM での許可よりも優先されます。組織のポリシーでどんなことができるのか、もちろんすべて覚える必要はありませんが、組織に統制を効かせる際にどのようなポリシーが使われるだろうかと想像しながら以下のドキュメントを確認するとよいでしょう。
- 参考 : 組織のポリシーの制約
例えば以下のようなポリシーに注目して、意義や使い方（パラメータに何を設定するか）を事前に理解しておいてください。
- 特定リージョンしか使えないようにする (
constraints/gcp.resourceLocations) - 外部 IP アドレスを持つことができる Compute Engine VM をホワイトリスト式で制限する (
constraints/compute.vmExternalIpAccess) - 外部組織の Google アカウントが IAM 権限を持てないようにする (
constraints/iam.allowedPolicyMemberDomains)
以下の記事も参照してください。
IAM の基本概念
Google Cloud の Identity and Access Management（IAM）は、リソースが持つポリシーが中心の概念であること、また継承が起きるということを正しく理解してください。IAM の概念については、以下の記事も参考にしてください。
Associate 試験と同様に基本的な概念をしっかり理解しておけば解ける問題ばかりです。
また試験問題で「こういうシチュエーションを改善するにはどうするか」と問われるとき、最小権限の原則を意識して改善策を考えてください。オーナーなどの強いロールは極力使わない方向にするべきですし、使う場合は組織全体に対して付与するのではなく、フォルダなどを使って適用範囲を制限します。
また、サービスアカウントの使い方は理解しておいてください。サービスアカウントは、人間ではなくプログラムや Google Cloud サービスが使うアカウントです。サービスアカウントに権限を与える際は、人のアカウントと同様に、最小権限の原則に従うべきです。
選択肢に安易に「組織の管理者を付与する」「オーナー権限を付与する」などがあれば、誤った選択肢である可能性が高いと言えます。
また個人のアカウントに個別に IAM 権限を付与することなく、グループに対して付与することで、運用工数を削減することができます。
- 参考 : IAM を安全に使用する
オペレーションスイート
Cloud Monitoring
Cloud Monitoring の基本機能（Google Cloud の指標、 Ops エージェントの指標、カスタム指標、ダッシュボード等）を理解してください。
Cloud Monitoring にはリソースのモニタリングやアラートの発報などの機能のほか、簡易的なインシデント管理の機能もあります。ドキュメント中心で構わないので、理解をしておく必要があります。
また Google Kubernetes Engine（GKE）でも Cloud Monitoring を使ったモニタリングが活躍します。こちらも確認しておくとよいでしょう。
Cloud Logging
Cloud Logging のシンク（ログルーター）の仕様や用途をしっかり押さえておきましょう。シンクからどのサービスにログをエクスポートできるのか、どんなアクションに繋げられるのか、という点が重要です。また集約シンクを使うことで、組織配下の全プロジェクトや、特定フォルダ配下の複数のプロジェクトのログを容易に集約し、監査用プロジェクトに保存することもできます。
- 参考 : ログエントリを転送する
Compute Engine VM に Ops Agent をインストールすれば、VM 上のアプリケーションログを簡単に Cloud Logging に送信し、ログシンクを使って BigQuery や Cloud Storage へログを転送、保存することができます。
- 参考 : Ops エージェントの概要
また Cloud Logging からログをフィルタしたうえで Pub/Sub へ送信すれば、特定のログ発生をトリガにしてイベントドリブンで Cloud Run functions を起動することもできます。こういった文面を読んだ時に、構成図が思い浮かぶくらいに理解しておきましょう。
Cloud Logging 全体の概要については以下の記事をご参照ください。
セキュリティ・統制
Network Intelligence Center
Network Intelligence Center は Google Cloud のネットワーク関連の可視性を提供したり、モニタリングやトラブルシューティングに役立つサービスです。以下の記事を読んで、どのような機能があるのかを確認しておきましょう。
ファイアウォールインサイト機能に注目です。これは、自動的に VPC のファイアウォールログをチェックしてルールの棚卸し等に役立つ機能です。
なお VPC のファイアウォールログは、ファイアウォールルールごとに明示的に有効化する必要がある点に注意しましょう。ファイアウォールのログを有効化しないと、ファイアウォールインサイト機能も動作せず、いつまで待っても検知事項がゼロのままです。
Sensitive Data Protection
Sensitive Data Protection（旧称 Cloud Data Loss Prevention、Cloud DLP）で何ができるかを確認しておきましょう。また、スキャン結果はどこにどのように配置したり応用したりできるかが重要になってきます。
データ処理パイプライン中で Sensitive Data Protection を使って PII（個人識別情報）を検知することで、PII を削除してからデータを保存するユースケースなどが挙げられます。
また、Sensitive Data Protection の検査結果はデータに対するメタデータとして、Dataplex Universal Data Catalog に保存できます。
Google Kubernetes Engine（GKE）
基本概念
Professional Cloud Architect 試験では Google Kubernetes Engine（GKE）だけでなく Kubernetes の全般知識が求められる問題もあります。 Pod、Deployment、Service、Ingress、Namespace、Cluster、Istio、サーキットブレイク、マイクロサービスなどの単語や概念の理解を進めましょう。
GKE や Kubernetes については以下の記事も参考にしてください。
モニタリング
GKE はネイティブに Cloud Monitoring や Cloud Logging と統合されています。この統合機能は Cloud Operations for GKE と呼ばれています。
- 参考 : GKE のオブザーバビリティ
GKE クラスタで Managed Service for Prometheus を有効化することもできます。新規クラスタのみならず、既存クラスタでも有効化が可能です。
安全なデプロイ
readiness probe と liveness probe を設定しておくと、Pod が更新された際などに、正常でない Pod にトラフィックがルーティングされてしまい、サービスに影響が出ることを防ぐことができます。
GKE からの Google API への認証
GKE で実行されているアプリケーションから Google Cloud サービスへアクセスする際の推奨事項を確認しておきましょう。
GKE から Google Cloud API への認証方法の最初の選択肢は Workload Identity 機能です。これは Kubernetes のサービスアカウントと Google Cloud のサービスアカウントを紐づける機能です。GKE コンテナからすると Kubernetes サービスアカウントのみを意識すれば良いため Kubernetes リソースと Google Cloud リソースが疎結合になり、保守性が向上します。
データベース・分析
データ分析プラットフォームの選択
Google Cloud のデータ分析系サービスは多数ありますが、それぞれをどんなユースケースのときに選択するのか、押さえておきましょう。Cloud SQL、Datastore（Firestore）、Bigtable、Spanner、BigQuery の特性を、それぞれ自分の言葉で説明できるでしょうか？
運用管理の知識を問われたときの備えて、それぞれのデータベースのバックアップ方法なども抑えておきましょう。
以下の記事の「その他のデータベース・移行」の項にて、データベースごとのユースケースを書いていますのでご参照ください。
例えば Bigtable は高スループットが出るデータベースです。IoT やアプリケーションのトラッキングのような秒間数万の書き込みリクエストがあるような場合に適しています。一方で標準的な SQL には対応していないため、 SQL での操作が必要な場合や、トランザクション処理が必要な場合には Cloud SQL や Spanner を検討することになります。
Firebase はサーバーレスでリクエスト数に応じた従量課金であるため、あまりワークロードが多くないシステムにおいてコストを重視する場合などに選択できます。
各種データベースサービスについて、以下の記事も参考にしてください。
- 参考 : Cloud SQLを徹底解説！ - G-gen Tech Blog
- 参考 : Cloud Spanner を徹底解説！ - G-gen Tech Blog
- 参考 : BigQueryを徹底解説！(基本編) - G-gen Tech Blog
- 参考 : Bigtableを徹底解説！ - G-gen Tech Blog
- 参考 : Firebaseを徹底解説！ - G-gen Tech Blog
- 参考 : AlloyDB for PostgreSQLを徹底解説！ - G-gen Tech Blog
Cloud SQL
オンプレミスからのデータベース（RDB）の移行先としては Cloud SQL が選択されることが多いはずです。どのような手法で移行ができるかを理解しておきましょう。
また、バックアップとリストアの方法や冗長化の方法など、可用性に関する内容は自信をもって設計・実装できるくらいに把握しておきます。
自動バックアップ機能に加え、トランザクションログの保存日数指定などが行える点を押さえておきます。また「ポイントインタイムリカバリ（PITR）機能」を用いるには、自動バックアップとポイントインタイムリカバリを両方有効にする必要があります。
PITR により、データベースを特定時刻の状態で復旧することができます。ただし、元のインスタンスとは別インスタンスとして構築されることになります。
以下の記事を参考にして、Cloud SQL の仕様を一通り理解しましょう。
Cloud Storage
Cloud Storageの基本的な仕様や概念は Associate 試験で押さえているはずです。さらに以下のようなポイントを押さえて、応用的な使い方を理解しましょう。
- IAM によるアクセス制御
- オブジェクトのバージョニング
- 保持ポリシーと保持ポリシーのロック
- ストレージクラス（Standard、Nearline、Coldline、Archive）
以下の記事で Cloud Storage の一通りの仕様を解説していますので、ご参照ください。
コンピュートサービス
概要
Google Cloud のコンピュートサービスである Compute Engine、Cloud Run、Cloud Run functions、App Engine について、各プロダクトのアーキテクチャ、用法、運用管理、デプロイ、スケーリングなどの特徴を理解する必要があります。
- どのようなときにどのプロダクトを選択するのか？それぞれのプロダクトの強みは何か？
- や可用性を高める方法は？
- コストを最適化するには？
- 安全にアプリケーションの新バージョンをデプロイして移行する方法は？
例えば Cloud Run では、新旧バージョン間でトラフィックを徐々に移行することができます。割合を指定することで、「新バージョンに10%、旧バージョンに90%のトラフィックをルーティング」「問題ないことがわかったら、徐々に%を変えていく」といった運用が可能です。
また「静的ファイルは Cloud Storage に配置。軽量なバックエンド API は Cloud Run functions で実装。フロントには Cloud Load Balancing を置く」といったクラウドネイティブなアーキテクチャは可用性・コスト効率が高いことも理解しましょう。
このように、プロダクトの特性を活かしたアーキテクチャやデプロイ方法などが問われます。
以下の記事も参考にしてください。
App Engine
App Engine では、運用工数が低いスタンダード環境と、より詳細なカスタマイズができるフレキシブル環境が選択できます。
デプロイの容易さや運用性を優先する場合で、開発言語が Java、Node.js、Go など、スタンダード環境に対応しているプログラミング言語である場合は、スタンダードが選択肢になります。
- 参考 : App Engine 環境を選択する
また、App Engine には新バージョンをデプロイする際、まずは別の URL へ新バージョンをデプロイして、テスト完了後に任意のタイミングで本番昇格する機能もあります。
また、App Engine のフレキシブル環境は VPC ネットワーク上の Compute Engine VM で実行される一方、スタンダード環境は VPC 外で実行されている点に注意が必要です。スタンダード環境の App Engine アプリケーションから VPC リソースや、VPC ネットワークと VPN や専用線で接続されているオンプレミス環境のリソースにアクセスするには、サーバーレス VPC アクセスを設定する必要があります。
- 参考 : App Engine 環境を選択する
- 参考 : VPC ネットワークへの接続
CI/CD
概要
Google Cloud サービスを使って CI/CD パイプラインを構築するにはどのサービスを使うか、理解しておきます。また、各コンピューティングサービスへのアプリケーションデプロイの方法を押さえます。Google Cloud プロダクトで実装する CI/CD では、Cloud Build が重要です。
Cloud Build はそのサービス名称からするとビルド専用のサービスにも思えますが、実際には GKE、Cloud Run、App Engine、Cloud Run functions などへのデプロイ自動化にも使われます。
Git などのソースコードレポジトリの特定のブランチに、ソースコードがコミットされたことを検知して Cloud Build が動き出し、アプリケーションやコンテナのビルドやテストが実行され、その後 GKE などにデプロイする、という一連の流れが基本です。
コンテナセキュリティ
Binary Authorization というサービスでは、Google Kubernetes Engine（GKE）や Cloud Run で「署名済みのコンテナイメージ」以外はデプロイできないようにする機能があります。これにより、検査されたセキュアなイメージ以外のデプロイを防ぐことができます。
VPC / ネットワーク
VPC の基本
以下の2記事を参考に、Virtual Private Cloud（VPC）の基本は改めておさらいしておきましょう。
- Google Cloud(旧GCP)のVPC基本機能を学ぶ！VPC・サブネット・NAT・ピアリング・AWSとの違い - G-gen Tech Blog
- Google CloudのVPCを徹底解説！(基本編) - G-gen Tech Blog
VPC に対して、Associate Cloud Engineer 試験と同等以上のレベルの理解は必要です。Associate Cloud Engineer 試験対策記事の VPC に関する記述も、改めて参考にしてください。
ネットワークセキュリティ
VPC ファイアウォールの基本的な仕様は、Associate 試験と同様に必須です。
また Cloud Armor の基本概念や、実装方法（Google Cloud コンソールおよび gcloud コマンドライン）も押さえておきましょう。
Cloud Armor はフルマネージドの WAF サービスです。L7 レベルの攻撃を防ぐ機能に加え、接続元 IP アドレスを制限することもできます。Fastly などの CDN からのトラフィックは許可できるよう、名前付き IP アドレスリストも用意されています。Fastly で言えば sourceiplist-fastly というようなリスト名です。
Cloud Armor の基本は以下の記事で把握することができます。
接続性
概要
異なる VPC ネットワークに存在する VM 同士で通信するにはどうすればいいか、といった応用的な方法を理解しておきます。以下のそれぞれの特徴を理解してください。
- VPC 間で VPC ネットワークピアリングを接続する
- VPC 間で Cloud VPN を使って接続する
- 複数の VPC の NIC を VM に追加する
VPC ネットワークピアリングを使うと、異なる VPC ネットワーク間を接続できます。利用料金がかからず、最もコスト効率の良い方法です。VPC ネットワーク同士が異なるプロジェクトや異なる組織に所属していても、VPC ネットワークピアリングを使うことができます。
- 参考 : VPC ネットワーク ピアリング
VPC 間の推移的通信
VPC ネットワークピアリングで2つの VPC ネットワークを接続すると、自動的にルートが交換され、相互に通信できるようになります。ただし以下のような場合、 VPC A と VPC C 同士は通信できません。
VPC A ===(Peering)=== VPC B ===(Peering)=== VPC C
VPC A と C は直接繋がっていないので、お互いに通信できません。この特性を「VPC ネットワークピアリングでは、推移的な接続はできない」と表現します。俗にこれを「2ホップ制限」と呼ぶこともあります。
ただし、この構成を VPC ネットワークピアリングではなく Cloud VPN で構成すれば、適切なルート交換を設定する前提で、推移的な通信が可能です。
ハイブリッドネットワーク
オンプレミスネットワークと VPC ネットワークを接続するための様々な方法を理解しておきましょう。
Google Cloud には、Dedicated Interconnect、Partner Interconnect、ダイレクトピアリング、キャリアピアリングと呼ばれる4つのライベート接続方法があり、それぞれユースケースが異なります。 細かい設定までは理解する必要はありませんが、どのようなときにどれを選ぶかを理解しておきましょう。
オンプレミスから Google Cloud の VPC ネットワークへプライベート接続を確立するためには、Dedicated Interconnect（専有型専用線）または Partner Interconnect（共有型専用線）を選択します。これらの専用線サービスを使うことで、Cloud VPN に比べて、安定した帯域とレイテンシを確保できます。
一方で、Google Workspace 等の Google サービスに接続したいときに ダイレクト ピアリング（専有型専用線）やキャリアピアリング（共有型専用線）を選択します。
専有型か共有型かという観点では、自社・データセンター等から Google の PoP（Point of Presence）に直接接続できる場合であり、かつ安定的で広い帯域が求められる場合に、専有型である Dedicated Interconnect / ダイレクトピアリングを選択します。一方でコストが重視される場合は、共有型である Partner Interconnect / キャリアピアリングを選択します。
可用性 SLA
Cloud VPN や Cloud Interconnect の可用性についても理解しておきます。
Cloud VPN で言えば、99.99% の可用性 SLA が適用されるには、以下の構成である必要があります。
- 1台の HA VPN ゲートウェイを、2台のピアデバイスに接続（トンネル数は2）
- 1台の HA VPN ゲートウェイを、外部 IP アドレスを2つ持つ1台のピアデバイスに接続（トンネル数は2）
- 1台の HA VPN ゲートウェイを、1つの外部 IP アドレスを持つ1台のピアデバイスに接続（トンネル数は2）
つまり、トンネルが2つ確立されていれば、オンプレ側のルータが1台でも、99.99%の可用性 SLA の対象になります。ただし HA VPN ゲートウェイ側は、2つのインターフェイスを使用する必要があります。
以下のドキュメントを参照し、構成を理解しておいてください。
Compute Engine
Compute Engine の基本
Compute Engine の基本的な仕様は、Associate 試験と同様です。さらに、運用にあたり重要となる応用的な概念を加えて理解しておきましょう。
マネージドインスタンスグループ
マネージドインスタンスグループ（MIG）におけるインスタンスのアップデートの仕様が問われることがあります。
MIG でインスタンスを更新するとき、方法が「自動更新（Automatic または proactive）」「選択（selective または opportunistic）」の二種類があります。前者はインスタンスの更新が自動的にされます。後者は手動で命令したときや新インスタンスが作成されたときにのみ更新されます。日中の稼働が激しいシステムなどでは、自動更新（proactive 更新）はリスクが大きいため、避けることを検討します。
リージョン永続ディスクを利用した可用性向上
リージョン永続ディスクは、Compute Engine VM にアタッチ可能な永続ディスクです。通常の永続ディスクがゾーンリソースなのに対して、リージョン永続ディスクはリージョンリソースです。ある片方のゾーンで障害が発生しても、データは別のゾーンに複製されます。
Compute Engine VM を複数のゾーンにデプロイし、現用系と待機系のアクティブ/スタンバイ構成を取っている場合、現用系のゾーンが停止しても、リージョン永続ディスクであれば待機系の VM に強制アタッチできます。これにより、可用性の高い構成を実現できます。
ライセンスの持ち込み
Windows Server のライセンスは、一定条件下で Google Cloud に持ち込む（BYOL）ことができます。以下のドキュメントを参考に、一連の流れを把握してください。
- 参考 : お客様所有ライセンスの使
ライセンスの持ち込みには、オンプレミスの仮想マシンの、仮想ディスクファイルを Compute Engine にインポートし、イメージを作成します。また、デプロイ先の Compute Engine は、物理的に専有された単一テナントノードである必要があります。
その他
以下のような細かい仕様を押さえておいてください。
- Cloud IAP
- Linux VM での起動スクリプトの使用
- オーバープロビジョニング（CPU やメモリが過剰にアサインされている VM）に対して推奨事項を表示する方法
- Spot VM
その他のプロダクト
以下のようなサービスも出題範囲となっています。細かい使い方まで分かれば理想的ですが、業務で使ったことがなければ、最低でも「どのようなサービスか」「どのようなときに、どのように利用されるのか」などを押さえておきましょう。
- Migrate for Compute Engine
- ランブックという言葉を把握しておく
- Cloud Memorystore
- Cloud Filestore
- Firestore ではなく Filestore
- 選択可能な Service Tier を把握し、ユースケースやスループット上の限界値を確認しておく
- Cloud Scheduler
- Anthos Service Mesh / Anthos Config Management
- Dataproc
杉村 勇馬 (記事一覧)
執行役員 CTO
元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。
Follow @y_sugi_it