模擬問題集一覧

GCP-ACE 模擬問題集(練習問題)

Associate Cloud Engineer 合格に向けた本番形式の模擬問題集。すべての問題に詳しい解説と、ドメイン別の弱点分析つき。

4 練習テスト 200 問 合格ライン 70% 各 120 分

この模擬問題集で身につくこと

  • 本番と同じ形式・難易度の問題で実力を確認
  • 制限時間つきの試験モードで時間配分を体得
  • 演習モードで1問ずつ解説を読みながら学習
  • すべての問題に正解の根拠つきの詳しい解説
  • ドメイン別スコアで弱点分野をひと目で把握
  • 完了後も何度でも復習して本番前に仕上げ

練習テストの内容

4 テスト · 全 200 問
1
模擬問題集①先頭 15 問 無料
50 問 120 分 合格 70%
2
模擬問題集② プラン限定
50 問 120 分 合格 70%
3
模擬問題集③ プラン限定
50 問 120 分 合格 70%
4
模擬問題集④ プラン限定
50 問 120 分 合格 70%

説明

GCP-ACE(Associate Cloud Engineer)の合格に向けた、本番形式の模擬問題集です。全 200 問を4 回の練習テストに分割し、 試験モード/演習モードで受験できます。各問題には正解の根拠と誤答の理由を記した詳しい解説が付き、受験後はドメイン別のスコアで弱点を把握できます。 各試験は先頭の問題から無料でお試しいただけます。

月額 ¥980 で全 200 問+全解説が受け放題

模試プラン(¥980/月)なら、ロックされた練習テストと詳しい解説、ドメイン別の弱点分析がすべて使い放題。本番に向けて実力を仕上げましょう。

GCP-ACE の出題範囲(カバーしている分野)

全 200 問を、本番の試験ガイドに沿った次の分野から出題しています。 受験後はドメイン別の正答率が表示され、弱点が特定できます。 難易度・学習時間・合格までの進め方はGCP-ACE の学習ガイドにまとめています。

GCP-ACE の無料練習問題(15 問・解説つき)

会員登録なしで、全 200 問のうち 15 問を正解と解説つきでご覧いただけます。 問題をクリックすると選択肢と解説が開きます。

問題 1複数のチームメンバーが競合することなく同時に Terraform 構成を扱えるようにし、かつ機密性の高い値がローカルマシ…クラウド ソリューションの計画と実装
問題
あなたは Terraform を使用して Google Cloud インフラストラクチャを管理しています。Terraform の構成ファイルは Git リポジトリに保存されています。複数のチームメンバーが競合することなく同時に Terraform 構成を扱えるようにし、かつ機密性の高い値がローカルマシンに永続化されないようにするソリューションを実装する必要があります。どうすればよいですか。

選択肢と解説

  • 1
    Terraform でローカル バックエンドを構成し、踏み台サーバー上の共有アカウントを使用してすべての変更をデプロイする。
  • ✓
    Terraform で Cloud Storage バックエンドを構成する。
  • 3
    Terraform でローカル バックエンドを構成し、状態ファイルを Git リポジトリに保存する。
  • 4
    Terraform でローカル バックエンドを構成し、変更のたびに Terraform の状態ファイルをチームメンバーと手動で共有する。

解説

【正解】B

【0からの解説】
①前提知識
Terraform は、管理しているリソースの実際の状態を「状態ファイル(terraform.tfstate)」に記録し、構成ファイルとの差分から変更を計画・適用します。状態ファイルにはリソースの属性がそのまま記録されるため、パスワードなどの機密性の高い値が平文で含まれることがあります。状態の保存場所を決めるのが「バックエンド」で、既定のローカル バックエンドでは作業者の PC に状態ファイルが保存されます。
Google Cloud では、gcs バックエンド(Cloud Storage バックエンド)で状態ファイルを Cloud Storage バケットに保存することが推奨されています。gcs バックエンドは状態のロック(同時に 2 人が apply して状態が壊れるのを防ぐ)に対応し、バケットの IAM でアクセスを制御でき、オブジェクトのバージョニングで過去の状態に戻すこともできます。

②要件の整理
・複数人が同時に作業しても競合しない(状態の共有とロック)
・機密性の高い値をローカルマシンに永続化しない

③正解の理由
Cloud Storage バックエンドを使うと、状態ファイルはチーム全員が共有する 1 か所(バケット)に保存され、実行中はロックがかかるため同時実行による破損を防げます。状態ファイルはローカルのディスクに保存されないため、機密値が各自のマシンに残りません。Google Cloud の Terraform ベスト プラクティスでも、リモート状態として Cloud Storage を使うこと、状態ファイルを Git にコミットしないことが推奨されています。

【誤りの選択肢】
A:踏み台サーバーの共有アカウントで実行すると、誰が変更したかの追跡(監査)ができなくなり、セキュリティのベスト プラクティスに反します。状態ファイルは踏み台サーバーのローカル ディスクに永続化されたままで、同時に作業した場合のロックもありません。
C:状態ファイルを Git リポジトリに保存すると、機密値がリポジトリの履歴に残り、各自がクローンしたローカルマシンにも複製されます。Git はロックの仕組みを提供しないため、同時実行の競合も防げません。Google のベスト プラクティスでも状態ファイルを Git にコミットしないことが推奨されています。
D:手動で状態ファイルを受け渡す方法は、最新版の取り違えや同時変更による状態の不整合を防げず、機密値も各メンバーのローカルマシンに保存されます。運用負荷も大きく、要件のいずれも満たしません。

【参考】
Terraform の状態を Cloud Storage バケットに保存する
Terraform の操作に関するベスト プラクティス
この問題のページを開く →
問題 290 日の期間が経過した直後に、これらのオブジェクトを長期保持に適した最も低コストのストレージ クラスへ自動的に移行する…クラウド ソリューションの運用の確保
問題
あなたは、Multi-Regional ストレージ クラスを使用する Cloud Storage バケットに保存されている会社のアーカイブ記録を管理しています。これらのオブジェクトは 90 日を過ぎるとほとんどアクセスされませんが、規制コンプライアンス要件を満たすために無期限に保持する必要があります。90 日の期間が経過した直後に、これらのオブジェクトを長期保持に適した最も低コストのストレージ クラスへ自動的に移行する、費用対効果の高いプロセスを実装する必要があります。どうすればよいですか。

選択肢と解説

  • 1
    バケットで Object Versioning を有効にし、daysSinceNoncurrentTime 条件を 90 日に設定して、非現行バージョンを Archive ストレージに移行する Object Lifecycle Management ルールを作成する。
  • ✓
    バケットに、age 条件を 90 日に指定し、SetStorageClass アクションを使用してオブジェクトを Archive ストレージに移行する Object Lifecycle Management ルールを作成する。
  • 3
    Cloud Storage API を使用して、90 日より古いすべてのオブジェクトのストレージ クラスを Archive ストレージに変更する、夜間にスケジュール実行される Cloud Run function を作成する。
  • 4
    バケットに、createdBefore 条件を 90 日前に設定し、Delete アクションを使用してオブジェクトを削除する Object Lifecycle Management ルールを作成する。

解説

【正解】B

