Professional Cloud Architect試験対策マニュアル

記事タイトルとURLをコピーする

G-gen の杉村です。 Professional Cloud Architect 試験 は、 Associate Cloud Engineer 試験の上位に位置する Google Cloud (旧称 GCP) の難関認定資格です。本投稿では試験の合格に役立つ、勉強方法や出題傾向などについて解説します。

Professional Cloud Architect

はじめに

Professional Cloud Architect 試験 とは

Professional Cloud Architect 試験 は Associate Cloud Engineer 試験の上位に位置する Google Cloud の難関認定資格です。
インフラ系、アプリ系の Google Cloud サービスの知識のみならず、データアナリティクス、セキュリティ、モニタリングなど幅広い知識が求められます。
この試験に合格していることは、 Google Cloud を幅広く理解しており、一人前の Google Cloud 技術者であることを示すといっても過言ではないでしょう。

可能であれば、当試験より先に Associate Cloud Engineer 試験に合格しておくことが望ましいです (ベターではありますが受験の必須要件ではありません) 。

blog.g-gen.co.jp

試験時間は 120 分、試験問題数は 50 問です。
試験は日本語と英語で提供されています。

Professional Cloud Architect 試験の難易度

当試験の難易度としては 中程度 だと言えます。
IPA の "応用情報技術者試験" 程度の基本的な IT 知識があり、かつ Google Cloud をある程度業務で使用した経験があるというのが前提知識として理想的です。
試験ガイドでは「3年以上の業界での経験と、1年以上の Google Cloud における経験」が推奨だと記載されていますが、必ずしもこれを満たしていなくても十分合格が狙える資格です。

むしろ普段から Google Cloud の公式ブログやドキュメントのベストプラクティスに目を通し、 Google の考えるクラウドらしいクラウドの使い方が何か、という一種の クラウド哲学 のようなものを頭にインプットしておくことが重要です。
選択肢に迷った時に「 最もクラウドらしい選択肢はどれか 」という判断基準が、助けになることがあります。

これらに加えて、当記事で追加の学習をすれば、合格は難しくないと言えます。

特に Amazon Web Services (AWS) の試験を受けたことがある人であれば気が付きますが、問題文の長さや複雑さは AWS Certified Solutions Architect - Professional 認定のそれと比較すると、短くてシンプルであると感じられます。体感的案難易度は AWS の Professional 試験より低いかもしれません。

推奨の勉強法

  1. Associate Cloud Engineer を先に取得する
  2. 試験ガイド を読み出題範囲を理解する
  3. 当記事を読み、出題傾向を理解する
  4. 把握した試験範囲・出題傾向をもとに勉強する
  5. 模擬試験 を受け、足りない知識を認識して、ギャップを埋める勉強をする
  6. ケーススタディ を直前に確認する

ドキュメント等を読むだけでは理解が進まないサービスも出てきます。
こういったときは「書籍を読む」「ブログ記事を検索して読む」「コンソール画面や gcloud で実際に触ってみる」の3つを 織り交ぜて学習 を進めるのがおすすめです。
特に3つめの「 触る 」は大事で、コンソールやコマンドラインを触ると リソースの構成 が手にとるように分かり、理解が進むことが多いです。
リソース構成を把握してからドキュメントに戻ると、理解度が全く違うことがあります。

ケーススタディ

Professional 試験では ケーススタディ と呼ばれる、架空の会社をテーマにしたクラウド導入事例が引用されます。

試験中は画面の右半分にケーススタディの内容を表示することができるため覚える必要はありませんが、目を通しておきましょう。
ほとんどがどんな場合でも要求されるような基本的な要件が書かれていますが、大事にしている (優先すべき) 要件が書かれている点に注意しましょう。
例えば、 コスト全世界からのレイテンシが小さい などトレードオフになりえる選択肢が現れた場合は、ケーススタディのビジネス要件がヒントになります。

ビジネス要件・技術要件に合わせて適切なサービスを選択する、などの問題が出題されます。
全ての問題でケーススタディが引用されるわけではありませんが、この「要件にあわせて適切なサービスを選択」というテーマは Professional 試験の共通の傾向に思えます。

出題傾向

出題範囲のサービスは Associate Cloud Engineer 試験対策記事 でご紹介したものと、大半が被っていますのでそちらの記事をご参照ください。

出題範囲は幅広く、多種多様なサービスを広く理解している必要があります。

