受験体験記（Google Cloud Professional Cloud Architect）

Posted at 2026-01-24

誰かの参考になれば。

受験概要

受験日 2026/01/18
オンライン受験（Kryterion）※複数回目
試験時間 2h ※見直し含めて1.5h超
問題数 50問 ※合格したので正答率不明
なぜか連続受験クーポンが利用できず$200

受験後の感想

流石にAssociateレベルに比べると難しく、用語や考え方など、自信を持って説明できないものがチラホラでてきた
そろそろ実際の環境を触りながら確認しないと活きた知識にならなそうなので、触りながらちゃんと復習してから次の試験に臨もうと思った
以下のUdemyの模擬試験の的中率は高かったけどちゃんと理解してないと意外と足元掬われる
50問終了時の見直しマークは13問
- 冒頭10問程度のケーススタディでの見直し対象が7問程度発生し、また慣れるまで時間がかかったため結構ヒヤヒヤした
- ケーススタディからはEHRとHRLが出題され、それぞれ5,6問ずつが連続して出題された
- ケーススタディ以降は比較的スムーズに解けた
開始直前の環境チェック最後の段階で「接続が切れた」とのことで、一旦終了して環境チェックからやり直した

勉強法

Udemy：【2026年最新】Google Cloud 認定 Professional Cloud Architect 模擬試験
- 割引なしで3000円
一旦真面目に3回分の模擬試験を受験し、残り1回分は解説を流し読み
直しをしながらGeminiと壁打ち
VSCodeでMDにまとめつつ、Copilotで補完するととても楽ができる
勉強時間：電車で模擬試験&直し、1hくらい集中して復習(4hくらい)
- 模擬試験：1,2,3回目それぞれ8割超えた。ACEで押さえた基礎知識だけで解けるものがそれなりにある
- 一方で、より細かい設定等に関する知識やトラブルシューティングなどが多かったが、システム開発・運用の知識があると割と対応可能
- 新たな知識としては以下を押さえておく必要あり
  - Binary Authorization
  - VPC Service Controls
  - Identity-Aware Proxy (IAP)
- 以下の用語等はまとめ切れなかったが、逆に時間のなさが見て取れる。。

前提

一般的なwebシステム開発の経験あり
Docker/Kubernetesの基礎知識あり
CISSPと情報処理安全確保支援士を取得済みなのでセキュリティ方面の知識もそれなり
いくつかのGoogleCloud資格取得済み(CDL,GAIL,ACE,ADP,AGWA)
まだ実際のGoogle Cloud環境は一切触ってない(そろそろやばい)

得られた用語など(試験後の復習含む)

※自分用メモ。正確性に責任負いません
Binary authorization: コンテナイメージのデプロイ前に署名を検証することで、信頼できるイメージのみを実行する仕組み
BQ+BYOK->CMEK: BigQueryで顧客管理の暗号化キーを使用する仕組み

シャットダウンスクリプト: インスタンスのシャットダウン時に実行されるスクリプト。以下はその設定値
- shutdown-script-metadata-key: シャットダウンスクリプトを指定するためのメタデータキー
- shutdown-script-timeout: シャットダウンスクリプトの実行時間のタイムアウト設定(デフォルト：30秒、最長：3600秒)
- shutdown-script-exit-on-timeout: タイムアウト時にスクリプトを強制終了するかどうかの設定
- SPOT VMの場合、シャットダウンスクリプトは事前通知なしに強制終了される可能性がある
GKE(k8s)のノード選択設定
- Node Affinity: 特定のノードにPodをスケジューリングするための設定
- Taints and Tolerations: 特定のノードにPodをスケジューリングしないようにするための設定

GKEのソリューション

ワークロード管理

