難易度は Level 1（やさしめ）〜Level 5（難関） の5段階です。
GCP PCAのサンプル問題（本番形式・解説付き）
GCP PCA（Google Cloud・Professional Cloud Architect（PCA））の出題形式を、実際の問題で確かめられます。ここに掲載する5問は、無料の会員登録で解ける模試 第1回（55問）の冒頭から抜粋したオリジナル問題です。当サイトは全440問を本番CBT準拠の形式で収録しており、この5問はそのごく一部にあたります。
設問1
オンライン小売企業のカタログ運用チームが、商品カタログの属性生成を自動化しようとしている。この企業の product strategy は品揃えの広さで勝つことであり、カタログ登録のリードタイム短縮が最優先の要件である。アーキテクトが選ぶ進め方はどれか。
- 自前の大規模言語モデルをフルスクラッチで学習させ、生成品質の最後の数%まで社内で作り込んでから公開に踏み切る。
- 属性の入力は担当者の手作業のまま残し、自動生成の対象を新規カテゴリの登録だけに限定して様子を見る。
- 生成した属性に Human-in-the-Loop レビューを挟み、登録の待ち時間を詰めて早く回す運用を組む。（正解）
- カタログ登録の自動化はいったん保留し、全社の監査証跡の設計をやり直してから着手する。
解説
product strategy が品揃えの広さで勝つことなので、カタログ登録のリードタイム短縮が最優先になり、生成品質の最後の数%を人手で詰めるより Human-in-the-Loop レビュー付きで早く回す設計が正解になります。自前 LLM のフルスクラッチ学習は、小売のカタログ改善という business use case と無関係に技術的高度さを取る形で、事業の勝ち筋に効かないため誤りです。手作業を残して対象を限定する案は、リードタイム短縮という最優先の要件に届きません。監査証跡の設計をやり直す案は、規制準拠を保ったまま進める医療 SaaS 側の判断軸であり、この場面の business use case からは導かれません。
設問2
医療 SaaS の運用チームが信頼性に関する用語を整理している。社内でリリースを止めるかどうかの判断基準として使う値を定義したい。この目的に当たる用語はどれか。
- SLI ── 測る値そのものを指す。
- SLA ── 顧客との契約で、違反時に補償が発生する。
- KPI ── 経営が見る事業側の指標を指す。
- SLO ── 自分たちが守ると決めた目標値で、error budget を伴う。（正解）
解説
SLO は自分たちが守ると決めた目標値で、error budget（許容される逸脱量）を使い切ったらリリースを止めて信頼性作業に回す、という運用判断につながります。SLI は測る値そのもので、判断の基準値には当たりません。SLA は顧客との契約で違反時に補償が発生するもので、設問の「社内で運用の判断基準にしたい」から外れます。KPI は売上や解約率のような経営が見る事業側の指標で、リリース判断の基準にはなりません。
設問3
決済データを扱う部門が事業継続計画を技術に落としている。リージョン障害が起きても RPO=0、RTO≒0 を満たすことが要件である。データベースの構成として適切なものはどれか。
- Spanner の multi-region 構成を採用し、リージョンをまたいで強整合を保つ。（正解）
- Cloud SQL の高可用性構成を同一リージョン内で組み、ゾーン障害に備える。
- Cloud SQL の cross-region read replica を用意し、被災時に昇格させて復旧する。
- 日次のバックアップを別リージョンに保持し、被災後にそこから環境を作り直す。
解説
RPO をほぼゼロにするには同期レプリケーションを持つ製品が要り、Spanner は multi-region で強整合なのでリージョン障害でも RPO=0、RTO≒0 の要件に寄ります。Cloud SQL の高可用性構成は同一リージョン内の仕組みで、リージョン障害には届きません。cross-region read replica は非同期で RPO>0、昇格に時間がかかるため RTO>0 となり要件を外します。日次バックアップからの復旧は Backup and restore に当たり、RTO の目安が時間〜日なので要件に届きません。
設問4
メディア配信企業が、公開直後はよく見られ数か月で参照が落ちる動画ファイルの保管費用を下げたい。高可用性と拡張性は維持する条件が付いている。取るべき構成はどれか。
- 作成時からオブジェクトを Archive クラスに置き、配信のたびに取り出す。
- Object Lifecycle Management で一定日数の経過後に Nearline・Coldline・Archive へ自動遷移させ、アクセスパターンが読めない部分は Autoclass に任せる。（正解）
- 参照が落ちた時点でバケットを新しく作り直し、対象のオブジェクトを手で移し替える運用を組む。
- Standard クラスのまま保持し、増える保管費用は Committed use discounts の購入で吸収する。
解説
アクセス頻度が下がるデータには Cloud Storage のクラス分けが効き、Object Lifecycle Management による自動遷移と、アクセスパターンが読めない部分を Autoclass に任せる組み合わせが正解の形です。作成時から Archive に置く案は、配信中コンテンツの取り出し費用と最低保存期間 365 日で逆に高くつきます。バケットを作り替えて手で移す案は運用負荷が大きく、誤答として出やすい形です。Committed use discounts は 1 年・3 年ずっと動く基盤に効く手札で、Cloud Storage のクラス分けの代わりにはなりません。
設問5
小売企業の Web アプリがセッション情報を VM のローカルディスクに置いており、オートスケールもゾーン障害対応も成り立っていない。インフラ側の改善策はどれか。
- セッション情報をローカルディスクに残したまま、インスタンスのサイズを大きくして同時接続数を稼ぐ。
- セッション情報を保持したまま VM を sole-tenant nodes へ移し、物理サーバーを占有して障害の影響を抑える。
- セッション情報を Memorystore へ外出しし、コンピュートを使い捨てにできる構成へ変える。（正解）
- セッション情報の置き場所は変えずに、アプリをコンテナ化して Cloud Run へ載せ替える。
解説
ステートの置き場所を分離することが設計の鍵で、Memorystore（Redis）や Firestore に外出しすればコンピュートは使い捨てにでき、オートスケールもゾーン障害対応も成り立ちます。インスタンスを大きくする案はローカルディスクにステートが残るため、元の欠陥がそのまま残ります。sole-tenant nodes は OS レベルの依存やライセンス要件に応える手札で、ステートの分離には効きません。置き場所を変えずに Cloud Run へ載せ替える案は、リクエスト単位でスケールする前提とステートの残留が噛み合いません。
続きは、会員登録なしでそのまま50問解けます。採点と解説つきで、上と同じ本物の問題です。
登録なしで50問解く