GCP PCA サンプル問題

正解：B

A　OSパッチ適用やイメージ管理などの運用負担が残り、少人数チームの短期立ち上げには向かない

B（正解）　正解。コンテナをデプロイするだけでスケーリングやインフラ管理が不要になり、運用専任者のいない少人数チームに最適

C　Kubernetesクラスタのバージョン管理やノード運用の負担が大きく、運用担当者のいない体制では過剰

D　オンプレミスのVMware資産を移行するためのサービスであり、新規のコンテナワークロードには不適

正解：C

A　システムが提供する機能そのものであり、機能要件に分類される

B　提供する機能の内容を定めたものであり、機能要件に該当する

C（正解）　正解。可用性・性能・セキュリティなどシステムの品質特性を定めるものは非機能要件

D　システムの振る舞いを定義した機能要件であり、品質特性の定義ではない

正解：A

A（正解）　正解。差別化に寄与しない標準業務は自社開発せず、実績あるSaaSの購入が総所有コストと保守負担の面で合理的

B　自社開発は差別化領域に投資すべきで、標準業務への大規模開発投資は費用対効果が低い

C　老朽化した独自システムの保守負担が残り続け、根本的な解決にならない

D　経費精算は法令上も業務上も必要なプロセスであり、廃止は選択肢にならない

正解：D

A　事後にKPIを選ぶと都合の良い指標だけを選定するバイアスが生じ、客観的な成功測定にならない

B　コストは指標の一つにすぎず、性能・可用性・リリース速度などの改善を測定できない

C　作業量の指標であり、移行がビジネスにもたらした価値の測定にはならない

D（正解）　正解。事前にベースラインとKPI（レイテンシ、コスト、リリース頻度など）を定義することで移行前後の比較が可能になる

正解：B

A　強整合は満たせるが、遠隔リージョンのユーザーへのカタログ配信レイテンシ要件を満たせない

B（正解）　正解。整合性要件が異なるデータをコンポーネント分割し、それぞれに適した基盤を選ぶのが設計トレードオフの定石

C　カタログには適するが、在庫の強整合要件を満たせず売り越しのリスクが生じる

D　ビジネス要件そのものを放棄しており、アーキテクチャ設計の解決策ではない

正解：A

A（正解）　正解。RPOは障害時に許容できるデータ損失の期間を表し、15分なら15分前までのデータ復元を保証する設計が必要

B　RTOはサービス停止から復旧完了までの許容時間であり、データ損失量の指標ではない

C　故障の発生頻度を表す信頼性指標で、データ損失の許容量とは無関係

D　提供者と利用者の間の合意文書全体を指し、データ損失許容時間そのものを表す指標ではない

正解：C

A　スナップショットは復旧を助けるが、ゾーン障害時に即時継続はできず単一障害点が残る

B　VM単体の障害には耐えるが、ゾーン全体の障害では全台が同時に停止する

C（正解）　正解。リージョナルMIGはゾーンをまたいでインスタンスを分散し、ゾーン障害時も残りのゾーンで継続できる

D　リージョン障害対策としては一案だが、手動切替では継続性が低くゾーン障害対策として過剰かつ低速

正解：B

A　リードレプリカは非同期複製の読み取り用で、自動フェイルオーバーは行われず昇格も手動操作が必要

B（正解）　正解。HA構成は別ゾーンのスタンバイへ同期複製し、障害時に自動フェイルオーバーする

C　復旧手段にはなるが復元操作が必要で、自動フェイルオーバーの要件を満たさない

D　整合性の破綻を招きやすいアンチパターンで、マネージドなHA機構の代替にならない

正解：D

A　RTOは最短になるが平常時コストが約2倍になり、コスト最小化の要件に反する

B　RTO数時間クラスの要件向けで、24時間許容の本要件にはコスト過剰

C　最も高コストな戦略で、基幹バッチのRTO24時間という緩い要件に対して過剰投資

D（正解）　正解。平常時はバックアップ保管費用のみで済み、RTO24時間ならIaCによる再構築で十分間に合う

正解：A

A（正解）　正解。単一のエニーキャストIPでヘルスチェックに基づき正常なリージョンへ自動的にルーティングされる

B　DNSはヘルスを考慮せず、キャッシュされたレコードが障害リージョンへ誘導し続ける

C架空　このようなサービスは実在しない。リージョン間フェイルオーバーはグローバルLBの標準機能で実現する