【0からの解説】
①前提知識
Cloud Storage には、アクセス頻度に応じたストレージ クラスがあります。Standard(頻繁にアクセス)、Nearline(月 1 回程度・最小保存期間 30 日)、Coldline(四半期に 1 回程度・90 日)、Archive(年 1 回未満・365 日)の順に保存料金が安くなり、その代わりにデータ取得料金と最小保存期間が大きくなります。問題文の Multi-Regional(マルチリージョナル)は旧来の(レガシーの)ストレージ クラス名です。現行の表記では「マルチリージョン(またはデュアルリージョン)のロケーションに置いた Standard ストレージ」に相当し、Google も新規には Standard の使用を推奨しています。つまり「クラス(Standard/Nearline/Coldline/Archive)」と「ロケーション(リージョン/デュアルリージョン/マルチリージョン)」は別々に選ぶ設定であり、本問の状況は「マルチリージョンの Standard で保存している記録を Archive に移したい」と読み替えて構いません。なお、ストレージ クラスを変えてもバケットのロケーション(マルチリージョン)はそのままです。
オブジェクトのライフサイクル管理(Object Lifecycle Management)は、バケットに「条件(condition)」と「アクション(action)」の組み合わせからなるルールを設定しておくと、条件に合致したオブジェクトに対して Cloud Storage が自動でアクションを実行する機能です。代表的な条件は age(オブジェクトの作成からの経過日数)、createdBefore(指定日より前に作成)、daysSinceNoncurrentTime(非現行バージョンになってからの日数)など、アクションは Delete(削除)、SetStorageClass(ストレージ クラスの変更)、AbortIncompleteMultipartUpload です。

②要件と制約語の整理
・作成から 90 日経過後はほぼアクセスされない
・規制のため無期限に保持する(削除してはいけない)
・「長期保持に適した最も低コストのクラス」= Archive
・「自動的に」「費用対効果が高い」=コードや手作業を増やさない

③正解の理由
age = 90 の条件と SetStorageClass(storageClass: ARCHIVE)のアクションを持つライフサイクル ルールを設定すると、作成から 90 日経過したオブジェクトが Cloud Storage 側で自動的に Archive に変更されます。追加のコンピューティング料金も運用コードも不要で、Multi-Regional から Archive への変更もライフサイクル管理で許可されている遷移です。ライフサイクル管理によるクラス変更はオブジェクトを書き換えないため、移行のための再書き込み料金もかかりません(クラス A オペレーションとして課金されます)。なお、ライフサイクル アクションは条件を満たした後、非同期に実行されるため、通常は 24 時間以内などの多少の遅延があります。

【誤りの選択肢】
A:daysSinceNoncurrentTime は「上書きや削除で非現行(過去)バージョンになってからの日数」を表す条件です。現行(ライブ)のアーカイブ記録そのものは対象にならないため、90 日を過ぎた記録が Multi-Regional のまま残り続け、要件を満たしません。さらに Object Versioning を有効にすると不要な旧バージョンの保存料金が増えます。
C:Cloud Run function(旧 Cloud Functions)と Cloud Scheduler で自前の処理を作れば動作はしますが、コードの作成・保守・エラー処理が必要で、関数の実行料金も追加されます。同じことは組み込みのライフサイクル管理で設定だけで実現できるため、費用対効果と運用負荷の両面で劣ります。また夜間バッチでは「90 日経過直後」の変更にもなりません。
D:Delete アクションはオブジェクトを削除してしまうため、「無期限に保持する」という規制要件に反します。また createdBefore は固定日付を指定する条件で、「常に作成から 90 日」という相対的な期間を表すことはできません。

【参考】
オブジェクトのライフサイクル管理 | Cloud Storage
ストレージ クラス | Cloud Storage
この問題のページを開く →
問題 3新しいプロセスについて伝えるために、これらのプロジェクトの作成者を特定する必要があります。クラウド ソリューション環境の設定
問題
あなたは会社の Google Cloud ガバナンスを担当しており、最近、Google Cloud プロジェクトをプロビジョニングするための新しい自動化プロセスを導入しました。この新しいプロセスの導入前に手動で作成されたプロジェクトがいくつか見つかりました。新しいプロセスについて伝えるために、これらのプロジェクトの作成者を特定する必要があります。どうすればよいですか。

選択肢と解説

  • 1
    プロジェクトに付与されている creator ラベルの値を確認して、プロジェクトの作成者を見つける。
  • 2
    Resource Manager を使用して、フォルダとプロジェクトの階層から担当部署を特定する。
  • 3
    プロジェクトにリンクされている Cloud Billing アカウントを確認し、その請求先アカウントのオーナーに連絡する。
  • ✓
    Google Cloud コンソールの IAM ページを使用して、オーナー(Owner)ロールを持つユーザーを特定する。

解説

【正解】D

【0からの解説】
①前提知識
Google Cloud のプロジェクトは、組織 → フォルダ → プロジェクトというリソース階層の中に作成されます。プロジェクトの作成には resourcemanager.projects.create 権限(通常はプロジェクト作成者 roles/resourcemanager.projectCreator ロール)が必要です。プロジェクト作成者ロールの説明にあるとおり、ユーザーがプロジェクトを作成すると、そのユーザーには新しいプロジェクトのオーナー(roles/owner)ロールが自動的に付与されます。つまり、手動で作られたプロジェクトでは、特に誰かが後から変更していない限り、作成したユーザーがオーナーとして IAM ポリシーに残っています。

②要件の整理
・手動で作成されたプロジェクトの「作成者(人)」を特定したい
・目的は本人に新しいプロセスを周知すること

③正解の理由
コンソールの [IAM] ページ(または gcloud projects get-iam-policy)でオーナー ロールを持つプリンシパルを確認すれば、プロジェクトを作成したユーザーを最も手軽に特定できます。補足として、厳密な作成者の記録は Cloud Audit Logs の管理アクティビティ監査ログ(CreateProject オペレーションの principalEmail)に残ります。オーナーが後から追加・変更されている可能性がある場合は、監査ログで裏付けを取るのが確実です。ただし、この問題の選択肢の中では D が作成者の特定に直接結びつく唯一の方法です。

【誤りの選択肢】
A:Google Cloud はプロジェクト作成時に creator のようなラベルを自動で付けません。ラベルはユーザーや自動化ツールが任意に付けるキーと値であり、手動で作られたプロジェクトには通常存在しないため、作成者の特定には使えません。
B:フォルダとプロジェクトの階層から分かるのは、プロジェクトがどのフォルダ(部署など)に属しているかまでで、個々の作成者は分かりません。また手動作成のプロジェクトが組織の想定どおりのフォルダに置かれているとも限りません。
C:請求先アカウントのオーナー(請求先アカウント管理者)は、課金を管理する人であって、プロジェクトを作成した人とは限りません。複数のプロジェクトが同じ請求先アカウントを共有していることも多く、作成者の特定にはなりません。

【参考】
プロジェクトを作成する | Resource Manager
ロールと権限 | Identity and Access Management (IAM)
Resource Manager の監査ロギング
この問題のページを開く →
問題 4チームメンバーに必要最小限の権限を付与する必要があります。アクセスとセキュリティの構成
問題
あなたは、組織の Google Cloud プロジェクトの IAM ポリシーを管理しています。新しい運用チームには、基本的なトラブルシューティングのために、このプロジェクト内の既存の Compute Engine VM インスタンスを起動、停止、リセットする機能が必要です。厳格なセキュリティ要件のため、運用チームがインスタンスを削除したり、ネットワークや構成の設定を変更したりすることは防がなければなりません。チームメンバーに必要最小限の権限を付与する必要があります。どうすればよいですか。