当記事ではこれ以降、どのような試験問題が出るか、出題傾向とその内容を解説していきます。
公式ドキュメントへのリンク等もできるだけ付記していますので、知らない用語や理解の浅い概念があれば、ドキュメントを読む・実際にサービスに触れる等の対策を行ってください。

組織 / IAM

組織のポリシー

組織のポリシーでは、さまざまな制約を組織全体に課すことができます。
ここでの設定は IAM での許可よりも優先されます。
組織のポリシーでどんなことができるのか、もちろんすべて覚える必要はありませんが、組織に統制を効かせる際にどのようなポリシーが使われるだろうかと想像しながら以下のドキュメントを確認するとよいでしょう。

例えば「特定リージョンしか使えないようにする」「 External IP を持てる GCE VM を制限する」などのポリシーに注目してください。
ドキュメントにてこれらのポリシーの使い方を理解すれば OK です。

IAM の基本概念

IAM は リソースに紐づく概念 であり、 継承 が起きるということを正しく理解していてください。
IAM の概念については、以下のブログ投稿も参考にしてください。

blog.g-gen.co.jp

Associate 試験と同様に基本的な概念をしっかり理解しておけば解ける問題ばかりです。

また試験問題で「こういうシチュエーションを改善するにはどうするか」と問われるとき 最小権限の原則 を意識して改善策を考えてください。
オーナーなどの強いロールは極力使わない方向にするべきです。

またサービスアカウントの使い方は理解しておいてください。サービスアカウントは 人ではなくプログラムや Google Cloud サービスが使うアカウント です。
サービスアカウントに権限を与える際は、人のアカウントと同様に、最小権限の原則に従うべきです。
選択肢に安易に「組織の管理者を付与する」「オーナー権限を付与する」などがあれば、誤った選択肢である可能性が高いと言えます。

オペレーションスイート

Cloud Monitoring

Cloud Monitoring の基本機能 (Google Cloud の指標、 Ops エージェントの指標、カスタム指標、ダッシュボード... ) を押さえておきましょう。

blog.g-gen.co.jp

Cloud Monitoring にはリソースのモニタリングやアラートの発報などの機能のほか、簡易的なインシデント管理の機能もあります。
使ったことがない場合は、ドキュメントを中心に理解をしておく必要があります。

また Google Kubernetes Engine でも Cloud Monitoring を使ったモニタリングが活躍します。
こちらも確認しておくとよいでしょう。

Cloud Logging

Cloud Logging のシンク機能の仕様や用途をしっかり押さえておきましょう。
シンクからどのサービスにログをエクスポートできるのか、どんなアクションに繋げられるのか、という点が重要です。
また Google Kubernetes Engine 等のサービスとの連携も重要です。

Cloud Logging 全体の概要については以下の記事をご参照ください。

blog.g-gen.co.jp

応用的なテクニックとして Cloud Logging (sink) → Pub/Sub のようにログを送出し、 Pub/Sub トリガで Cloud Functions を起動することで イベントドリブンでリアルタイムな処理 が可能です。
上記の 文字面を見て構成図が思い浮かぶくらい には理解しておく必要があります。

セキュリティ・統制

Network Intelligence Center

Network Intelligence Center は Google Cloud のネットワーク関連の可視性を提供したり、モニタリングやトラブルシューティングに役立つサービスです。
どのような機能があるのかを、確認しておきましょう。

特にファイアウォールインサイト機能に注目です。
これは、自動的に VPC のファイアウォールログをチェックしてルールの棚卸し等に役立つ機能です。

なお VPC のファイアウォールログは ルールごとに明示的に有効化 することが必要な点に注意しましょう。

Data Loss Prevention

Cloud Data Loss Prevention (Cloud DLP) で何ができるかを確認しておきましょう。
また、スキャン結果はどこにどのように配置したり応用したりできるかが重要になってきます。

Cloud DLP の結果はメタデータとして Data Catalog に保存 できます。

Data Catalog は Google Cloud サービスで、いわゆるメタデータを管理するためのサービスです。
BigQuery 等に入っているデータに対してラベル付けをしたり説明を付記するなどして、データの管理・維持運用に用いられます。
特にデータ活用基盤では重要になるサービスです。

Cloud DLP + Data Catalog により個人情報 (PII) がどこに保管されているかが管理されます。

Kubernetes / Googke Kubernetes Engine (GKE)

基本概念

Google Kubernetes Engine (GKE) だけでなく Kubernetes の全般知識が求められる問題もあります。
Pod, Deployment, Service, Ingress, Namespace, Cluster, Istio, サーキットブレイク, マイクロサービス... などの単語や概念の理解を進めましょう。