D　手動運用では切替までの停止時間が長く、利用者の操作なしという要件は満たしても自動性・即時性に欠ける

正解：C

A　RPOは改善するが、復旧作業に時間がかかる問題（RTO超過）の解決にはならない

B　データ保全性は上がるが、復旧手順の習熟や検証の欠如という根本原因に対処できない

C（正解）　正解。バックアップは復元できて初めて意味を持ち、定期的なリストアテストでRTO達成可能性と手順の妥当性を検証できる

D　取得の成否を知るだけで、復旧作業の実効性は何も検証されない

正解：A・C

A（正解）　正解。Spannerはマルチリージョン構成でも外部整合性を保証する数少ないリレーショナルDB

B　サブミリ秒応答はMemorystoreなどインメモリストアの領域で、Spannerの適用理由にならない

C（正解）　正解。Spannerは自動シャーディングにより書き込みを水平スケールでき、単一ノードRDBの限界を超えられる

D　SpannerはMySQLワイヤ互換ではなく、無変更移行の要件にはCloud SQLが適する

E　オフライン同期はFirestoreの機能であり、Spannerは提供しない

正解：B・D

A　垂直スケーリングは処理能力の話であり、リージョン全体の障害には無力

B（正解）　正解。複数リージョンへの分散配置により、1リージョンの喪失時も他リージョンで処理を継続できる

C　同一障害ドメイン内のバックアップはリージョン障害時に一緒に失われる可能性がある

D（正解）　正解。グローバルLBは異常リージョンを自動的に切り離し、ユーザー操作なしでフェイルオーバーを実現する

E　長いTTLは切替時に古い宛先へ誘導し続け、フェイルオーバーをむしろ阻害する

正解：B

A　99.99%のSLAは満たせるがインターネット経由のため、専用の安定した10Gbps帯域は保証できない

B（正解）　正解。Dedicated Interconnectは10Gbps/100Gbpsの専用物理接続を提供し、所定の冗長構成で99.99%SLAを満たせる

C　パートナー経由の接続で施設要件は緩いが、コロケーション接続が可能なら専用線のDedicatedの方が適切

D　GoogleのパブリックサービスとのBGPピアリングでありSLAがなく、VPCへのプライベート接続にも使えない

正解：A

A（正解）　正解。HA VPNはIPsecで暗号化され、冗長トンネル構成により99.99%のSLAを提供する低コストな接続手段

B　物理専用線は月額コストが高く、小規模拠点の要件に対して過剰

C　SLAが99.9%にとどまり冗長性の要件を満たさない。新規構築はHA VPNが推奨

D　アプリ層の暗号化だけではネットワーク層の接続・ルーティング要件を満たせない

正解：C

A　単一トンネルではSLAは99.99%にならず、静的ルートでは障害時の経路切替もできない

B　マルチリージョン化はSLA条件ではなく、同一ゲートウェイの2インターフェース利用が条件

C（正解）　正解。両インターフェースからの冗長トンネルとBGPによる動的経路制御が99.99%SLAの条件

D　本数の追加は帯域集約のためで、SLAの条件は冗長インターフェースとBGPの構成

正解：B

A　接続は可能だがインターネット経由となり、高帯域・低レイテンシの専用接続要件を満たさない

B（正解）　正解。Cross-Cloud InterconnectはGoogle Cloudと他クラウド間を専用線で直接接続するマネージドサービス

C　Google Cloud内のVPC同士を接続する機能で、他クラウドとの接続には使えない

D　CDNはコンテンツ配信のキャッシュサービスで、クラウド間のネットワーク接続機能ではない

正解：D

A　コロケーション施設でGoogleのネットワークと物理接続する必要があり、施設要件を満たせない

B　VPCへのプライベート接続には使えず、SLAも提供されない

C　Google Workspaceなどパブリックサービス向けの経路改善であり、VPC接続の手段ではない

D（正解）　正解。Partner Interconnectはサービスプロバイダ経由で50Mbps〜50Gbpsの接続を提供し、コロケーション設備なしで専用線品質を得られる

正解：A

A（正解）　正解。転送ゾーンにより特定ドメインの名前解決をオンプレミスのDNSサーバーへ委譲できる

B　ホストの増減に追従できず、スケールしない管理方法

C　社内専用の名前をインターネットに公開することになり、セキュリティ上も同期運用上も不適切

