Professional Cloud Developer 合格記

🌸 合格：2025年02月27日

合格メモ

感想：
- 問題数：50問
	- 自信のある問題：35問程度／見直した数：15問程度
	- 70/120分 程度で１周完了／見直しで30分程度 使用し、100/120分 程度で試験完了

初見の問題が多かった印象
また、Developerの模擬試験以外の、Cloud Architect　や Network からの出題も目立った印象
特に、Cloud Architect と被る問題が多かったので、試験対策時には同時に学習することを推奨
確実な正解を導かなければ、絞ることのできない選択肢構成が多かった印象

出題傾向：

- 限定公開のGoogleアクセスを使用したCloud SQL への接続の問題
- 外部ロードバランサーの使用したいインスタンスへのネットワーク構成の問題
- デプロイ時の認証認可に関する問題
- Cloud Build のコードや構成に関する問題
	- コードから接続エラーの改善策を求める
- デプロイ時のPub/subを使用したトリガーに絡む複合問題
- Cloud Run の仕様を推奨するような問題
- Artifacts Registry　を使用した、脆弱性スキャンのためのデプロイ手順を求める問題
- Binary Auth の構成手順を求めるような問題

試験概要：

Professional Cloud Developer

受験情報 2025 年 2 月 27 日

試験名: Google Cloud Certified -Professional Cloud Developer 遠隔プロクター：自宅時計アイコン 2025年2月27日（木12:15 (世界時+09:00) 昼 🔥ぎっくり腰の状況次第で室内のセットアップができない可能性もあるので早めにリスケの検討

試験当日

試験の準備のためにログインページで試験開始を待つ
- 身分証を揃える
試験開始まで、公式ドキュメントと苦手項目を復習する

試験後のTODO

🔥 緊急事態：Udemyの当該コースが削除されていた

試験終了後に返金請求を各コースでかける
試験の回想をメモする

🔥受験に向けた戦略🔥

公式の参考資料を読む

学習戦略：

苦手項目

カーソル、制限、オフセット｜datastore

クエリカーソルを使用すると、アプリケーションでクエリオフセットのオーバーヘッドを発生させることなく、クエリの結果を一括取得できます。

Datastore モードのデータベースでは整数のオフセットをサポートしていますが、使用は避けてください。その代わりにカーソルを使用します。