Professional Cloud Architect 試験では GKE や Kubernetes 関連の問題が頻出です。

GKE や Kubernetes については各種 Web サイトや書籍が詳細に解説していますので、本記事では詳しい説明は省略させていただきます。

モニタリング

GKE はネイティブに Cloud Monitoring や Cloud Logging と統合されています。
この統合機能は Cloud Operations for GKE と呼ばれています。
あまり目にしない単語かもしれませんが、問題文で見て面食らわないようにしておきましょう。

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 の特性を、それぞれ人に自分の言葉で説明できるでしょうか?

運用管理の知識を問われたときの備えて、それぞれのデータベースのスキーマの扱い方 (定義の方法や変更の方法) も抑えておきましょう。

以下の記事の「その他のデータベース・移行」の項にて、データベースごとのユースケースを書いていますのでご参照ください。

blog.g-gen.co.jp

例えば Bigtable は高スループットが出るデータベースです。
IoT やアプリケーションのトラッキングのような秒間数万の書き込みリクエストがあるような場合に適しています。

一方で標準的な SQL には対応していないため、 SQL での操作が必要な場合や、トランザクション処理が必要な場合には Cloud SQL や Spanner を検討することになります。

Cloud SQL

オンプレミスからのデータベース (RDB) の移行先としては Cloud SQL が選択されることが多いはずです。
どのような手法で移行ができるかを理解しておきましょう。

また、バックアップとリストアの方法や冗長化の方法など、可用性に関する内容は自信をもって設計・実装できるくらいに把握しておきます。

自動バックアップ機能に加え、トランザクションログの保存日数指定などが行える点を押さえておきます。
また「ポイントインタイムリカバリ (PITR) 機能」を用いるには、 自動バックアップとポイントインタイムリカバリを両方有効にする 必要があります。

PITR により、データベースを特定時刻の状態で復旧することができます (ただし、元のインスタンスとは別インスタンスとして構築されることになります) 。

Cloud Storage

Cloud Storageの基本的な仕様や概念は、 Associate 試験で押さえていると思います。
以下のようなポイントを押さえて、応用的な使い方を理解しましょう。

  • アクセス制御
  • オブジェクトのバージョニング
  • 保持ポリシーと保持ポリシーのロック
  • Cloud Storage のパフォーマンス最適化 (資料)

最後のリンクにある「アップロード時のパフォーマンス最適化」については、マルチスレッドアップロードの方法の記述を中心に一通り目を通しておきましょう。

また当ブログの記事で Cloud Storage の詳細を解説していますので、ご参照ください。

blog.g-gen.co.jp

Cloud Run / Cloud Functions / App Engine (コンピューティング系サービス)

各サービスのアーキテクチャ、用法、運用管理、デプロイ、スケーリングなどの特徴を理解する必要があります。

  • どのようなときにどのサービスを選択するのか? (それぞれのサービスの強みは何か)
  • 冗長性を確保するには?
  • コストを最適化するには?
  • 安全に新バージョンに移行するためのデプロイ方法は?

例えば Cloud Run では 新旧バージョン間でトラフィックを徐々に移行 することができます。

また「静的ファイルは Cloud Storage に配置。動的バックエンドは Cloud Functions で実装。フロントには Cloud Load Balancing を置く」といった クラウドネイティブなアーキテクチャ は高可用性・コスト効率が非常に良いため、クラウド系試験ではこういった選択肢を選ばされることが多いと言えます。

このように、サービスの特性を活かしたアーキテクチャやデプロイ方法などが問われます。

CI/CD

できるだけ Google Cloud サービスを使って CI/CD パイプラインを構築するにはどのサービスを使うか、理解しておきます。
また、各コンピューティングサービスへのアプリケーションデプロイの方法を押さえます。

Google Cloud サービスで実装する CI/CD では Cloud Source RepositoryCloud Build といったサービスが重要になってきます。

Cloud Build はそのサービス名称からするとビルド専用のサービスにも思えますが、実際には GKE, Cloud Run, App Engine, Cloud Functions などへのデプロイ機能が備わっています。

Git や Cloud Source Repository (Google Cloud の提供するマネージドな Git リポジトリ) などの コードレポジトリにソースがコミットされたことを検知して Cloud Build が動き出し、アプリケーションやコンテナのビルドが走り、 Cloud Build がそれらを GKE などにデプロイする、という一連の流れが基本です。

VPC / ネットワーク

VPC の基本