選択肢と解説

  • 1
    運用チームに roles/writer IAM ロールを付与し、ロールに resource.type =='compute.googleapis.com/Instance' 条件を追加する。
  • 2
    運用チームに、プロジェクトに対する事前定義ロール roles/compute.instanceAdmin.v1 を付与する。compute.instances.delete 権限を除外する IAM 条件を適用する。
  • ✓
    compute.instances.start、compute.instances.stop、compute.instances.reset 権限のみを含むカスタム IAM ロールを作成する。このロールをプロジェクトに対して運用チームに割り当てる。
  • 4
    インスタンスを表示できるように、運用チームに事前定義ロール roles/compute.viewer を付与する。起動、停止、リセットなどの Google Cloud コンソールの基本操作を使用するようチームに指示する。

解説

【正解】C

【0からの解説】
①前提知識
IAM のロールには、基本ロール(オーナー・編集者・閲覧者)、事前定義ロール(サービスごとに Google が用意したもの。例: roles/compute.instanceAdmin.v1)、カスタムロール(必要な権限だけを自分で選んで作るもの)の 3 種類があります。ロールは「権限(permission)」の集合で、Compute Engine の VM 操作では compute.instances.start(起動)、compute.instances.stop(停止)、compute.instances.reset(リセット)、compute.instances.delete(削除)、compute.instances.setMetadata(メタデータ変更)などの個別の権限があります。事前定義ロールに必要な権限の組み合わせがない場合は、カスタムロールで最小権限を実現するのが Google の推奨です。

②要件と制約語の整理
・既存 VM の起動・停止・リセットだけをできるようにする
・削除、ネットワーク・構成の変更は禁止
・「必要最小限の権限」=最小権限の原則

③正解の理由
compute.instances.start / stop / reset のみを含むカスタムロールを作成してプロジェクトで付与すれば、許可したい 3 つの操作だけが可能になり、削除や設定変更に必要な権限は一切含まれません。最小権限を最も正確に実現できます。補足として、コンソールでインスタンスの一覧を見て操作するには compute.instances.list や compute.instances.get などの読み取り権限も合わせて含めるのが実務上一般的ですが、その場合も削除・変更系の権限は含めません。

【誤りの選択肢】
A:roles/writer という Compute Engine 用の事前定義ロールは存在しません。仮に書き込み系の広いロールを付けて resource.type 条件で VM に限定しても、条件で絞れるのは「どのリソースに対して」であり、「どの操作を」許すかは絞れません。VM の削除や設定変更もできてしまい、要件に反します。
B:roles/compute.instanceAdmin.v1 は VM の作成・削除・メタデータやディスクの変更など幅広い権限を含みます。IAM 条件(IAM Conditions)はリソース名・リソースタイプ・日時などの属性に基づいてロール付与全体の有効・無効を決める仕組みで、ロールに含まれる個別の権限を除外する機能はありません。そのため delete を外すことはできず、ネットワークや構成の変更も防げません(権限単位で禁止したい場合は IAM 拒否ポリシーという別の仕組みになりますが、それでも過剰な付与であることに変わりはありません)。
D:roles/compute.viewer は読み取り専用のロールで、start / stop / reset の権限を含みません。コンソールで操作を指示しても、権限不足で起動・停止・リセットは失敗します。

【参考】
カスタムロールの作成と管理 | Identity and Access Management (IAM)
Compute Engine IAM のロールと権限
IAM Conditions の概要 | Identity and Access Management (IAM)
この問題のページを開く →
問題 5あなたは、管理・運用の手間を最小限に抑えながらグローバルにスケールできるリレーショナル データベースを選択する必要があり…クラウド ソリューションの計画と実装
問題
あなたの会社は、オンプレミスのリレーショナル データベースから Google Cloud にデータを移行したいと考えています。現在のデータベースはユーザー数の増加に対してスケールできなくなっており、今後ユーザー数が急速に増加すると予想されています。あなたは、管理・運用の手間を最小限に抑えながらグローバルにスケールできるリレーショナル データベースを選択する必要があります。また、Google が推奨するプラクティスに従いたいと考えています。どうすればよいですか。

選択肢と解説

  • 1
    Cloud SQL を使用する。
  • ✓
    Spanner を使用する。
  • 3
    Firestore を使用する。
  • 4
    BigQuery を使用する。

解説

【正解】B

【0からの解説】
①前提知識
・Spanner: Google が提供するフルマネージドのリレーショナル データベースで、SQL と強整合性のトランザクション(ACID)を備えつつ、ノード(コンピューティング容量)を追加するだけで水平方向にほぼ無制限にスケールします。リージョン / デュアルリージョン / マルチリージョン構成を選べ、複数リージョンにまたがる同期レプリケーションで高可用性(マルチリージョンで 99.999%)とグローバルな配置を実現できます。
・Cloud SQL: MySQL / PostgreSQL / SQL Server のフルマネージド版ですが、基本は単一リージョンの 1 台のプライマリで書き込みを処理する構成で、書き込みのスケールは垂直方向(マシンサイズ)に限られます。
・Firestore: NoSQL のドキュメント データベース。
・BigQuery: 分析用のデータ ウェアハウス(OLAP)。

②要件の整理
・リレーショナル データベースであること
・ユーザー数の急増に耐え「グローバルにスケール」できること
・管理・運用の手間を最小化(フルマネージド)

③正解 B の理由
Spanner はリレーショナル モデルと SQL を維持したまま、グローバルな水平スケーリングと高可用性をフルマネージドで提供します。シャーディングやレプリケーションの管理は Spanner が自動で行うため、運用負荷も最小です。3 つの条件をすべて満たすのは Spanner だけです。

【誤りの選択肢】
A:Cloud SQL はリレーショナルかつフルマネージドですが、書き込みは単一プライマリで処理され、スケールは主に垂直方向(リードレプリカで読み取りのみ水平拡張)です。グローバルに書き込みを含めてスケールさせる用途には向かず、「現在の DB がスケールできない」という課題を根本的に解決できません。
C:Firestore はグローバルにスケールするフルマネージド DB ですが、NoSQL のドキュメント データベースであり、「リレーショナル データベース」という要件を満たしません。スキーマやクエリの作り直しも必要になります。
D:BigQuery は大量データの分析向けデータ ウェアハウスで、ユーザーのアプリケーションからの大量の小さなトランザクション(OLTP)を処理する運用データベースとしては設計されていません。

【参考】
リージョン、デュアルリージョン、マルチリージョンの構成 | Spanner
レプリケーション | Spanner
この問題のページを開く →
問題 6最初に何をすべきですか。クラウド ソリューションの運用の確保
問題
あなたは、複雑なアプリケーション障害のトラブルシューティングを行っています。Cloud Logging で、個人を特定できる情報(PII)を含まない、見覚えのない不可解なエラー メッセージがいくつか見つかりました。これらのログの意味を理解し、どのような対応を取るべきかをできるだけ早く判断する必要があります。最初に何をすべきですか。

選択肢と解説

  • 1
    エラー メッセージを手動でコピーし、公開フォーラムやドキュメントで検索する。
  • 2
    Cloud Profiler を使用して、エラー発生時のアプリケーションのパフォーマンスを分析する。
  • ✓
    ログ エクスプローラの「Explain this log entry」機能を使用し、Gemini との会話を開始する。
  • 4
    アプリケーションのソースコードを検索して、エラーの原因を特定する。