Deployment: ステートレスアプリケーションの管理、レプリカ数の指定、自動ロールアウトとロールバック
ReplicaSet: Podのレプリカ数を維持する
Service: Podへの安定したネットワークアクセスを提供、ロードバランシング
Ingress: HTTP/HTTPSトラフィックのルーティング、SSL終端
Egress: クラスタ外へのトラフィック管理
ConfigMap: 非機密設定データの管理と注入
Secret: 機密データ（パスワード、APIキーなど）の管理と注入
IAP (Identity-Aware Proxy): アプリケーションへのアクセスをユーザーのIDに基づいて制御する仕組み
- 用途：社内アプリケーションへのセキュアなアクセス、ゼロトラストセキュリティの実現
- IAPのIP範囲（35.235.240.0/20）をファイアウォールで許可する必要がある
IstioやAnthos Service Meshのフォールトインジェクション: システムの耐障害性をテストするために、意図的に障害を注入する手法
- Istio: オープンソースのサービスメッシュプラットフォームで、マイクロサービス間の通信を管理、セキュリティ強化、監視を提供
- Anthos Service Mesh: Google Cloudのマネージドサービスメッシュで、Istioをベースにしており、セキュリティ、可観測性、トラフィック管理を提供
- サービスメッシュ: マイクロサービスアーキテクチャにおいて、サービス間の通信を管理するためのインフラストラクチャレイヤー
k8sのコンテナの追跡可能性: タグにコミットハッシュ (SHA) を使う
- Cloud BuildのビルドステップでコミットSHAを取得し、コンテナイメージにタグ付けする
- GKEのデプロイメントマニフェストで、イメージタグとしてコミットSHAを指定する

「パブリックIPなし」＋「インターネットへアクセス」＝ Cloud NAT
Regional Persistent Disk」 + 「Force Attach」
「アップロード後の整合性確認」＝ローカル計算ハッシュ vs GCSメタデータ(CRC32C)
「SLO/エラーバジェット監視」＝ Anthos Service Mesh (ASM) + Cloud Monitoring
「GKE」＋「マルチリージョン・低レイテンシ」＝ Multi Cluster Ingress (MCI)
Cloud Monitoring が正確なサイズ適正化の推奨（Rightsizing Recommendations）
「データの持ち出し（Exfiltration）防止」＝ VPC Service Controls