D　Google Cloud内部名の解決ができなくなり、メタデータサーバー経由の解決の仕組みも損なわれる

正解：C

A　サブネットルートはサブネット作成時に自動生成されるため、通常欠落しない

B　Cloud NATは外部向けアウトバウンド用であり、VPC内部の通信には関与しない

C（正解）　正解。VPCのイングレスは暗黙拒否がデフォルトで、defaultネットワークと異なりカスタムVPCには内部許可ルールが自動作成されない

D　ピアリングは別VPC間の接続手段であり、同一VPC内の通信には不要

正解：B

A　プロジェクト管理者が変更・削除でき、一律強制の要件を満たせない

B（正解）　正解。階層型ファイアウォールポリシーは上位階層で評価され、下位のプロジェクトで上書きできない一律の制御を実現する

C　OS内の設定は各管理者が変更でき、インフラレベルの強制にはならない

D　運用ルールだけでは技術的強制力がなく、許可ルールの追加を防げない

正解：A

A（正解）　正解。networkUserロールはサブネット単位で付与でき、共有サブネットを使ったリソース作成に必要な最小権限

B　ネットワーク全体の管理権限まで与えることになり、最小権限の原則に反する

C　プロジェクト全体の管理権限であり、サブネット利用には過剰すぎる

D　共有VPCの構成管理者用ロールであり、サブネットを利用する開発者に与えるものではない

正解：C

A　IAM管理を含む全権限を渡すことになり、最小権限の原則に反する

B　基本ロールは広範な権限の塊であり、依然として最小権限にならない

C（正解）　正解。職務に必要な権限を洗い出し、対応する事前定義ロール（不足があればカスタムロール）を付与するのが最小権限の実践

D　開発が停滞し、管理者への権限集中と作業ボトルネックという別の問題を生む

正解：B

A　事後検知はできても過剰権限そのものが残り、指摘の是正にならない

B（正解）　正解。実際に使われている権限を分析しつつ事前定義ロールへ移行するのが、業務影響を抑えた最小権限化の進め方

C　業務に必要な権限まで失われ、大規模な業務停止を招く

D　権限をさらに拡大する対応であり、指摘と逆行する

正解：A

A（正解）　正解。グループへのロール付与により、人の異動はグループのメンバー変更だけで完結し、権限の漏れと残留を防げる

B　職務に不要な権限が広く配られ、最小権限の原則に反する

C　棚卸しは有効な補完策だが、異動から反映までのタイムラグと手作業ミスは解消しない

D　ロール数が人数分に増殖し、管理負担がかえって悪化する

正解：B

A　長期キーの存在自体が漏えいリスクであり、保存場所を変えても根本解決にならない

B（正解）　正解。Workload Identity連携により外部IdPのトークンを信頼してキーレスで認証でき、長期キーの管理・漏えいリスクを排除できる

C　漏えいの影響時間は縮むが、キー配布・管理の運用負担とリスクは残る

D　個人認証情報の共有は最悪の運用であり、監査追跡も破綻する

正解：C

A　長期キーの配布は漏えいリスクが高く、誰が使ったかの追跡も困難

B　常時特権の保有は最小権限に反し、誤操作・侵害時の影響が最大化する

C（正解）　正解。iam.serviceAccountTokenCreatorによる権限借用なら、キーなしで一時的に特権を行使でき、監査ログに実行者が記録される

D　共有アカウントは操作者の特定ができず、認証情報管理も破綻する

正解：A

A（正解）　正解。IAM条件のexpressionで日時条件を指定すれば、期限を過ぎたバインディングは自動的に無効になり削除漏れがない

B　人手による削除は失念のリスクがあり、技術的な保証がない

C　なりすましと同義であり、監査証跡・責任分界の観点で論外

D　データの複製が組織外に残り、アクセス制御と追跡が不可能になる

正解：D

A　不要な権限が含まれたままになり、最小権限の徹底ができない

B　プロジェクト全リソースの閲覧権限まで付与され、範囲がさらに広がる

C　定常業務のたびに手作業が発生し、運用が破綻しやすい

D（正解）　正解。事前定義ロールが過剰な場合は、必要権限のみのカスタムロールを定義するのが最小権限の実現手段

正解：B

A　事後検知はできるが、追加そのものを技術的に防止できない

B（正解）　正解。許可したドメイン（Cloud Identity/Workspace）のプリンシパル以外のIAM追加を組織全体でブロックできる