解説

【正解】C

【0からの解説】
①前提知識
Cloud Logging のログ エクスプローラには、Gemini Cloud Assist と連携してログエントリの内容を要約・説明する機能があります。ログエントリのメニューから実行すると、そのログエントリのテキストが Gemini Cloud Assist に送られ、エラーの意味や考えられる原因、次に取るべき対処を Cloud Assist パネルに表示し、追加の質問で会話を続けられます。この機能は当初「Explain this log entry(このログエントリについて説明)」という名前で提供され、現行のドキュメントでは「Investigate log(ログを調査)」ボタンとして説明されています。利用には、プロジェクトとユーザーで Gemini Cloud Assist を設定しておく必要があります。

②要件と制約語の整理
・見覚えのない不可解なエラー メッセージの「意味」を理解したい
・対応方針を「できるだけ早く」決めたい、まず「最初に」やること
・ログには PII が含まれない(Gemini に送ってもデータ保護上の懸念が小さい)

③正解の理由
ログ エクスプローラ上でワンクリックで Gemini にログの説明を求め、そのまま会話で深掘りできるため、手作業の検索よりも速く意味と対処の方向性を得られます。PII を含まないという条件は、ログのテキストを Gemini Cloud Assist に送ることへの懸念がないことを示しており、この機能を使う前提が整っています。なお Gemini の回答はもっともらしくても誤っている可能性があるため、提示された対処は検証してから実施します。

【誤りの選択肢】
A:フォーラムやドキュメントを手作業で検索する方法は、不可解なメッセージほど該当情報が見つからず時間がかかります。「できるだけ早く」という要件に対して、統合された Gemini の説明機能より劣ります。
B:Cloud Profiler は CPU やメモリなどの使用状況を関数単位で継続的に分析するツールで、性能のボトルネック調査には有用ですが、個々のエラー メッセージの意味を説明するものではありません。最初の一手としては目的に合いません。
D:ソースコードの調査は根本原因の特定に最終的に必要になることはありますが、メッセージの意味が分からない段階で大規模なコードを検索するのは時間がかかり、「最初に、できるだけ早く」という要件に合いません。まず Gemini で意味と当たりを付けてから、必要に応じてコードを調べるのが効率的です。

【参考】
Gemini アシスタンスを使用してログエントリを要約する | Cloud Logging
ログ エクスプローラを使用してログを表示する | Cloud Logging
この問題のページを開く →
問題 7各スタートアップが、自社の Google Cloud 使用量について個別の月次請求書を受け取れるようにする必要があります…クラウド ソリューション環境の設定
問題
あなたは、最近 3 つの小規模なスタートアップを買収した大企業で働いています。スタートアップのすべての Google Cloud リソースは、単一の Google Cloud 組織の下で一元管理する必要があります。ただし、各スタートアップには独自の予算と財務報告の体制があります。各スタートアップが、自社の Google Cloud 使用量について個別の月次請求書を受け取れるようにする必要があります。どうすればよいですか。

選択肢と解説

  • 1
    スタートアップごとにフォルダを持つ Google Cloud 組織を作成する。単一の Cloud Billing アカウントを共有し、詳細な課金データのエクスポートを使用して費用を配分する。
  • ✓
    スタートアップごとにフォルダを持つ Google Cloud 組織を作成する。各スタートアップが独自の Cloud Billing アカウントを持つように構成する。
  • 3
    スタートアップごとに Google Cloud 組織を作成する。各スタートアップが独自の Cloud Billing アカウントを持つように構成する。
  • 4
    スタートアップごとに Google Cloud 組織を作成する。単一の Cloud Billing アカウントを共有し、詳細な課金データのエクスポートを使用して費用を配分する。

解説

【正解】B

【0からの解説】
①前提知識
Google Cloud のリソース階層は「組織 → フォルダ → プロジェクト」です。組織はドメインに対応する最上位のノードで、組織のポリシーや IAM を上から一括で継承させて一元管理できます。フォルダは部署や子会社などの単位でプロジェクトをまとめるためのノードです。
一方、Cloud Billing アカウント(請求先アカウント)は「誰がいくら支払うか」を決める支払いの単位で、請求書(または明細書)は請求先アカウントごとに発行されます。リソース階層と請求先アカウントは独立しており、1 つの組織の中に複数の請求先アカウントを持ち、プロジェクトごとにどの請求先アカウントにリンクするかを選べます。

②要件の整理
・すべてのリソースを「単一の組織」で一元管理する
・各スタートアップが「個別の月次請求書」を受け取る

③正解の理由
1 つの組織の下にスタートアップごとのフォルダを作り、各スタートアップ用の Cloud Billing アカウントを用意して、そのスタートアップのプロジェクトをそれぞれの請求先アカウントにリンクします。これで組織のポリシーや IAM は一元管理しつつ、請求書は請求先アカウント(=スタートアップ)ごとに個別に発行されます。

【誤りの選択肢】
A:単一の請求先アカウントを共有すると請求書は 1 通にまとまります。課金データのエクスポートで費用を配分(チャージバック)することはできますが、それは社内での按分であり、「各スタートアップが個別の請求書を受け取る」という要件を満たしません。
C:スタートアップごとに別の組織を作ると、請求書は個別になりますが、「単一の組織の下で一元管理する」という要件に反します。組織が分かれると組織のポリシーや IAM を共通に適用できず、管理も分散します。
D:組織を分けるため一元管理の要件に反し、さらに請求先アカウントを共有するため個別の請求書という要件も満たしません。両方の要件を満たさない選択肢です。

【参考】
Cloud Billing リソースの編成とアクセス管理
リソース階層について | Resource Manager
Cloud Billing の概要
この問題のページを開く →
問題 8作成されたサービス アカウント キーを監査し、作成から 90 日を超えたキーを特定する必要があります。アクセスとセキュリティの構成
問題
あなたの組織では、オンプレミスや他のクラウドでホストされ、Google Cloud API を使用するさまざまなアプリケーション向けに、数百のサービス アカウントが作成されています。作成されたサービス アカウント キーを監査し、作成から 90 日を超えたキーを特定する必要があります。どうすればよいですか。

選択肢と解説

  • 1
    gcloud asset search-all-resources --scope="organizations/[ORG_ID]" --query="createTime < [DATE_90_DAYS_AGO]" --asset-types="apikeys.googleapis.com/Key" --order-by="createTime" コマンドを実行する。
  • 2
    gcloud iam service-accounts list --filter="createTime < [DATE_90_DAYS_AGO]" コマンドを実行する。
  • 3
    gcloud tans keys list --filter="createTime < [DATE_90_DAYS_AGO]" コマンドを実行する。
  • ✓
    gcloud asset search-all-resources --scope="organizations/[ORG_ID]" --query="createTime < [DATE_90_DAYS_AGO]" --asset-types="iam.googleapis.com/ServiceAccountKey" --order-by="createTime" コマンドを実行する。

解説

【正解】D

【0からの解説】
①前提知識
サービス アカウント キーは、サービス アカウントとして Google Cloud API に認証するための長期間有効な認証情報です。オンプレミスや他のクラウドのアプリケーションで使われることが多く、漏えい時のリスクが高いため、定期的な監査とローテーション(一定期間ごとの作り直し)が推奨されています。
Cloud Asset Inventory は、組織・フォルダ・プロジェクト全体の Google Cloud リソースのメタデータを横断的に検索・一覧表示できるサービスです。gcloud asset search-all-resources コマンドは、--scope で検索範囲(例: organizations/ORG_ID)、--asset-types でアセットタイプ、--query で createTime などの条件、--order-by で並べ替えを指定できます。サービス アカウント キーのアセットタイプは iam.googleapis.com/ServiceAccountKey です。