VPC Service Controls: Google Cloudリソースへの不正アクセスやデータの持ち出しを防止するためのセキュリティ機能
高可用性: システムが継続的に稼働し、障害が発生してもサービスを提供し続ける能力
- DR（Disaster Recovery）: 災害復旧。システム障害や災害発生時にデータとサービスを復旧するための計画と手順
- SLA（Service Level Agreement）: サービス提供者と利用者の間で合意されたサービス品質や可用性の基準
- BCP（Business Continuity Plan）: 事業継続計画。災害や障害発生時に事業を継続するための計画
- RPO（Recovery Point Objective）: データ復旧目標時間。障害発生時に許容されるデータ損失の最大時間
- RTO（Recovery Time Objective）: 復旧目標時間。障害発生からサービス復旧までの最大許容時間
高信頼性：システムが一貫して正確に動作し、エラーや障害が発生しにくい能力
- フォールトトレランス: 障害が発生してもシステムが継続的に動作する能力
- 冗長化: システムの重要なコンポーネントを複数用意し、障害発生時に代替できるようにすること
- 自動フェイルオーバー: 障害発生時に自動的にバックアップシステムに切り替える仕組み
- Binary Authorization: コンテナイメージのデプロイ前に署名を検証することで、信頼できるイメージのみを実行する仕組み
回復力(レジリエンス)：システムが障害や攻撃から迅速に回復し、正常な状態に戻る能力
- バックアップとリストア: データの定期的なバックアップと、必要に応じてデータを復元する手順
- モニタリングとアラート: システムの状態を監視し、異常が発生した場合に通知する仕組み
- インシデント対応計画: 障害発生時の対応手順と責任者を明確にした計画
スケーラビリティ: システムが負荷の増加に応じてリソースを拡張・縮小できる能力
- 垂直スケーリング: 既存のリソース（CPU、メモリなど）を増強することで性能を向上させる方法
- 水平スケーリング: 新しいリソース（サーバー、インスタンスなど）を追加することで性能を向上させる方法
- オートスケーリング: システムの負荷に応じて自動的にリソースを増減させる仕組み
高機密性: システムが機密情報を保護し、不正アクセスや漏洩を防止する能力
- データ分類: 機密情報の重要度に応じて分類し、適切な保護措置を講じること
- アクセス制御: 機密情報へのアクセスを必要最小限に制限する仕組み
- 監査ログ: 機密情報へのアクセス履歴を記録し、不正アクセスを検出するためのログ
セキュリティとコンプライアンス: システムが不正アクセスやデータ漏洩から保護され、法規制や業界標準に準拠していること
- IAM（Identity and Access Management）: ユーザーやサービスの認証・認可を管理する仕組み
- データ暗号化: データを暗号化して保護する方法
- ネットワークセキュリティ: ファイアウォール、VPN、VPCなどを使用してネットワークを保護する方法
- コンプライアンス: 法規制や業界標準に準拠するための取り組み
コスト最適化: システムの運用コストを最小限に抑えつつ、必要な性能と可用性を確保すること
- リソースの適切な選択: 必要な性能に応じて適切なリソースを選択すること
共有VPC: 複数のプロジェクトでVPCネットワークを共有し、リソースの一元管理とセキュリティ強化を図る仕組み
VPCピアリング: 異なるVPCネットワーク間でプライベートIP通信を可能にする仕組み
共有VPCとVPCピアリングの違い: 共有VPCは複数プロジェクトで同一VPCを共有するのに対し、VPCピアリングは異なるVPC間で通信を可能にする仕組み
Node affinity: 特定のノードにPodをスケジューリングするための設定
「誰がリソースを作成したか？」＝ Cloud Logging の管理アクティビティログ
集約シンク：複数のプロジェクトや組織からのログを一元的に収集・管理する仕組み
includeChildren オプション：組織やフォルダ内のすべてのプロジェクトからログを収集するための設定
WORM（Write Once Read Many）：一度書き込んだデータを変更できず、読み取り専用にすることでデータの整合性と保護を強化する仕組み
POSIX準拠のファイルシステム： Unix系システムで標準的に使用されるファイルシステム規格に準拠したファイルシステム
- POSIX（Portable Operating System Interface for Unix）： Unix系システムで標準的に使用されるAPIとコマンドセットの規格
Cloud Filestore： Google Cloud上で提供されるマネージドなNFSファイルシステムサービス
Filestore High Scale：大規模なワークロード向けの高性能なFilestoreオプション
Filestore Enterprise：エンタープライズ向けの高可用性とセキュリティを備えたFilestoreオプション
「外部ドメインへの権限付与禁止」＝組織ポリシーの「ドメイン制限付き共有」
ドメイン制限付き共有: 組織内のユーザーが外部ドメインのユーザーとリソースを共有することを制限するポリシー
VPC境界: VPC Service Controlsを使用して、特定のVPCネットワーク内でのみリソースへのアクセスを許可するセキュリティ境界
「Bigtable のホットスポット」＝ RowKey の設計ミス（分散させる）
column family: Bigtableのデータを論理的にグループ化するための列の集合
ホットスポット: 特定のノードに過剰な負荷が集中する現象
RowKey設計: データの分散とアクセスパターンを考慮したRowKeyの設計
K8sのprobe: コンテナの状態を監視するための仕組み
- Liveness probe: コンテナが正常に動作しているかを監視し、異常が検出された場合に再起動する仕組み
- Readiness probe: コンテナがリクエストを受け付ける準備ができているかを監視し、準備ができていない場合はトラフィックを停止する仕組み
  「IP重複あり」＋「他社へのプライベート公開」＝ Private Service Connect (PSC)
  「GKEへのCDパイプライン」＋「Skaffold」＝ Cloud Deploy