C　人的な注意喚起には強制力がなく、ヒューマンエラーは再発する

D　ファイアウォールはネットワーク制御であり、IAMポリシーへのメンバー追加は制御できない

正解：C

A　検出は事後対応であり、作成そのものを防げない

B　テンプレートは初期値にすぎず、利用者による外部IP付与を禁止できない

C（正解）　正解。この組織ポリシー制約により外部IP付きVMの作成を組織・フォルダ単位で技術的に禁止できる

D　経済的な抑止は強制力がなく、セキュリティ標準の担保にならない

正解：B

A　ビルド環境の差異と手作業ミスが入り込み、CIの再現性・自動化の要件を満たさない

B（正解）　正解。Cloud Buildトリガーはpushやプルリクエストを契機にビルド構成を自動実行するマネージドCIの標準手段

C　夜間バッチではpushごとの即時フィードバックが得られず、CIの目的を果たさない

D　本番環境でのビルドは障害リスクと構成汚染を招くアンチパターン

正解：C

A　手作業の昇格は履歴管理・承認・ロールバックの仕組みがなく、宣言的管理の要件を満たさない

B　時刻起動では昇格の順序性・承認ゲートを表現できない

C（正解）　正解。Cloud Deployは環境の昇格順序・承認・カナリア戦略を宣言的に定義できるマネージド継続的デリバリーサービス

D　タグはイメージの識別にすぎず、デプロイの実行・承認・戦略の管理はできない

正解：A

A（正解）　正解。DORA（DevOps Research and Assessment）の4指標はデリバリーのスループットと安定性を測る業界標準の指標群

B　レイテンシ・トラフィック・エラー・飽和度というシステム監視の4指標であり、デリバリー指標ではない

C　災害復旧の目標値であり、開発パフォーマンスの指標ではない

D　目標と主要成果による目標管理フレームワークで、特定の4指標を指す用語ではない

正解：D

A　Container Registryは廃止済みで、Artifact Registryへの移行が必須

B　イメージのバージョン管理・pull認証・スキャンなどレジストリ機能が一切なく不適

C　ソースコード用のリポジトリ（新規受付終了）であり、コンテナイメージの保管先ではない

D（正解）　正解。Artifact Registryはコンテナ・言語パッケージの統合レジストリで、Artifact Analysisによる脆弱性スキャンと統合されている

正解：B

A　作業のボトルネックが生まれるだけで、長命ブランチという根本原因が残る

B（正解）　正解。小さな変更を頻繁にトランクへ統合すればコンフリクトが小さくなり、未完成機能はフラグで本番影響を遮断できる

C　命名はコンフリクトの発生と無関係

D　統合の間隔がさらに延び、コンフリクトの規模が拡大する逆効果の施策

正解：C

A　環境差異そのものが残る限り、確認項目の追加ではすり抜けが続く

B　事後対応の改善であり、発生自体の予防にならない

C（正解）　正解。環境パリティの欠如が典型的な原因であり、IaCによる同一定義からの構築で差異を体系的に排除できる

D　検証の場を失い、障害リスクをさらに高める本末転倒な施策

正解：A

A（正解）　正解。本番相当構成への段階的な負荷テストにより、実際の限界点とボトルネック（DB・外部依存等）を事前に特定できる

B　監視は検知の手段であり、耐えられるかどうかの事前検証にならない

C　単体テストは機能の正しさの検証であり、システム全体の負荷特性は分からない

D　ボトルネックがアプリやDBにある場合は増強しても耐えられず、無駄なコストも発生する

正解：B

A　テストデータの混入や誤操作の本番影響リスクがあり論外

B（正解）　正解。公式エミュレータはローカル・CIで実サービスと同じAPIを提供し、コストなし・分離された統合テストを可能にする

C　テスト対象の動作自体が変わってしまい、統合テストの意味がない

D　実現は可能だがコストとプロビジョニング管理の負担が大きく、ローカル実行の要件にも合わない

正解：C

A　旧バージョンの環境が失われるため、切り戻しには再デプロイが必要で時間がかかる

B　停止を伴ううえ、問題発生時の切り戻しも一括作業になり遅い

C（正解）　正解。旧環境（ブルー）を残したままトラフィックのみ切り替えるため、問題時はルーティングを戻すだけで即座にロールバックできる