②要件の整理
・数百のサービス アカウントにまたがる「サービス アカウント キー」を監査する
・作成から 90 日を超えたキーを特定する

③正解の理由
組織スコープで iam.googleapis.com/ServiceAccountKey を対象に createTime < 90 日前の日付で検索すれば、組織内のすべてのプロジェクトのサービス アカウント キーのうち、作成から 90 日を超えたものを 1 回のコマンドで抽出し、作成日時順に並べられます。サービス アカウントごとにコマンドを繰り返す必要がなく、数百のアカウントでも効率的に監査できます。

【誤りの選択肢】
A:apikeys.googleapis.com/Key は「API キー」(API Keys API で作成する、主に公開 API の呼び出しに使う文字列キー)のアセットタイプです。サービス アカウント キーとは別のものなので、要件のキーは検索されません。
B:gcloud iam service-accounts list はサービス アカウント自体の一覧を表示するコマンドで、キーの一覧や作成日時は対象外です。古いサービス アカウントが分かっても、そのアカウントのキーがいつ作られたかは分かりません。
C:gcloud tans keys というコマンドは存在しません(原文のまま)。サービス アカウント キーを一覧表示する正しいコマンドは gcloud iam service-accounts keys list ですが、これは --iam-account で 1 つのサービス アカウントを指定して実行する必要があり、数百のアカウントに対して繰り返すのは非効率です。

【参考】
リソースを検索 | Cloud Asset Inventory
アセットタイプ | Cloud Asset Inventory
サービス アカウント キーを管理するためのベスト プラクティス | Identity and Access Management (IAM)
この問題のページを開く →
問題 9また、ソリューションはストレージ レイヤを同期的にレプリケートし、最適化できる必要があります。クラウド ソリューションの計画と実装
問題
あなたの会社は、オンプレミスの PostgreSQL データベースを Google Cloud に移行する予定です。ワークロードの要求は厳しく、高速なトランザクション処理と分析処理の性能が必要です。あなたは Google Cloud 上のフルマネージドのデータベース サービスを選択する必要があります。また、ソリューションはストレージ レイヤを同期的にレプリケートし、最適化できる必要があります。どうすればよいですか。

選択肢と解説

  • 1
    Database Migration Service を使用して、データベースを Cloud SQL for PostgreSQL に移行する。
  • 2
    Compute Engine インスタンスにインストールした psql クライアントを使用する。Cloud SQL インスタンスに接続して、データベースの移行を実行する。
  • ✓
    Database Migration Service を使用して、データベースを AlloyDB for PostgreSQL に移行する。
  • 4
    Compute Engine インスタンスを作成する。そのインスタンスに PostgreSQL をインストールして構成し、データベースを移行する。

解説

【正解】C

【0からの解説】
①前提知識
・AlloyDB for PostgreSQL: PostgreSQL 互換のフルマネージド データベースです。コンピューティングとストレージを分離し、複数のゾーンにまたがってデータを永続化するクラウドネイティブな分散ストレージ エンジンを備えています(書き込みはストレージ層で複数ゾーンに同期的に複製され、ストレージは自動で拡張されます)。さらにカラムナ エンジンにより、分析クエリをメモリ上の列指向データで高速化でき、トランザクション(OLTP)と分析(OLAP)の両方で高い性能を発揮します。
・Database Migration Service(DMS): オンプレミスや他クラウドのデータベースから、Cloud SQL や AlloyDB へ、継続的なレプリケーションによって最小限のダウンタイムで移行できるマネージドの移行サービスです。
・Cloud SQL for PostgreSQL: 標準的な PostgreSQL のフルマネージド版。高可用性構成ではリージョン永続ディスクによる同期レプリケーションを行いますが、AlloyDB のような最適化された分散ストレージ層やカラムナ エンジンは持ちません。

②要件の整理
・高速なトランザクション処理と分析処理
・フルマネージド
・ストレージ レイヤを同期的にレプリケートし、最適化できる

③正解 C の理由
AlloyDB は、最適化された分散ストレージ層(ゾーン間の同期レプリケーション)とカラムナ エンジンによる分析の高速化を備え、要求の厳しい OLTP と分析を両立するフルマネージド サービスです。移行には PostgreSQL からの移行をサポートする DMS を使うのが Google の推奨手段です。

【誤りの選択肢】
A:DMS での移行手段は適切ですが、Cloud SQL for PostgreSQL は標準 PostgreSQL ベースで、分析処理を高速化するカラムナ エンジンや最適化された分散ストレージ層を持たないため、「高速なトランザクションと分析」「ストレージ レイヤの最適化」という要件で AlloyDB に劣ります。
B:psql クライアントで手動移行する方法は、ダンプとリストアなどの手作業が多く、継続レプリケーションによる低ダウンタイム移行もできません。移行先も Cloud SQL であり、A と同じく性能・ストレージ要件を満たしません。
D:Compute Engine 上の自前の PostgreSQL はフルマネージドではなく、パッチ適用・バックアップ・レプリケーション・高可用性をすべて自分で構築・運用する必要があります。「フルマネージド」という要件に反します。

【参考】
AlloyDB の概要 | AlloyDB for PostgreSQL
この問題のページを開く →
問題 10管理のオーバーヘッドを最小限に抑えてドメイン名を解決する必要があります。クラウド ソリューションの運用の確保
問題
あなたは、内部アプリケーション ロードバランサの背後に新しい内部ウェブ アプリケーションをデプロイしています。このアプリケーションは、ドメイン名 internal.altostrat.com を使用して、VPC ネットワークとオンプレミス ネットワークの両方からアクセスできる必要があります。この名前は公共のインターネットから名前解決できてはなりません。オンプレミス ネットワークは Cloud VPN を使用して VPC ネットワークに接続されており、受信サーバー ポリシーを構成済みです。管理のオーバーヘッドを最小限に抑えてドメイン名を解決する必要があります。どうすればよいですか。

選択肢と解説

  • 1
    オンプレミスの DNS サーバーに、ロードバランサの IP アドレスを指す A レコードを作成する。
  • ✓
    Cloud DNS の限定公開マネージド ゾーンを作成し、VPC ネットワークにそのゾーンの使用を承認して、ロードバランサの IP アドレスを指す A レコードを追加する。
  • 3
    Cloud DNS の一般公開マネージド ゾーンを作成し、ロードバランサの IP アドレスを指す A レコードを追加する。
  • 4
    各従業員のワークステーションでローカルの HOSTS ファイルを編集し、ドメイン名をロードバランサの IP アドレスにマッピングする。

解説

【正解】B

【0からの解説】
①前提知識
Cloud DNS のマネージド ゾーンには、インターネット全体から名前解決できる「一般公開ゾーン」と、承認した VPC ネットワークの中からだけ名前解決できる「限定公開ゾーン(private zone)」があります。
DNS サーバー ポリシーで受信転送(inbound server policy)を有効にすると、VPC のサブネット内に Cloud DNS の受信用エントリ ポイント(内部 IP アドレス)が作られます。オンプレミスの DNS サーバーからこのアドレスに問い合わせを転送すると、Cloud VPN や Cloud Interconnect 経由で、その VPC に承認された限定公開ゾーンのレコードをオンプレミスからも解決できます。