Cloud Deploy: Google Cloud上で提供される継続的デリバリーサービス
Skaffold: Kubernetesアプリケーションの開発とデプロイを自動化するためのツール
spinner: Skaffoldのコンポーネントで、コードの変更を監視し、自動的にビルドとデプロイを実行する仕組み
spinnakerとは異なる
- Spinnaker: マルチクラウド環境での継続的デリバリーをサポートするオープンソースのプラットフォーム(Net
  flix発)
  「モバイル同期」＋「オフライン対応」＝ Firestore (ネイティブモード)
  「サーバーレス」＋「バッチ処理（HTTP不要）」＝ Cloud Run Jobs
  共有VPC + VPCピアリングの違い
共有VPC: 複数のプロジェクトでVPCネットワークを共有し、リソースの一元管理とセキュリティ強化を図る仕組み

キーワードごとのGoogleCloudサービス例

高可用性・スケーラビリティ
- Compute Engineのマネージドインスタンスグループ
- Cloud Load Balancing
- Cloud SQLの高可用性構成
高信頼性・回復力
- Cloud Storageのバージョニングとライフサイクル管理
- Cloud MonitoringとCloud Logging
- Cloud Functionsの自動リトライ
高機密性・セキュリティとコンプライアンス
- Cloud IAMとCloud Identity
- Cloud KMS（Key Management Service）
- VPC Service Controls
コスト最適化
- Sustained Use DiscountsとCommitted Use Contracts
- Cloud Cost Managementツール
- プリエンプティブルVMとスポットインスタンス
- Cloud FunctionsやCloud Runなどのサーバーレスサービス
- BigQueryのオンデマンド課金モデル
高可用性＋高コスパのくみ合わせ例
- Cloud CDN + Cloud Storage
- Cloud Functions + Firestore
- App Engine Standard Environment
  API の収益化/開発者ポータル＝ Apigee。
  Interconnect SLA 99.99% ＝ 2 つの都市圏 × 2 つのドメイン＝ 4 本の接続。
  不安定な回線でのファイルアップロード＝再開可能なアップロード (Resumable Uploads)。
  脆弱性のあるイメージのブロック＝ Artifact Registry スキャン＋ Binary Authorization。
  Dataflowのウォーターマークと遅延＝イベントタイムの処理。
- ウォーターマーク: イベントタイムの進行を示す指標で、遅延データの処理を管理するために使用される
- 遅延: イベントが発生してから処理されるまでの時間差
- 許容される遅延: システムが許容できる最大の遅延時間
  SLSA レベル 3 / ビルド証明書＝ Cloud Build の自動来歴生成 (Provenance)。
SLSA (Supply chain Levels for Software Artifacts): ソフトウェアアーティファクトのサプライチェーンセキュリティのレベル
- レベル 1: 基本的なビルドプロセスの確立
  - 例: ソースコードのバージョン管理、ビルドスクリプトの使用
- レベル 2: ビルドプロセスの自動化と検証
  - 例: CI/CDパイプラインの導入、依存関係の検証
- レベル 3: ビルドプロセスの完全な監査可能性
  - 例: ソースコードの署名、ビルド環境の分離
- レベル 4: 高度なセキュリティ対策の実装
  - 例: 複数の署名者による署名、ハードウェアセキュリティモジュール (HSM) の使用
ビルド証明書 (Provenance): ソフトウェアアーティファクトのビルドプロセスとソースコードの来歴を証明する情報
Cloud Build の自動来歴生成: Cloud Buildがソフトウェアアーティファクトのビルドプロセスとソースコードの来歴を自動的に生成する機能
Direct VPC Egress ＝高速でセキュアなオンプレミス接続。
Direct VPC Egress: Google CloudのVPCネットワークからオンプレミス環境への直接的なトラフィックルーティングを可能にする機能
サーバーレスVPCアクセスvs Direct VPC Egress
サーバーレスVPCアクセス: Cloud FunctionsやCloud RunなどのサーバーレスサービスがVPCネットワークにアクセスするための機能
Direct VPC Egress: VPCネットワークからオンプレミス環境への直接的なトラフィックルーティングを可能にする機能
違い：
- サーバーレスVPCアクセスはサーバーレスサービスからVPCへのアクセスを提供し、Direct VPC EgressはVPCからオンプレミスへのアクセスを提供する
  生成 AI の有害コンテンツブロック＝安全性設定 (Safety settings)。