以下の2記事を参考に、 VPC の基本は改めておさらいしておきましょう。

  1. Google Cloud(旧GCP)のVPC基本機能を学ぶ!VPC・サブネット・NAT・ピアリング・AWSとの違い
  2. Google CloudのVPCを徹底解説!(基本編)

Associate Cloud Engineer 試験と同等以上のレベルの理解は必要です。当社の Associate Cloud Engineer 試験対策記事の VPC の箇所 も、改めて参考にしていただければと思います。

ネットワークセキュリティ

VPC ファイアウォールの基本的な仕様は Associate 試験の際に理解したと思います。

Cloud Armor やその 実装方法 (コンソール / gcloud) も押さえておきましょう。

細かいパラメータまで覚える必要はありませんが、コンソールを眺めたり、コマンドラインをドキュメント上で一通り眺めておくとよいかもしれません。

特に Cloud Armor のセキュリティポリシーは Cloud SDK (CLI) でのコマンド名が gcloud compute security-policies となっているのが分かりづらいですので要注意です。これが出てきたら「あ、これは Cloud Armor のセキュリティポリシーを作るコマンドだ」と分かるようにしておきましょう。

接続性

異なる VPC に存在する VM 同士で通信するにはどうすればいいか、といった応用的な方法を理解しておきます。

"VPC 間で Peering を繋ぐ" , "VPC 間で VPN を繋ぐ" , "VPC を跨いだ NIC を VM に追加する" といった方法が思いつくと思います。
それぞれの特徴を理解する必要があります。

例えば "VPC 間で Peering を繋ぐ" だと、自動的にルートが交換され、 VPC 間で通信ができるようになります。
ただし以下のような場合、 VPC AVPC C 同士は通信できません。

VPC A ===(Peering)=== VPC B ===(Peering)=== VPC C

VPC AC は直接繋がっていないので、お互いに通信できません。
これは "推移的な通信" と呼ばれます。 VPC Peering では 推移的な通信はできない という仕様です (2 hop 制限と呼ぶこともあります) 。
ただし、これが Peering ではなく Cloud VPN であれば、適切なルート設定により推移的な通信は可能になります。

また "VPC を跨いだ NIC を VM に追加する" ということを行えば、その VM は双方の VPC (Subnet) と通信することができます。

ハイブリッドネットワーク

オンプレミスネットワークと VPC / Google サービスを接続するための様々な方法を理解しておきましょう。

Dedicated InterconnectPartner Interconnectダイレクト ピアリングキャリア ピアリング といったプライベート接続方法があり、これら4つの接続方法はユースケースが異なります。
細かい設定までは理解する必要はありませんが、 どのようなときにどれを選ぶか 、は理解しておきましょう。

Google Cloud の VPC へのプライベートネットワーク接続のためには Dedicated Interconnect または Partner Interconnect を選択します。

Google Workspace 等の Google サービスに接続したいときに ダイレクト ピアリング や キャリア ピアリング を選択します。

専有型か共有型かという観点では、自社・データセンター等から Google の PoP (Point of Presence) に直接接続できる場合で、かつ安定的で広い帯域が求められる場合に Dedicated Interconnect / ダイレクト ピアリング を選択します。
そうでない場合は Partner Interconnect / キャリア ピアリング です。

Google Compute Engine (GCE)

GCE の基本的な仕様は Associate 試験の際に理解したと思います。
運用の際に重要となる応用的な概念を加えて理解しておきましょう。

また IAP について以下の記事も参考にして内容をご理解ください。

blog.g-gen.co.jp

その他

以下のようなサービスも出題範囲となっています。
細かい使い方まで分かれば理想的ですが、業務で使ったことがなければ最低でも概要 (どのようなサービスか、どのようなときにどのように利用されるのか) を押さえておきましょう。

  • Migrate for Compute Engine
    • ランブック という言葉を把握しておく
  • Cloud Memorystore
    • Redis をクラウドに移行する際の選択肢として認識しておく
  • Cloud Filestore
    • 選択可能な Service Tier を把握し、ユースケースやスループット上の限界値を確認しておく
  • Cloud Tasks
  • Cloud Scheduler
  • Anthos

杉村 勇馬 (記事一覧) (Facebook)

クラウドソリューション部 部長

元・警察官という経歴を持つ現・エンジニア。クラウド管理運用やネットワークに知見。AWS 12冠、Google Cloud認定資格11冠。

2022年6月現在、ハマっているものはピーナッツくんの新しいアルバム Walk Through the Stars 。