②要件と制約語の整理
・VPC とオンプレミスの両方から internal.altostrat.com を解決する
・公共のインターネットからは解決できない
・Cloud VPN と受信サーバー ポリシーは構成済み
・「管理のオーバーヘッドを最小限に」

③正解の理由
限定公開ゾーンに A レコードを 1 つ作って VPC ネットワークを承認すれば、VPC 内の VM などはそのまま名前解決でき、インターネットには公開されません。オンプレミスからは、構成済みの受信サーバー ポリシーのエントリ ポイントに問い合わせを転送することで同じレコードを解決できます。レコードの管理場所が Cloud DNS の 1 か所に集約されるため、管理のオーバーヘッドが最小です。

【誤りの選択肢】
A:オンプレミスの DNS サーバーに A レコードを作るとオンプレミスからは解決できますが、VPC 内のリソースは既定で Cloud DNS(メタデータ サーバー)を使うため解決できません。VPC 側から使うにはさらに Cloud DNS の転送ゾーン(送信転送)を構成する必要があり、受信サーバー ポリシーを構成済みであることも活かせず、管理が増えます。
C:一般公開ゾーンのレコードは公共のインターネットから名前解決できるため、「インターネットから解決できてはならない」という要件に反します(内部 IP アドレスが外部に知られることにもなります)。
D:各従業員の HOSTS ファイルを手作業で編集する方法は、端末数に比例して管理負荷が増え、IP アドレス変更のたびに全台の修正が必要です。VPC 内のリソースからの名前解決にも対応できず、管理のオーバーヘッド最小という要件に最も反します。

【参考】
DNS ゾーンの概要
DNS サーバーのポリシー
Cloud DNS のベスト プラクティス
この問題のページを開く →
問題 111. パブリック トラフィックを受けるフロントエンド サーバーで構成されるウェブ層 2. コアとなるアプリケーション ロ…クラウド ソリューションの計画と実装
問題
あなたは、安全に分離する必要がある Google Cloud プロジェクトに、1,000 個を超える IP アドレスを使用する大規模な多層アプリケーションをデプロイしようとしています。このアプリケーションは次の層で構成されています。 1. パブリック トラフィックを受けるフロントエンド サーバーで構成されるウェブ層 2. コアとなるアプリケーション ロジックを実行するサーバーで構成され、ウェブ層からのアクセスのみを必要とするアプリケーション層 3. データベース サーバーで構成され、アプリケーション層からのアクセスのみを必要とするデータベース層 あなたは、ネットワーク アーキテクチャのコスト、複雑さ、管理のオーバーヘッドを最小限に抑えたいと考えています。どうすればよいですか。

選択肢と解説

  • 1
    /24 の共有 VPC を作成し、層ごとに個別のサブネットを用意する。ネットワーク タグを参照するファイアウォール ルールを使用してトラフィックを制御する。
  • ✓
    3 つのサブネットを持つ /16 のカスタムモード VPC を 1 つ作成する。各層をそれぞれのサブネットに配置し、IP サブネットを参照するファイアウォール ルールを使用してトラフィックを制御する。
  • 3
    各層を個別の /16 のカスタムモード VPC にデプロイする。VPC ネットワーク ピアリングを使用して各カスタムモード VPC を安全に接続する。各 VPC でファイアウォール ルールを個別に管理する。
  • 4
    各層を /24 の VPC にデプロイし、ネットワーク タグを使用してインスタンスを識別する。きめ細かいネットワーク セグメンテーションのためにファイアウォール ルールを実装する。

解説

【正解】B

【0からの解説】
①前提知識
・VPC ネットワーク: Google Cloud の VPC はグローバルなリソースで、IP アドレス範囲はリージョンごとのサブネットに割り当てます(選択肢の「/16 の VPC」は、VPC 全体で計画するアドレス空間を指していると読みます)。カスタムモード VPC では、サブネットの範囲を自分で設計できます。
・CIDR のサイズ: /24 は 256 個(Google Cloud では各サブネットで 4 個が予約されるため使用可能は 252 個)、/16 は 65,536 個の IPv4 アドレスです。
・VPC ファイアウォール ルール: 送信元を IP 範囲(サブネットの CIDR)、ネットワーク タグ、サービス アカウントなどで指定して、上り / 下りの通信を許可・拒否できます。

②要件の整理
・1,000 個を超える IP アドレス → /24 では不足、/16 なら十分
・層の分離: ウェブ層 ← インターネット、アプリ層 ← ウェブ層のみ、DB 層 ← アプリ層のみ
・コスト、複雑さ、管理のオーバーヘッドを最小化

③正解 B の理由
1 つのカスタムモード VPC に層ごとのサブネットを作り、たとえば「アプリ層サブネットへの通信はウェブ層サブネットの CIDR からのみ許可」「DB 層サブネットへの通信はアプリ層サブネットの CIDR からのみ許可」といったファイアウォール ルールを書けば、層ごとの分離が実現できます。VPC が 1 つなのでピアリングや共有 VPC の設定が不要で、ルールも 1 か所で管理でき、十分なアドレス空間も確保できます。

【誤りの選択肢】
A:/24 では使えるアドレスが約 250 個しかなく、1,000 個を超える IP アドレスという要件を満たせません。また共有 VPC は複数プロジェクトでネットワークを共有するための仕組みで、単一プロジェクトのこのケースでは不要な複雑さを加えます。
C:層ごとに VPC を分けて VPC ネットワーク ピアリングで接続すると、ピアリングの構成とファイアウォール ルールを 3 つの VPC で個別に管理する必要があり、複雑さと管理オーバーヘッドが増えます(VPC ピアリングは推移的でない点にも注意が必要です)。同じ分離は 1 つの VPC 内のサブネットとファイアウォール ルールで実現できます。
D:/24 の VPC では各層あたり約 250 個のアドレスしか使えず、層の規模によってはアドレスが不足するおそれがあります。さらに層ごとに VPC を分けるなら相互接続(ピアリングなど)も必要になるのに、その手段が示されておらず、異なる VPC 間ではネットワーク タグを参照したファイアウォール ルールで通信を制御することもできません。

【参考】
サブネット | Virtual Private Cloud
VPC ファイアウォール ルール | Cloud Next Generation Firewall
この問題のページを開く →
問題 12クラウド ソリューションの運用の確保クラウド ソリューションの運用の確保
問題
あなたは Cloud Run にデプロイされたアプリケーションを管理しています。開発チームがアプリケーションの新しいバージョンをリリースしました。あなたはこの新しいバージョンをデプロイし、トラフィックをそこへ切り替えたいと考えています。新しいバージョンへのトラフィックが起動時間なしで処理されるように、トラフィックの流れを調整する前に、受信トラフィック用のアイドル状態のインスタンスが 2 つ利用可能になっていることを確認したいと考えています。また、管理のオーバーヘッドを最小限に抑えたいと考えています。どうすればよいですか。