D　検証を経ない直接適用はリスクが高く、切り戻し手段も確保されない

正解：A

A（正解）　正解。Cloud Runはリビジョン単位のトラフィック分割を標準機能として提供し、5%→50%→100%のような段階的移行が設定だけで行える

B　DNSキャッシュにより配分が不正確になり、標準機能があるのに構成が複雑化する

C　全トラフィックが一度に新版へ向かうため、5%での検証という要件を満たさない

D　時間帯の工夫であって段階的な検証にはならず、深夜でも全ユーザーが影響を受ける

正解：B

A　停止時間が発生するうえ、失敗時はアプリとDBの両方を戻す高リスクな作業になる

B（正解）　正解。新カラム追加（expand）→両対応アプリ→データ移行→旧カラム削除（contract）の段階移行なら無停止で安全に変更できる

C　恒久的なトリガー依存は複雑性と性能劣化を残す暫定策にすぎない

D　技術的に確立された無停止移行パターンがあり、機能を断念する理由にならない

正解：C

A　分散トレーシングの収集・可視化サービスであり、対話型のAI支援機能ではない

B　ドキュメント理解を支援するGeminiベースのツールだが、クラウドコンソールの運用支援に統合されたものではない

C（正解）　正解。Gemini Cloud AssistはコンソールでGoogle Cloud環境の設計・運用・トラブルシューティングを対話的に支援するAI機能

D　アプリケーションエラーの集約・通知サービスであり、対話型の支援機能ではない

正解：A

A（正解）　正解。Migrate to Virtual Machinesは稼働中VMの継続レプリケーションとテストクローン起動を提供し、短時間のカットオーバーで移行できる

B　オブジェクトストレージ間のデータ転送サービスで、VMの移行はできない

C　データベース専用の移行サービスであり、VM全体の移行には使えない

D　手作業では台数分の工数と長い停止時間が発生し、継続レプリケーションもできない

正解：D

A　線形にスケールする保証はなく、ピーク時のボトルネックを検出できない

B　クライアント側が先に限界に達し、システムの実際の限界を測定できない

C　本番ユーザーを実験台にすることになり、事前検証の目的に反する

D（正解）　正解。GKE上のLocust等の分散負荷基盤で現実的なトラフィックパターンを再現し、SLO目標と比較するのが負荷テストの定石

正解：B

A　横断的な相関分析ができず、監視の運用負担がプロジェクト数に比例して増える

B（正解）　正解。メトリクススコープにより複数プロジェクトのメトリクスを単一のスコーピングプロジェクトから横断的に参照・アラート設定できる

C　リアルタイム性が失われ、アラートの基盤としても機能しない

D　監視のためにリソース分離・ガバナンス設計を壊すのは本末転倒

正解：C

A　インフラ指標が正常でもアプリが応答不能なケースを検出できない

B　事後の手動確認であり、リアルタイムの死活検知にならない

C（正解）　正解。稼働時間チェックは世界各地のプローブからエンドポイントを定期検査し、失敗時にアラート通知できる

D　Cloud Traceはレイテンシ分析のためのトレーシングであり、外形死活監視の機能ではない

正解：A

A（正解）　正解。ログベースの指標はログのフィルタ条件に一致するエントリ数等をメトリクス化でき、通常のアラートポリシーで監視できる

B　自前ポーリングは遅延と保守負担があり、マネージド機能で足りる

C　手動記録は漏れと遅延が避けられず、可視化・アラートの基盤にならない

D　保持期間はログの保存の話であり、集計・アラートの要件と無関係

正解：D

A　実行停止を伴うデバッグは本番サービスに深刻な影響を与える

B　リクエスト間のレイテンシ分析が目的であり、関数単位のCPU消費のプロファイルは取得できない

C　計測コードの追加はオーバーヘッドと保守負担が大きく、網羅性も低い

D（正解）　正解。Cloud Profilerは低オーバーヘッドの継続的プロファイリングでCPU・メモリ消費を関数単位で可視化する

正解：B

A　リソース使用率からはリクエスト単位の呼び出し経路と所要時間の内訳は分からない

B（正解）　正解。分散トレーシングはリクエストがまたぐ各サービスの処理時間をスパンとして可視化し、ボトルネック区間を特定できる

C　例外の集約サービスであり、正常リクエストのレイテンシ内訳は分析できない

D　全体時間は分かるが、内部のどのサービスが遅いかの内訳は得られない