❌SELECT * FROM books LIMIT 10 OFFSET 20;
⭕️`SELECT * FROM books WHERE id > last_id ORDER BY id LIMIT 10;

シリアルコンソールを使用して問題をデバッグする：Compute Engine

シリアルコンソールのログで接続エラーがないか調べることをおすすめします。シリアルコンソールには、ローカルワークステーションからブラウザを使用して root ユーザーでアクセスできます。このアプローチは、SSH を使用してログインできない場合や、インスタンスがネットワークに接続していない場合に便利です。

Cloud Shell を使用した限定公開クラスタへのアクセス：GKE・Cloud Shell

自動生成されたサブネットの使用セクションで作成した限定公開クラスタ、private-cluster-1 には、パブリックエンドポイントがあり、承認済みネットワークが有効になっています。Cloud Shell を使用してクラスタにアクセスする場合は、Cloud Shell の外部 IP アドレスをクラスタの承認済みネットワークのリストに追加する必要があります。

イメージの脆弱性を表示する：Artifact Registry

Artifact Analysis は、Artifact Registry にアップロードされた新しいイメージをスキャンします。このスキャンにより、コンテナ内のシステムパッケージに関する情報が抽出されます。レジストリ内のイメージの脆弱性の発生は、Google Cloud コンソール、Google Cloud CLI、または Container Analysis API を使用して確認できます。イメージに脆弱性が存在する場合、その詳細を確認できます。

アプリケーションロードバランサ用の GKE Ingress

このページでは、外部アプリケーションロードバランサ（HTTPS） の概要と仕組みについて説明します。Google Kubernetes Engine（GKE）では、GKE Ingress と呼ばれる、組み込みのマネージド Ingress コントローラを使用できます。このコントローラは、GKE で HTTP(S) ワークロードを処理する Google Cloud ロードバランサとして Ingress リソースを実装します。

個々のプロジェクトでの Cloud KMS の設定：職掌分散（Separation of duties (SoD)）

職掌分散を可能にするために、Cloud KMS を独自のプロジェクト（your-key-project など）で実行できます。分散要件の厳格さに応じて、次のいずれかを行うことができます。

（推奨）プロジェクトレベルで owner なしで your-key-project を作成し、組織レベルで付与された組織管理者を指定します。owner とは異なり、組織管理者は直接鍵の管理や使用はできません。鍵の管理や使用ができるユーザーを制限する IAM ポリシーの設定に限定されます。組織レベルのノードを使用すると、組織内のプロジェクトに対する権限をさらに制限することができます。

トラフィック管理（Traffic Director）：Cloud Service Mesh

Cloud Service Mesh では、メッシュ内のすべてのサービスのサービスレジストリを名前別およびそれぞれのエンドポイント別に管理します。このリストを維持して、トラフィックフロー（Kubernetes Pod の IP アドレス、マネージドインスタンスグループ内の Compute Engine VM の IP アドレスなど）を管理します。メッシュは、このサービスレジストリを使用してサービスと同時にプロキシを実行することで、適切なエンドポイントにトラフィックを転送します。プロキシレス gRPC ワークロードは、Envoy プロキシを使用するワークロードと並行して使用することもできます。

インスタンスメタデータサーバー：Cloud Run

Cloud Run インスタンスは、プロジェクト ID、リージョン、インスタンス ID、サービスアカウントなど、コンテナに関する詳細情報を取得するために使用できるメタデータサーバーを公開します。メタデータサーバーを使用して、サービス ID のトークンを生成することもできます。メタデータサーバーのデータにアクセスするには、Metadata-Flavor: Google ヘッダーを使用して http://metadata.google.internal/ エンドポイントに HTTP リクエストを送信します。

BigQuery Job User

BigQuery Job User (roles/bigquery.jobUser)

Provides permissions to run jobs, including queries, within the project.

プロジェクト内でクエリを含むジョブを実行する権限を付与します。

コンピューティング容量を変更する：Cloud Spanner

インスタンスを作成した後で、そのコンピューティング容量を増やすことができます。ほとんどの場合、リクエストは数分で完了します。まれに、スケールアップが完了するまでに最大 1 時間かかることがあります。...

コンピューティング容量を削除するときは、Cloud Monitoring で CPU 使用率とリクエストレイテンシをモニタリングし、リージョンのインスタンスで CPU 使用率が 65% を下回り、マルチリージョンのインスタンスの各リージョンで 45% を下回るようにしてください。コンピューティング容量の削除中に、リクエストのレイテンシが一時的に増加する場合があります。

Cloud Trace と Zipkin の使用

Zipkin サーバーは、アプリケーションが Zipkin でインストゥルメントされているが、独自のトレースバックエンドを実行したくない場合や、Cloud Trace の高度な分析ツールを利用したいとう場合に役立ちます。

GKE：ベストプラクティス：推奨

リージョンクラスターは、3つのKubernetesコントロールプレーンクォーラムで構成され、ゾーンクラスターがクラスターのコントロールプレーンAPIに提供できるよりも高い可用性を提供します。また、コントロールプレーンが利用できない場合、ノードで実行されている既存のワークロードは影響を受けませんが、一部のアプリケーションはクラスターAPIの可用性に大きく依存しています。これらのワークロードには、リージョンクラスタートポロジを使用することをお勧めします。

初期化期間（旧称クールダウン期間）：GCE

初期化期間（旧称クールダウン期間）は、VM インスタンスでアプリケーションが初期化されるのにかかる時間です。アプリケーションがインスタンスで初期化されている間に、インスタンスの使用状況は通常の状況を反映していない可能性があります。 : インスタンスの初期化に要する時間よりも大幅に長い初期化期間の値を設定すると、オートスケーラーが適正な使用率データを無視してしまう可能性があります。その結果、グループの必要なサイズが過小評価され、スケールアウトの遅延が生じることがあります。

Gateway API リソース：GKEネットワーク

図が有益

Kubernetes Service とは

Service の目的は、一連の Pod エンドポイントを 1 つのリソースにグループ化することです。このグループにアクセスするさまざまな方法を構成できます。デフォルトでは固定クラスタ IP アドレスを取得し、クラスタ内のクライアントはそれを使って Service 内の Pod と通信できます。

クラスタの可用性タイプ：GKE

ベストプラクティス:

本番環境ワークロードには、ゾーンクラスタよりも可用性が高いリージョンクラスタを使用します。開発環境の場合は、ゾーンノードプールを使用するリージョンクラスタを使用します。リージョンコントロールプレーンとゾーンノードプールを使用するクラスタの費用は、ゾーンクラスタと同じです。

ネットワーク分離の選択肢：GKE

ベストプラクティス:

Cloud NAT を使用して、GKE Pod がパブリック IP アドレスでリソースにアクセスできるようにします。Cloud NAT を使用すると、Pod は直接インターネットに公開されませんが、インターネットに接続するリソースにはアクセスできるため、クラスタの全体的なセキュリティポスチャーが向上します。

GKE クラスタのアーキテクチャ

構成図が有益

コンテナログを書き込む：Cloud Run ログ

サービスまたはジョブからログを作成する場合、ログの出力先が次のいずれかであれば、Cloud Logging によってログが自動的に取得されます。

標準出力（stdout）または標準エラー（stderr）ストリーム

/var/log ディレクトリにあるすべてのファイル

syslog（/dev/log）

Cloud Logging クライアントライブラリを使用して作成されたログ。このログは、多くの一般的な言語で利用可能です。

ほとんどのデベロッパーは、ログの出力先として標準出力と標準エラーを想定しています。

フレームグラフ：Cloud Profiler

Cloud Profiler では、フレームグラフを使用してプロファイリングデータが表示されます。フレームグラフでは、ツリーや他のグラフより画面スペースが効率的に使用され、大量の情報がコンパクトで読みやすい形式で表示されます。枠には関数の名前が付き、その幅はその関数の合計 CPU 時間の測定値に相対した長さになります。

リクエストレートを徐々に増やす：Cloud Strage

Cloud Storage の自動スケーリングを常に最適に機能させるためには、高いリクエストレートが数日間なかったバケットや、オブジェクトキーの新しい範囲を持つバケットのリクエストレートを徐々に増やす必要があります。毎秒の書き込みリクエストが 1,000 件未満、または読み取りリクエストが 5,000 件未満のリクエストレートについては、増やす必要はありません。リクエストレートがこれらのしきい値を超えると予想される場合は、しきい値より低いまたは近いリクエストレートから徐々にレートを上げていきます。ただし、20 分間でレートが倍にならないようにする必要があります。レイテンシやエラーレートの増大などの問題が発生した場合は、一時的にリクエストレートの段階的な増加を中止するか、リクエストレートを減らして、Cloud Storage でバケットがスケーリングされるまでもうしばらく待ってみます。指数バックオフを使用してリクエストを再試行するのは、次のようなときです。

408 と 429 のレスポンスコードでエラーが発生する。

5xx レスポンスコードでエラーが発生する。

uptime checks：Cloud Monitoring

HTTP と HTTPS の場合、すべての URL リダイレクトを行い、稼働時間チェックで受信した最終的なレスポンスを使用して成功基準を評価します。HTTPS チェックの場合、SSL 証明書の有効期限は、最後のレスポンスで受信したサーバー証明書に基づいて計算されます。

障害復旧アーキテクチャ：Cloud SQL 図を要確認

Cloud SQL の 2 つのインスタンス（プライマリ インスタンスとスタンバイ インスタンス）は、単一のリージョン（プライマリリージョン）内の 2 つの別々のゾーンにあります。インスタンスは、リージョン永続ディスクを使用して同期されます。

Cloud SQL（クロスリージョン リードレプリカ）の 1 つのインスタンスが 2 番目のリージョン（セカンダリリージョン）にあります。DR の場合、クロスリージョンリードレプリカは、リードレプリカの設定を使用して（非同期レプリケーションを使用）プライマリインスタンスとの同期をとるように設定されます。

合格メモ​

受験情報 2025 年 2 月 27 日​

試験当日​

試験後のTODO​

🔥受験に向けた戦略🔥​

学習戦略：​

苦手項目​