選択肢と解説

  • 1
    新しいリビジョンをデプロイするときに「このリビジョンをすぐに提供する」チェックボックスがオフになっていることを確認する。トラフィック ルールを変更する前に、トラフィック シミュレーション ツールを使用して新しいリビジョンに負荷を送る。
  • 2
    サービスの自動スケーリングを構成し、インスタンスの最小数を 2 に設定する。
  • ✓
    新しいリビジョンのリビジョン自動スケーリングを構成し、インスタンスの最小数を 2 に設定する。
  • 4
    既存のリビジョンのリビジョン自動スケーリングを構成し、インスタンスの最小数を 2 に設定する。

解説

【正解】C

【0からの解説】
①前提知識
・リビジョン: Cloud Run ではデプロイのたびに不変の「リビジョン」が作成され、サービスへのトラフィックをリビジョン間で分割・移行できます。新しいリビジョンをトラフィック 0% でデプロイし(コンソールの「このリビジョンをすぐに提供する」をオフ、または gcloud run deploy --no-traffic)、準備ができてから切り替えるのが段階的ロールアウトの基本です。
・最小インスタンス数: リクエストが無くてもアイドル状態で待機させておくインスタンスの数で、コールド スタート(起動時間)を回避するために使います。サービス レベルとリビジョン レベルの両方で設定できます。
・サービス レベルの最小インスタンスは、トラフィック分割に含まれるリビジョンへ、トラフィックの割合に応じて按分されます。一方、リビジョン レベルの最小インスタンスは、そのリビジョン自体に対して確保されます。

②要件の整理
・トラフィックを切り替える「前に」、新しいバージョンでアイドル インスタンスが 2 つ待機している状態にしたい
・起動時間(コールド スタート)なしで処理したい
・管理オーバーヘッド最小

③正解 C の理由
新しいリビジョンに対してリビジョン レベルの最小インスタンス数 2 を設定すれば(例: gcloud run deploy SERVICE --image=IMAGE --no-traffic --tag=green --min-instances=2。--min-instances はリビジョン レベルの設定)、そのリビジョン専用に 2 つのインスタンスが起動して待機するため、トラフィックを移したとたんにウォームなインスタンスで応答できます。設定 1 つで済み、手作業の負荷テストなども不要です。
※補足: リビジョン レベルの最小インスタンスは、そのリビジョンがトラフィック分割で参照されている、またはタグ付けされているときに起動されます。トラフィック 0% で準備したい場合は、リビジョン タグを付けておくか、ごく小さな割合を割り当てた状態で設定すると確実です。

【誤りの選択肢】
A:トラフィック 0% でデプロイすること自体は適切ですが、シミュレーション ツールで負荷をかけてインスタンスを温める方法は手作業が多く、負荷を止めればインスタンスはやがてスケールインするため、「2 つのアイドル インスタンスを確保する」ことが保証されません。管理オーバーヘッド最小という要件にも反します。
B:サービス レベルの最小インスタンスは、トラフィック分割の割合に応じてリビジョン間で按分されます。切り替え前の新しいリビジョンはトラフィックを受けていないため、その 2 インスタンスは既存のリビジョン側に割り当てられ、新しいリビジョンにはアイドル インスタンスが確保されません。
D:既存(旧)リビジョンに最小インスタンスを設定しても、温まるのは旧バージョンのインスタンスです。新しいバージョンへ切り替えたときのコールド スタート回避には役立ちません。

