G-gen の杉村です。当記事では Google Cloud（旧称 GCP）の認定試験の中でも基本的なレベルの内容である Associate Cloud Engineer 試験 の合格に役立つ情報を記載します。
- はじめに
- 組織とリソース
- IAM
- VPC
- Cloud DNS
- Cloud Load Balancing
- Compute Engine
- コンピューティングサービス
- Cloud Storage
- データベース、データ分析
- Google Cloud Observability
- 料金
- Access Approval
- その他
はじめに
当記事について
当記事では Google Cloud（旧称 GCP）の認定試験の中でも基本的なレベルの内容である Associate Cloud Engineer 試験の合格に役立つ情報を記載します。
試験の利用規約において、試験の内容を公開することは禁じられています。本投稿では試験問題そのものを書くこと等はせず、合格するためには何を知っているべきか、を中心に記載します。
なお当記事に記載されていることで試験範囲をすべてカバーできているわけではない点、ご了承ください。公式で発表されている試験ガイドや模擬試験も駆使して、学習を進めてください。
また当試験は、2024年8月26日に試験内容が改訂されています（2024年11月時点では英語版のみ。日本語版には未反映）。当記事は新旧どちらの試験にも対応できる Tips を記載していますが、どちらかというと新試験寄りの内容が記載されていることにご留意ください（当記事は、2024年11月に最新化されました）。
試験の概要
Associate Cloud Engineer 試験は、 Google Cloud の認定試験の中でも基本的な試験です。
Google Cloud のインフラ系サービスを中心に、セキュリティ、アプリケーションホスティング、データベース、モニタリングなど、幅広い範囲が対象です。試験時間は120分、試験問題数は50問です。
試験は日本語、英語、スペイン語、ポルトガル語で提供されています。
他の試験一覧は以下をご参照ください。
- 参考 : Google Cloud 認定資格
試験の難易度
当試験の難易度としては、他の Google Cloud 認定資格と比較して、比較的簡単であると言えます。
前提知識として、IPA の基本情報技術者試験程度の基本的な IT の知識があり、かつ Google Cloud に関する多少の業務経験を持っていることが望ましいです。公式ガイドには「6ヶ月以上の Google Cloud における実務経験」が推奨であると記載されていますが、必ずしもこれを満たしていなくても、十分合格を狙えます。
また普段から Google Cloud の公式ブログやドキュメントのベストプラクティスに目を通し、「Google の考えるクラウドらしさ」という、一種の「クラウド哲学」に慣れておくことが重要です。これに加えて、当記事で追加の学習をすれば、合格は難しくないと言えます。
推奨の勉強法
- 書籍や公式のトレーニングを受け Google Cloud の基本を理解する
- 試験ガイドを読み出題範囲を理解する
- 当記事を読み、出題傾向を理解する
- 理解した試験範囲・出題傾向をもとに勉強する
- 模擬試験を受け、足りない知識を認識して、ギャップを埋める勉強をする
上記のうち 1. の基礎学習については、書籍が日本語でいくつか出版されているのに加え、 Google Cloud Japan 社が定期的にセミナーなどを開催しています。
参考として、Google Cloud Certification Jumpstart プログラムというプログラムがあります。以下のサイトでは、過去のセッション内容を動画で閲覧することができます。
出題傾向
Associate Cloud Engineer 試験では以下のようなサービスが主題範囲です。
- 組織 / リソース
- アカウント（Cloud Identity / Google Workspace）
- Identity and Access Management（IAM）
- Virtual Private Cloud（VPC）
- Cloud DNS
- Google Cloud CLI（gcloud、bq）
- Compute Engine
- App Engine
- Cloud Run
- Google Kubernetes Engine（GKE）
- Cloud Storage
- データベース系サービス（Cloud SQL、Cloud Spanner、Bigtable、BigQuery)
- Cloud Monitoring / Cloud Logging
- 利用料金
当記事ではこれ以降、どのような試験問題が出るか、出題傾向を解説していきますので、参考にして各サービスの内容を押さえてください。わからない言葉や知らない用語があれば、公式ドキュメントなどを辿り、十分知識をつけてください。そのように勉強すれば、試験に合格できるのに加え、実践的な知識にもなります。
組織とリソース
リソース階層の概念
Google リソースが階層構造となっていることを押さえておきましょう。最上位に組織があり、その下にフォルダ（入れ子構造も可能）、プロジェクト 、そして個々の仮想マシン（VM）や BigQuery テーブルといった個別リソースが配置されるツリー構造となっています。
組織やプロジェクト自体も、リソースの一種です。リソースは IAM ポリシーを持っていること、また IAM 権限は継承されることに留意しましょう。以下の記事も参照してください。
プロジェクトと API 有効化
Google Cloud を利用開始するには何が必要か、と考えたとき、少なくともプロジェクトを作成することは 必須 です。
また、各サービスの API の有効化の概念を理解してください。例えば Google Cloud プロジェクトで Spanner を利用開始するとき、最初にプロジェクトで API を有効化する必要があります。
組織のポリシー
組織のポリシー機能を使うと、Google Cloud 組織全体で一定のルールを強制することができます。
特にサービスアカウントキーの発行を禁止するポリシーは、よく用いられます。
IAM
IAM の基本概念
Google Cloud の IAM（Identity and Access Management）は「リソースに紐づけて設定する」ものであり、また継承の概念があることを正確に理解しましょう。IAM の概念については、以下の記事を参考にしてください。
これが理解できれば、例えば VM にアタッチされたサービスアカウントがプロジェクトを跨いで別のプロジェクトのリソースにアクセスするにはどうすればいいかという質問にも回答できます。
IAM ロールはアカウントではなくグループに付与
複数のドキュメントで繰り返し述べられているベストプラクティスとして、「IAM ロールは、個別の Google アカウントではなく Google グループに付与するべきである」というものがあります。
Google グループは、Google アカウントをグルーピングするための仕組みで、Google Workspace または Cloud Identity に備わっています。
個別のアカウントにロールを付与してしまうと、その人が退職したり異動になるたびに多くのリソースに対して IAM のメンテナンスが必要になってしまいます。グループにアカウントを所属させて、そのグループに IAM ロールを付与するようにしましょう。
- 参考 : ポリシーの管理
基本ロールと事前定義ロール
基本ロールと事前定義ロールのいくつかを押さえておきましょう。基本ロールは以下の3つです。
- 閲覧者（
roles/viewer） - 編集者（
roles/editor） - オーナー（
roles/owner）
基本ロールは権限が大きいため、可能な限り利用を避けます。事前定義ロールや、カスタムロールを使ってきめ細かい権限制御をしましょう。事前定義ロールは以下のドキュメントで確認できます。数が多すぎるので、もちろん全てを覚える必要はありません。
- 参考 : ロールについて
サービスアカウント
Compute Engine VM 上で稼働するプログラムから Google Cloud リソースにアクセスする際の認証・認可は、サービスアカウントに権限を付与し、そのサービスアカウントを VM にアタッチすることで実現します。
Compute Engine にはデフォルトサービスアカウントが存在しますが、このデフォルトサービスアカウントよりも、ユーザー管理のサービスアカウントを新規作成して使用することが推奨されます。
VPC
VPC とサブネットの基本
VPC（Virtual Private Cloud）とサブネットの概念をきちんと理解します。以下の記事もご参考にお願いします。
前者の記事で VPC の全体概要を掴み、後者の記事で詳細を深堀りして理解いただければ役に立つかと思います。
VPC の特に重要な仕様として、以下が挙げられます。
- VPC の中に作ったサブネット間は自動的にルートが交換されるので、互いに通信できる
- サブネットはリージョンリソースである
- リージョンAに作ったサブネットAと、リージョンBに作ったサブネットBは互いに通信できる（ファイアウォールによる制限は可能）
また、 VPC 自体は IP アドレス帯を持たず、サブネットが持ちます。VPC へのサブネット追加は容易にできますし、既存サブネットを拡張することができる（IP アドレス帯の追加）ということを押さえましょう。
セグメントとファイアウォールルール
Google Cloud では、よく比較される Amazon Web Services（AWS）と比べると、細かく VPC やサブネットを分割しない傾向にあります。
ファイアウォールルールとネットワークタグを駆使して、いわゆる DMZ と内部ネットワークを分けることが第1選択肢です。とはいえ、全く通信させたくない環境同士は VPC を分けます。まずは、ファイアウォールルールの仕組みを正確に理解しておきましょう。
以下のようなことに回答できるようにしておいてください。
- 上り（Ingress）ルールと下り（Egress）ルールの概念
- サービスアカウントまたはネットワークタグを使ってファイアウォールルールの適用対象インスタンスを指定する方法
- デフォルト状態ではファイアウォールルールはどのような挙動をするのか
ファイアウォールルールの適用対象 VM は、サービスアカウントまたはネットワークタグを使って指定できます。より厳密な制御のためには、ネットワークタグよりもサービスアカウントを使うことが推奨されます。
限定公開の Google アクセス
限定公開の Google アクセスや Private Service Connect で何ができるかを押さえましょう。
特にハイブリッドネットワーク（オンプレとクラウドを併用したネットワーク）でのユースケースを押さえます。Private Service Connect を使うと、Cloud Run services のような非 VPC リソースにも、オンプレミスから専用線経由でリクエストを受信することができます。
Cloud DNS
Cloud DNS の基本的な機能を押さえてください。また Cloud DNS 以前に、一般的な DNS の仕組み、各レコードタイプの意味などは理解してください。
Cloud DNS では一般公開ゾーン（Public Zone）や限定公開ゾーン（Private Zone）を使うことができます。前者はインターネットから名前解決ができるゾーンであり、後者は Google Cloud の VPC の中などプライベートネットワークからのみ名前解決できるゾーンです。
- 参考 : 一般的な DNS の概要
Cloud Load Balancing
Cloud Load Balancing は、フルマネージドのロードバランサーです。用途の異なる10種類のロードバランサーが存在しますので、どんなケースでどのロードバランサーを選択すべきかを押さえます。「外部 vs 内部」「グローバル vs リージョナル」「HTTP(S) vs TCP/UDP」などの観点で、適切なロードバランサーを選択してください。以下のドキュメントのディシジョン・ツリーの図が分かりやすいです。
- 参考 : ロードバランサを選択する
また、ロードバランサーを実際にセットアップするときの、DNS との関係性を理解しましょう。ロードバランサーを作成すると、IP アドレスが払い出されます。その IP アドレスに対して DNS に A レコードを設定することで、ドメイン名でロードバランサーにアクセスできます。
- 参考 : ドメインをロードバランサに接続する
Compute Engine
基礎知識
Compute Engine の基礎的な知識は、以下の記事を参考にして理解してください。
ディスク・バックアップ・リストア
Persistent Disk（永続ディスク）に関する理解を深めておきましょう。
Persistent Disk からのインスタンス作成はどうすればよいのか、バックアップをスケジュールするにはどうすればよいか、などを公式ドキュメントから理解しておきます。
永続ディスクにはリージョン永続ディスクと、ゾーン永続ディスクがあります。これらの違いとユースケースも理解しておいてください。
- 参考 : Persistent Disk
購入オプション
Compute Engine にはいくつかの購入方法があります。以下を、人に説明できるまで理解しておきます。
- オンデマンド VM
- Spot VM
- 確約利用割引（CUD）
- 継続利用割引
Spot VM は非常にお得に見えますが、強制終了（プリエンプト）があることに留意します。
確約利用割引（CUD）や継続利用割引については、以下の記事も参考にしてください。
コンピューティングサービス
App Engine
App Engine の強みが何かを押さえましょう。細かい仕様まで覚える必要はなく、どのようなサービスで、何を強みとしているかを理解してください。
リリースした複数のバージョン間でユーザトラフィックの割合を調整できるのも優れた機能の一つです。
- 参考 : トラフィックの分割
Google Kubernetes Engine（GKE）
Google Kubernetes Engine（GKE） の基本的な概念と、操作方法（クラスタの操作や Depoloyment や Pod のデプロイ）を理解することが望ましいです。
クラスタ、ノードプール、ノード、Pod、Deployment、Service などの概念を理解してください。また、以下のような操作をコマンドラインで行う方法を把握しておいてください。
- 単一ゾーンのクラスタをマルチゾーンクラスタに変更する（ゾーンの追加）
- 既存クラスタに、従来と異なるマシンタイプのノードを追加する（新規ノードプールの追加）
- Horizontal Pod Autoscaling と Vertical Pod Autoscaling（recommendation）の使い方
以下の記事も参考にしてください。
Cloud Run
Cloud Run の基本的な概念と、使うべきシーンを理解してください。
Cloud Run は、利用が小規模または散発的なワークロード、特に API バックエンドや Web アプリ（Single Page Application、SPA）などで利用できます。
以下の記事も参考にしてください。
また、コールドスタートの概念も理解してください。コールドスタートを防ぐ最も簡単な方法は、最小インスタンス数を増やすことです。
コンピューティングサービスの使い分け
App Engine、Cloud Run、Google Kubernetes Engine（GKE）はいずれもアプリケーションをホストするためのサービスです。コンピューティングサービスと総称されることもあります。どのようなときに、どのサービスを利用するのかを考えられるようにしておきましょう。
以下の記事を一読し、各サービスの特徴と使うべき場面を理解しておきましょう。
Cloud Storage
Cloud Storage のユースケースも押さえてください。Cloud Storage はオブジェクトストレージですので、通常のファイルシステムとは特性も用途も異なります。安価でスケーラブルなので、非構造化データを含め、フォーマットもサイズも異なる多様なデータをクラウドに保存するために適した選択となります。
また、データの保存期間やアクセス頻度によって、どのストレージクラスを選ぶべきかを、しっかり押さえておきます。
- 頻繁にアクセスされる : Standard
- 1か月に1度 : Nearline
- 四半期に1度 : Coldline
- 年に1回未満 : Archive
以下のドキュメントが参考になります。
- 参考 : ストレージ クラス
また以下の記事で Cloud Storage の詳細を解説していますので、是非参考にしてください。
データベース、データ分析
Cloud SQL
以下の当社記事を読んで、Cloud SQL の基本的な機能を押さえます。
BigQuery
以下の記事を参考にして、BigQuery の機能を一通り押さえておきます。
Spanner
以下の記事を参考にして、Spanner の機能を一通り押さえておきます。「世界中からの大量のアクセスが見込まれる」「トランザクション処理が必要」「SQL の使用」などのキーワードがある場合は、Spanner のユースケースです。
データベースのベストな選択
以下の問いに答えられるようにしておきます。Google Cloud のデータベースサービスの特徴とユースケースを必ず押さえておきましょう。
- 大量の IoT センサーデータを格納し、低レイテンシで読み出すのに適したデータベースは？（BigTable）
- 複数のリージョンにまたがるトランザクションワークロードに適したデータベースは？ (Cloud Spanner)
- Web アプリケーションから使う NoSQL データベースは？（Firestore）
- 一般的なアプリケーションから MySQL や PostgreSQL などのリレーショナルデータベースを使いたいときは？（Cloud SQL）
- 大量のデータに対して SQL を使って分析を行いたいときは？（BigQuery）
データパイプライン
データパイプラインを実現するサービスである Dataflow の概要を理解しておきましょう。
Google Cloud Observability
Cloud Monitoring
Cloud Monitoring の基本機能は以下の記事で押さえることができます。
メトリクスを監視し、しきい値を超えたらアクションを起こす、という基本的な使い方を押さえます。アラートの通知先は「通知チャネル」として設定できます。
- 参考 : 通知チャネルの管理
Pub/Sub を通知先として設定できるので、アラートを契機にメッセージを Pub/Sub に送り、それをトリガに Cloud Functions を起動し、任意の宛先に通知を送ることもできます。
Cloud Logging
以下の記事で Cloud Logging の機能を把握する必要があります。
特に Log Analytics 機能やシンク（ログルーター）の機能を把握してください。
Cloud Audit Logs
証跡管理機能である Cloud Audit Logs の基本を、以下の記事で押さえておきましょう。
Cloud Audit Logs には、Google Cloud APIs へのリクエストの履歴が記録されます。例えば Bigtable のように、API でデータの読み書きをするサービスの場合、設定によってはデータの読み書き履歴を記録することができます。
料金
請求先アカウント
請求先アカウントの概念は以下の記事で押さえておきましょう。
予算アラート
請求先アカウントに対し、予算アラートを仕掛けることができます。
- 参考 : 予算と予算アラートの作成、編集、削除
利用料金の見積とアーキテクチャ
Google Cloud's pricing calculator を使って料金を見積もることができます。
‐ 参考 : Google Cloud's pricing calculator
パブリッククラウドでは、最適な利用料金となるよう考慮してアーキテクチャを設計するのも、アーキテクトの仕事になります。ある目的を達成するためのアーキテクチャは無数にありますが、その中でも最もコスト効率良く（Cost-effective に）実現する方法を編み出すことが求められます。
アーキテクチャを考えるとき、原則的には「マネージドサービスが使えるときは、マネージドサービスを使う。次点でコンテナ等、最後の選択肢として仮想サーバを選択する」と考えれば良いです。Cloud Run functions（旧 Cloud Functions）でアーキテクチャを実現すれば、Compute Engine の VM を常時起動させる必要がないのでコスト効率が良くなる、などが一例です。
利用料金データの BigQuery へのエクスポート
請求先アカウントから BigQuery へ請求データを自動エクスポートすることができます。
そのデータを、Looker Studio（旧称データポータル）で可視化して分析することもセオリーです。
Access Approval
Access Approval が何をするためのサービスなのか、また必要な IAM ロールは何かを押さえておきましょう。
Access Approval は Google のテクニカルサポート等がユーザーのコンテンツにアクセスする必要がある場合に、明示的な承認を経ないとアクセスできないようにすることができるサービスです。有効化すると、メールや Pub/Sub 通知で承認依頼が行われます。
Access Approval 承認者（roles/accessapproval.approver）ロールが付与されているアカウントのみが、承認を行うことができます。
- 参考 : Access Approval の概要
その他
Google Cloud の哲学
全体を通して、選択肢の絞り込みに迷った際は Google Cloud の哲学ともいうべき共通認識に基づいて判断しましょう。以下のようなキーワードを理解して判断に活かすことができれば、考え方を大きく間違えずに済みます。
「いや、そうは言っても、実務ではこうするべきだろう...」という気持ちをこらえて、クラウドの哲学に沿った回答を選ぶことが重要です。
- 可能な限りフルマネージドサービスを使う
- 責任共有モデル
- 最小権限の原則
- 組織全体でガバナンスを発揮する
- 権限の分譲
- ステートレスなアプリケーションとイミュータブルなインフラ
- 自動化によるトイルの削減
- スケーラブル、高可用性、堅牢性
- モニタリングと自動的な通知
受験環境
受験環境に関する当社メンバーの実体験が以下の記事で紹介されていますので、参考にしてください。
杉村 勇馬 (記事一覧)
執行役員 CTO / クラウドソリューション部 部長
元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。
Follow @y_sugi_it