安全性設定 (Safety settings): 生成AIモデルが有害なコンテンツを生成しないようにするための設定オプション
Binary Authorizationによる手動承認フロー
attestation authority: コンテナイメージの署名と検証を担当する権限
manual approval: コンテナイメージのデプロイ前に手動で承認を行うプロセス
deployment policy: コンテナイメージのデプロイに関するルールと要件を定義するポリシー
attestator: コンテナイメージの署名と検証を行うエンティティ
Binary Auth での手動承認＝ Attestor（証明者）による署名作成＋ポリシーでの署名要求。

PCAの4つのケーススタディの観点

※試験時間を節約できる可能性があるため、事前に内容と解決策を詳細に把握しておくことが重要
事例紹介：https://cloud.google.com/certification/guides/cloud-architect?hl=ja#case_studies
Youtube解説動画：https://www.youtube.com/watch?v=wJqmcacktOE

1. EHR Healthcare（医療インフラの移行）

背景

多国籍な医療機関にSaaSを提供
急成長に伴い、オンプレミスからクラウドへの移行が必要
DR（災害復旧）プランの強化が必要
PHI（Protected Health Information）の保護が必須
BAA（Business Associate Agreement）の遵守

技術的要件

99.9%以上の可用性
レガシーインターフェースの維持
コンテナ管理の共通化
データ暗号化とアクセス制御の強化

推奨ソリューション

GKE / Anthos: ハイブリッド・マルチクラウド環境のコンテナ管理
Cloud Interconnect: オンプレミスとの高パフォーマンスな専用線接続
Apigee: 保険プロバイダーとのAPI統合管理

2. Helicopter Racing League (HRL)（メディア・予測分析）

背景

ヘリコプターレースの世界配信
ライブテレメトリとレース展開の予測をリアルタイムで提供

技術的要件

視聴者の低遅延化
AI予測モデルのパートナーへの公開
大量データの処理

推奨ソリューション

Vertex AI (AI Platform): エンドツーエンドの機械学習ライフサイクルと予測
Cloud CDN: グローバル、特に新興市場へのコンテンツ配信の低遅延化
Pub/Sub & Dataflow: リアルタイムストリーミングデータの取り込みと処理

3. TerramEarth（製造業・IoT/API）

背景

重機の製造
200万台の車両から収集される膨大なセンサーデータを活用
故障検知や部品供給の最適化を図る

技術的要件

レガシーシステムへのAPIアクセスのための抽象化レイヤー構築
CI/CDのモダナイズ

推奨ソリューション

Apigee / Developer Portal: パートナー向けのAPI管理とセルフサービスポータル
BigQuery & Bigtable: 時系列データやセンサーデータの分析・リアルタイム処理
Cloud Build & Artifact Registry: コンテナベースのCI/CDパイプライン構築

4. Mountkirk Games（ゲーム・グローバルスケール）

背景

マルチプレイヤーゲームの開発
世界中のプレイヤーを最も近いリージョンに接続
グローバルリーダーボードを同期させる必要がある

技術的要件

リアルタイムのリーダーボード更新
数百万ユーザーへの自動スケーリング
コストの最適化

推奨ソリューション

Cloud Spanner: リージョンを跨いだ強い整合性と水平スケーリング（リーダーボード用）
GKE & Global Load Balancing: 世界規模のシームレスなオートスケーリング
GPUアクセラレータ: サーバーサイドでのグラフィックスレンダリング支援

製品選定のヒント

問題文の中の「スケーラビリティ（垂直か水平か）」や「リレーショナルか非構造化か」といったキーワードから最適なサービスを導き出す

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up