【参考】
Cloud Run サービスでのインスタンスの自動スケーリングについて
ロールバック、段階的なロールアウト、トラフィックの移行 | Cloud Run
この問題のページを開く →
問題 13あなたは、組織ポリシー サービスのリソース ロケーション制約(resource locations constraint…クラウド ソリューション環境の設定
問題
あなたの会社は欧州経済領域(EEA)で事業を行っており、ワークロードに Google Cloud を導入する予定です。プロジェクトは現在、複数の異なるフォルダ内に構成されています。あなたは、組織ポリシー サービスのリソース ロケーション制約(resource locations constraint)を使用して、今後デプロイされるすべてのリソースが EEA 内の Google Cloud ロケーションを使用するようにする必要があります。どうすればよいですか。

選択肢と解説

  • 1
    フォルダ レベルでポリシーを構成し、許可するすべてのロケーションをポリシーに追加する。
  • ✓
    組織レベルでポリシーを構成し、許可するすべてのロケーションをポリシーに追加する。
  • 3
    フォルダ レベルでポリシーを構成し、許可しないすべてのロケーションをポリシーに追加する。
  • 4
    組織レベルでポリシーを構成し、許可しないすべてのロケーションをポリシーに追加する。

解説

【正解】B

【0からの解説】
①前提知識
・リソース階層: Google Cloud のリソースは「組織 → フォルダ → プロジェクト → リソース」の階層で管理されます。上位で設定した組織のポリシーは、下位のフォルダやプロジェクトに継承されます。
・組織ポリシー サービス: 組織全体でリソースの構成に制約をかける仕組みです。リソース ロケーション制約(constraints/gcp.resourceLocations)は、リソースを作成できるロケーションを「許可する値(allowed)」または「拒否する値(denied)」のリストで制限するリスト型の制約で、in:eu-locations のような値グループでまとめて指定することもできます。

②要件の整理
・「すべての」リソースが EEA 内のロケーションを使うようにする
・プロジェクトは複数のフォルダに分散している(今後フォルダやプロジェクトが増える可能性もある)
・この問題で問われているのは「どの階層に設定するか(組織 or フォルダ)」と「許可リストか拒否リストか」の 2 点です。リソース ロケーション制約を使うこと自体は問題文で決まっているので、この 2 つの軸で 4 つの選択肢を比べます。

③正解 B の理由
・設定する階層: 組織レベル(階層の最上位)で設定すれば、既存のすべてのフォルダ・プロジェクトだけでなく、今後作成されるフォルダ・プロジェクトにも自動で継承されます。フォルダごとに設定すると、設定漏れや、組織直下に作られたプロジェクトが対象外になるリスクがあります。
・許可リスト方式: 許可する EEA 内のロケーションを列挙する(allowlist)方式なら、それ以外はすべて拒否されます。新しいリージョンが追加されても自動では許可されないため、確実に EEA 内に限定できます。

【誤りの選択肢】
A:許可リスト方式は正しいものの、フォルダ レベルでは各フォルダに個別に設定する必要があり、新設フォルダや組織直下のプロジェクトへの設定漏れが起こり得ます。「すべてのリソース」を確実に制限するには組織レベルの B に劣ります。
C:フォルダ レベルである点に加え、拒否リスト方式は EEA 外のロケーションをすべて列挙し続ける必要があり、Google Cloud に新しいリージョンが追加されると、それが拒否リストに無い限り許可されてしまいます。漏れが生じやすく管理負荷も高い方法です。
D:組織レベルである点は正しいものの、拒否リスト方式のため C と同じく新リージョン追加時に漏れが生じ、要件を確実に満たせません。許可リスト方式の B が適切です。

【参考】
リソース階層について | Resource Manager
Cloud Storage の組織のポリシーに関する制約
この問題のページを開く →
問題 14最初に何をすべきですか。アクセスとセキュリティの構成
問題
あなたは組織の Google Cloud システム管理者です。ユーザー A から、自分の Google Cloud プロジェクトの Cloud SQL データベースにアクセスしようとしたところエラーが発生したと報告がありました。一方、ユーザー B はそのデータベースにアクセスできています。あなたは Google が推奨するプラクティスに従って、ユーザー A の問題をトラブルシューティングする必要があります。最初に何をすべきですか。

選択肢と解説

  • 1
    ネットワークのファイアウォール ルールがユーザー A のトラフィックをブロックしていないことを確認する。
  • 2
    ユーザー A に Identity and Access Management(IAM)のプロジェクト オーナー ロールが割り当てられていることを確認する。
  • 3
    権限が意図せず変更された原因となった可能性のある、最近の構成変更を確認する。
  • ✓
    ユーザー A が受け取ったエラー メッセージを確認する。

解説

【正解】D

【0からの解説】
①前提知識
Cloud SQL へのアクセスでエラーになる原因はさまざまです。たとえば、IAM 権限の不足(例: Cloud SQL クライアント ロール roles/cloudsql.client がない、IAM データベース認証のユーザーが未登録)、ネットワーク到達性(承認済みネットワーク、プライベート IP、ファイアウォール)、データベース ユーザー / パスワードの誤り、Cloud SQL Auth Proxy の設定ミスなどです。原因によってエラー メッセージの内容(PERMISSION_DENIED、接続タイムアウト、認証失敗など)が異なります。

②要件の整理
・ユーザー B はアクセスできる → インスタンス自体は稼働しており、ユーザー A 固有の問題である可能性が高い。
・「Google 推奨のプラクティスに従い」「最初に」何をすべきか → 当て推量で設定を調べ回る前に、問題を切り分ける最初の手がかりを得ることが重要。

③正解 D の理由
トラブルシューティングの基本は、まず事実(症状)を正確に把握することです。エラー メッセージには「権限が拒否された(どの権限か)」「接続がタイムアウトした」「認証に失敗した」など、原因の種類を直接示す情報が含まれており、次に調べるべき対象(IAM か、ネットワークか、DB ユーザーか)を絞り込めます。Google Cloud のトラブルシューティング ガイドも、表示されたエラー メッセージを起点に原因を調べる構成になっており、IAM の権限問題であれば Policy Troubleshooter などで続けて調査できます。

【誤りの選択肢】
A:ファイアウォールが原因の可能性はありますが、エラーの内容を見ないうちにネットワークだけを疑うのは当て推量です。エラーが権限拒否であれば調べても無駄になります。エラー メッセージを確認したうえで、接続系のエラーであれば次に行う手順です。
B:プロジェクト オーナーは非常に広い権限を持つ基本ロールで、Cloud SQL へのアクセスに必要ではありません。最小権限の原則に反しており、「オーナー ロールがあるか」を確認すること自体が誤った方向の調査です(必要なのは roles/cloudsql.client などの適切な事前定義ロール)。
C:最近の構成変更(監査ログなど)の確認は有用な調査手段ですが、「最初に」行うことではありません。まずエラー メッセージで原因の種類を特定してから、権限関連と分かった場合に変更履歴を追うのが効率的な順序です。

【参考】
ポリシーのトラブルシューティング | Identity and Access Management (IAM)
ロールと権限 | Cloud SQL for MySQL
この問題のページを開く →
問題 15あなたは、各チームが会社の必須プラクティスの実装の詳細をすべて知らなくても、独立してインフラストラクチャをデプロイできる…クラウド ソリューションの計画と実装
問題
あなたは、さまざまなエンジニアリング チームが Google Cloud にインフラストラクチャをデプロイするのを支援しています。あなたの会社は、すべてのワークロードに必須となる特定のプラクティスを定めています。あなたは、各チームが会社の必須プラクティスの実装の詳細をすべて知らなくても、独立してインフラストラクチャをデプロイできるようにするソリューションをエンジニアリング チームに提供する必要があります。どうすればよいですか。

選択肢と解説

  • 1
    組織のポリシーを構成して会社の必須プラクティスを適用する。各チームに Google Cloud コンソールを使用してインフラストラクチャをプロビジョニングするよう依頼する。
  • 2
    チームごとにサービス アカウントを作成し、そのサービス アカウントにプロジェクト編集者ロールを付与する。各チームに、専用のサービス アカウントの権限を借用しながら Google Cloud CLI(gcloud CLI)を使用してインフラストラクチャをプロビジョニングするよう依頼する。
  • ✓
    会社の必須プラクティスに準拠した Terraform モジュールをコンポーネントごとに作成し、各チームにそれらのモジュールを使用してインフラストラクチャを実装するよう依頼する。
  • 4
    会社の必須プラクティスを理解するためのトレーニングを、関わるすべてのエンジニアリング チームに提供する。各チームがニーズに最も合う方法でインフラストラクチャをプロビジョニングできるようにする。

解説

【正解】C

【0からの解説】
①前提知識
・Infrastructure as Code(IaC): インフラ構成をコードで定義し、レビュー・再利用・自動適用できるようにする手法です。Google Cloud では Terraform が代表的なツールとして推奨されています。
・Terraform モジュール: 複数のリソース定義をひとまとめにして入力変数で再利用できる部品です。たとえば「ログ設定・暗号化・ラベル・ネットワーク設定などの社内ルールを組み込んだ VM / バケット / VPC のモジュール」を用意すれば、利用者は必要なパラメータを渡すだけで準拠したリソースを作れます。Google も Cloud Foundation Toolkit の Terraform ブループリント(モジュール)を公開しています。

②要件の整理
・会社の必須プラクティスをすべてのワークロードに適用したい
・各チームが「独立して」デプロイできる
・各チームが必須プラクティスの「実装の詳細をすべて知らなくても」よい → 詳細を抽象化して隠す仕組みが必要

③正解 C の理由
必須プラクティスを実装済みの Terraform モジュールを提供すれば、プラクティスの実装の詳細はモジュール内部にカプセル化され、チームはモジュールを呼び出すだけで準拠したインフラを自分たちのタイミングで独立してデプロイできます。コードとして再利用・バージョン管理・レビューができ、全チームで一貫した構成になります。

【誤りの選択肢】
A:組織のポリシーは「してはいけないこと」を制限するガードレールとしては有効ですが、制約に違反しない正しい構成の作り方までは教えてくれません。コンソールで手作業でプロビジョニングするとチームは結局プラクティスの詳細を知る必要があり、エラーを受けて試行錯誤することになります。手作業のため再現性・一貫性も確保できません。
B:プロジェクト編集者は広範な権限を持つ基本ロールで、最小権限の原則に反します。また gcloud CLI で個別にリソースを作る方法では、必須プラクティスをどう適用するかを各チームが知っている必要があり、要件を満たしません。
D:トレーニングでは、各チームが実装の詳細をすべて理解して自分で実装する必要があり、「詳細を知らなくてもデプロイできる」という要件と正反対です。チームごとの実装のばらつきや準拠漏れも防げません。

【参考】
再利用可能なモジュールのベスト プラクティス | Terraform
Google Cloud の Terraform ブループリントとモジュール
この問題のページを開く →

GCP-ACE 模擬問題集についてよくある質問

GCP-ACE の練習問題は無料で試せますか?

はい。GCP-ACE は先頭 15 問を会員登録なしで、正解と全選択肢の解説つきでご覧いただけます。16 問目以降は模試プラン(月額 ¥980)または Pro プラン(月額 ¥4,980)でご利用ください。

問題は何問ありますか?

GCP-ACE は本番形式の練習テスト 4 回・全 200 問を収録しています。全問に解説が付いています。

解説は付いていますか?

全ての問題に、正解の理由と各選択肢がなぜ誤りなのかの解説を付けています。ドメイン(出題分野)別の正答率も受験後に確認できます。