GCP ACE サンプル問題

正解：C

A　階層が逆。プロジェクトは階層の最下位で、その配下に置けるのはVMやバケットなどのリソースのみ

B　フォルダは課金専用の概念ではなく、部門やチームごとの階層化とポリシー継承の単位。課金は請求先アカウントが担う

C（正解）　正解。組織ノードが最上位で、フォルダで部門などを階層化し、プロジェクトが実リソースを収容する。IAMや組織ポリシーはこの階層を通じて継承される

D　最上位は常に組織リソース。フォルダは組織の配下にのみ作成できる

正解：A

A（正解）　正解。フォルダレベルで付与したIAMロールは配下の全プロジェクトに継承されるため、1回の設定で済み、プロジェクト追加時も自動で適用される

B　動作はするが管理コストが最大になる。メンバーやプロジェクトが増えるたびに設定作業が必要で、付与漏れや剥奪漏れの温床になる

C　組織レベルの付与は他部門のプロジェクトまで見えてしまい、最小権限の原則に反する

D　オーナーは過剰権限であり、閲覧権限の一括付与という要件も満たさない

正解：B

A　IAMは誰が操作できるかの制御であり、許可された管理者が外部IP付きVMを作ることは防げない。構成そのものの制約には組織ポリシーを使う

B（正解）　正解。組織ポリシーはリソース構成に対するガードレールで、この制約により配下の全プロジェクトで外部IPの付与を一括して禁止できる

C　ファイアウォールは通信の制御であり、外部IPの付与自体は防げない。全拒否は正当な通信まで止めてしまう

D　予算アラートはコスト通知の仕組みで、構成の強制やIP付与の検知はできない

正解：D

A　事後的な確認であり強制力がない。国外リージョンへの作成そのものは防げない

B　CLIの既定値を変えるだけで、ユーザーが明示的に他リージョンを指定すれば作成できてしまう

C　検知はできても作成自体を防げない。予防的な強制には組織ポリシーが必要

D（正解）　正解。組織ポリシーのgcp.resourceLocations制約により、指定したリージョン以外へのリソース作成をAPIレベルで拒否できる

正解：A

A（正解）　正解。組織ポリシーはリソース構成に対する制約(外部IP禁止など)を課し、IAMはプリンシパルへのロール付与でアクセスを制御する。両者は補完関係にある

B　役割が異なるため置き換え関係にはない。組織ポリシーで個々のユーザーに権限を与えることはできない

C　どちらも組織・フォルダ・プロジェクトの各レベルで設定でき、階層を通じて継承される

D　課金上限の機能ではない。コスト管理は予算とアラートで行う(それでも強制停止はされない)

正解：C

A　プロジェクトIDは作成時に確定し、以後変更できない。変更できるのはプロジェクト名のほう

B　一意性が求められるのはプロジェクトIDで、プロジェクト名は重複してもよい表示用の文字列

C（正解）　正解。プロジェクトIDはグローバル一意で作成後は変更不可。表示用のプロジェクト名はいつでも変更できる

D　プロジェクト番号はGoogleが自動採番する識別子で、利用者は指定も変更もできない

正解：B

A　作り直しても新規プロジェクトでは多くのAPIが既定で無効のため、同じエラーになる

B（正解）　正解。gcloud services enable compute.googleapis.comまたはコンソールのAPIライブラリから有効化すれば利用できるようになる

C　権限不足ではなくAPI未有効が原因。オーナーであってもAPIが無効なら同じエラーになる

D　組織ポリシーとAPIの有効化は別の仕組み。全ポリシーの無効化はガードレールを失わせる危険な操作

正解：D

A　プロジェクト削除には猶予期間があり、即時に完全消去されるわけではない

B　猶予期間内であれば利用者自身がコンソールやgcloudで復元操作を実行できる

C　猶予期間内の復元はプロジェクト全体が対象。ただし一部リソースは削除処理が先行して失われる場合がある

D（正解）　正解。プロジェクトは削除後30日間は保留状態にあり、この間はgcloud projects undeleteなどで復元できる

正解：A・C

A（正解）　正解。compute.vmExternalIpAccess制約により外部IP付きVMの作成を一括で禁止できる

B　個人への権限付与はIAMの役割。組織ポリシーは構成の制約であり権限は与えられない

C（正解）　正解。gcp.resourceLocations制約で許可ロケーションを限定できる

D　課金を強制停止する機能は組織ポリシーにも予算にも存在しない

E　パッチ適用はVM Managerの機能であり、組織ポリシーの守備範囲ではない

正解：B・D

A　予算に自動停止のオプションは存在しない。停止したい場合はPub/Sub通知を受けて自前で実装する必要がある

B（正解）　正解。予算アラートは実績(または予測)がしきい値へ達した時点で通知を送る基本の仕組み

C　支払い手段の変更であり、コスト急増の検知には寄与しない

D（正解）　正解。Pub/Sub連携により課金状況をプログラムで受信でき、チャットへの通知や自動対応に発展させられる

E　コストは抑えられてもサービスが動かなくなり、検知の仕組みでもない

正解：B

A　VMの管理(OSパッチ、スケール設定)が必要で、ゼロスケールもできない

B（正解）　正解。コンテナをフルマネージドで実行し、リクエスト量に応じてゼロからの自動スケールが可能。インフラ管理が不要

C　ノードの運用管理が残る。K8sの機能を直接使う要件がなければ過剰

D　オブジェクトストレージであり、コンテナのAPIサーバーを実行する基盤ではない

正解：C

A　単機能のイベント駆動コードを動かすサービスで、K8sマニフェスト資産は利用できない

B　独自のアプリ実行基盤でありKubernetes APIは提供しない

C（正解）　正解。マネージドKubernetesとして標準APIを提供し、既存のマニフェストやHelmチャートをそのまま適用できる

D　マネージドのリレーショナルデータベースであり、コンテナ実行基盤ではない

正解：A

A（正解）　正解。VMを直接制御できるIaaSであり、OSの選択・カーネル設定・ミドルウェア構成まで自由に扱える

B　コンテナのサンドボックス内で動作するためカーネルモジュールの導入やOSチューニングはできない

C　コード実行環境が固定されておりOSへのアクセスはできない

D　分析用データウェアハウスでありソフトウェアの実行基盤ではない

正解：D

A　イベントが少なくてもVM費用が発生し続け、ポーリング実装も必要で非効率

B　クラスタとノードの常時コストがかかり、単機能処理には過剰

C　Cloud SQLのトリガーはDB内のデータ変更に対するもので、Cloud Storageのイベントは扱えない

D（正解）　正解。オブジェクトの作成イベントで関数を起動でき、実行時間分だけの課金で済むイベント駆動処理の典型構成

正解：B

A　ノードプールの設計・管理は利用者の責任で、課金もノード(VM)単位。細かな制御が必要な場合に選ぶ

B（正解）　正解。Autopilotはノード管理をGoogleが担い、Podのリソースリクエストに基づく課金になる。運用負荷を最小化したい場合の既定の選択肢

C　ハイブリッド/マルチクラスタ管理向けの構成で、ノード管理を任せたいという要件の答えではない

D　コントロールプレーンまで自己管理となり、要件と正反対

正解：C

A　物理サーバー専有はむしろ割高で、コスト削減の要件に逆行する

B　常時稼働が前提の割引であり、夜間バッチだけの利用では確約分が無駄になる

C（正解）　正解。Spot VMは大幅な割引価格で利用でき、プリエンプト(強制停止)を許容できる再実行可能なバッチ処理に最適

D　大容量メモリ向けの高価なファミリーであり、コスト削減にならない

正解：A

A（正解）　正解。Spot VMは余剰容量を安価に使う仕組みで、事前通知の後プリエンプトされ得る。SLA対象外のため中断耐性のある処理に限定して使う

B　Spot VMはSLAの対象外。可用性保証が必要なワークロードには通常VMを使う

C　稼働時間の保証はなく、割引率はむしろ非常に大きい(この保証があったのは旧プリエンプティブルVMでもない)

D　Spot VMはライブマイグレーションされず、プリエンプト時は停止される

正解：B

A　不要なvCPUの分まで課金され、費用効率が悪い

B（正解）　正解。カスタムマシンタイプはvCPUとメモリを個別に指定でき、標準比率を超えるメモリは拡張メモリオプションで追加できる

C　別VMのメモリはプロセスから直接は使えない。アプリを分散対応させる大工事になる

D　スワップはメモリより桁違いに遅く、インメモリ処理の要件を満たさない

正解：D

A　日常的な汎用ワークロード向けでメモリ搭載量の上限が小さい

B　高クロックCPU性能向けのファミリーで、数百GB級のメモリ要件が主眼の場合は適さない

C　スケールアウト型のコスト効率重視ファミリーで、大容量メモリの単一ノード要件には合わない

D（正解）　正解。M系はテラバイト級までの大容量メモリを提供するファミリーで、インメモリDBの推奨選択肢

正解：B

A　VMはゾーンリソースであり、必ずいずれかのゾーンに配置される

B（正解）　正解。gcloud compute instances createでは--zone指定(または構成の既定ゾーン)により配置先ゾーンが決まる

C　グローバルリソースなのはイメージやスナップショットなど。VM本体はゾーンに属する

D　ゾーン間の移動は無停止ではできない(スナップショットやマシンイメージから移行先ゾーンで再作成する。なおgcloud compute instances moveコマンドは非推奨)

正解：C

A　自動化の要件を満たさず、オートスケール環境では現実的でない

B　仕込むためには一度手動設定が必要で、初回起動時の自動実行にならない

C（正解）　正解。--metadata startup-script=...や--metadata-from-fileで起動スクリプトを渡せば、起動時に自動実行される。テンプレートに含めればMIGでも機能する

D　タイミング依存で不確実。VM自身の起動処理として実行する標準機構がstartup-script

正解：A

A（正解）　正解。インスタンステンプレートはイミュータブルで編集できない。新テンプレートを作成し、MIGの更新(ローリング更新など)で切り替える

B　テンプレートを編集するコマンドは存在しない。イミュータブルであることが仕様

C　既存VMを変えてもテンプレート定義は変わらず、新規VMは古い構成で起動してしまう

D　削除してもVMは変わらない。そもそも使用中テンプレートの扱いには注意が必要

正解：D

A　手動運用では負荷追従が遅れ、夜間の消し忘れなどコスト面の無駄も出る

B　マシンタイプの自動変更(垂直スケール)機能はCompute Engine単体にはなく、スケールアウトの要件にも合わない

C　非マネージドインスタンスグループはオートスケーリング非対応。自動増減にはMIGが必要

D（正解）　正解。テンプレート→マネージドインスタンスグループ(MIG)→オートスケーリングポリシー(CPU使用率など、min 2/max 10)という標準構成

正解：B

A　台数が増えてもハングしたVMはそのまま残る。不健全なVMの置き換えには自動修復が必要

B（正解）　正解。ヘルスチェックに失敗したVMをMIGが自動で再作成する。OSは生きているがアプリが死んでいる状態を検出するにはアプリ層のチェックを使う

C　プリエンプトの有無とプロセスハングの復旧は無関係

D　ディスクのバックアップ機能であり、稼働状態の監視・復旧はしない

正解：C

A　同一ゾーンに何台あってもゾーン障害では全滅する

B　復旧素材は増えるが、サービス継続(可用性)そのものは実現しない

C（正解）　正解。リージョンMIGはリージョン内の複数ゾーンにVMを分散し、1ゾーンの障害でも残りのゾーンでサービスを継続できる

D　性能の変更であり、ゾーン障害への耐性は変わらない

正解：A

A（正解）　正解。OS LoginはSSHアクセスをIAMロールと連動させ、GoogleアカウントベースでLinuxアカウントと鍵を自動管理する。プロジェクト全体にもVM単位にも設定できる

B　鍵の配布・失効を手作業で管理し続けることになり、要件と逆行する

C　監査不能なパスワード共有はセキュリティ上の禁じ手

D　シリアルコンソールは緊急時のデバッグ用アクセスであり、日常のSSH管理の仕組みではない

正解：D

A　ログインは可能だが管理者権限(sudo)は付与されない

B　リソース情報の閲覧のみで、VMへのログイン自体ができない

C　サービスアカウントの利用に関するロールで、OS Loginのsudo可否とは別。VMにSAが付いている場合に併用が必要になることはある

D（正解）　正解。osAdminLoginは管理者権限(sudo)付きのログインを許可するロール。一般ユーザーにはosLoginを使い分ける

正解：B

A　台数が増えると破綻する。適用状況の把握もできない

B（正解）　正解。VM ManagerはOSインベントリの収集、パッチのコンプライアンス確認、パッチジョブのスケジュール実行をフリートに対して提供する

C　コンテンツ配信のキャッシュ機能でありパッチ管理とは無関係

D　スナップショットはバックアップでありOSの更新は行われない

正解：C

A　メンテナンス時にVMが停止される設定で、要件と逆

B　障害停止後に自動起動しなくなるだけで、メンテナンス時の挙動は改善しない

C（正解）　正解。ライブマイグレーションは稼働中のVMを別ホストへ無停止で移動する既定の仕組み。GPUやSpot VMなど一部構成では利用できない点に注意

D　Spot VMはむしろプリエンプトで停止され得る構成であり、継続稼働の要件に反する

正解：A

A（正解）　正解。gcloud compute disks create→instances attach-diskの後、OS内でmkfs(初回のみ)とmountを行い、永続化するならfstabに追記する

B　ブランクディスクのフォーマットとマウントはOS側での作業が必要。自動では使える状態にならない

C　永続ディスクは稼働中のVMにオンラインでアタッチできるため、削除は不要

D　バケットはオブジェクトストレージであり、ブロックデバイスとしてはアタッチできない(gcsfuseはファイルシステム風の別物)

正解：B

A　kubeconfigを手動で書くコマンドで、GKEの認証情報や証明書を自動設定してはくれない

B（正解）　正解。クラスタのエンドポイントと認証情報を取得してkubeconfigを構成し、以後kubectlで操作できるようになる

C　gcloud自体の認証であり、kubeconfigへのクラスタ登録は行われない

D　接続確認のコマンドであり、先に認証情報の設定が済んでいなければ失敗する

正解：C

A　ノードを増やしてもコントロールプレーンは単一ゾーンのままで、そのゾーン障害時にはAPI操作ができなくなる

B　アプリの二重デプロイや切り替え運用が必要になり、標準機能で済む要件に対して過剰な自作になる

C（正解）　正解。リージョンクラスタはコントロールプレーンとノードを複数ゾーンに複製し、単一ゾーン障害でも運用を継続できる

D　モードの選択と可用性構成は別の軸。なおAutopilotクラスタはリージョンクラスタとして作成される

正解：B

A　手動の鍵管理そのもので、そもそも書き込むためのアクセス手段が先に必要になる

B（正解）　正解。gcloud compute sshやブラウザ内SSHは鍵の生成・伝搬を自動で処理するため、手動の鍵管理なしで接続できる

C　telnetは平文で危険な上、既定で開いてもいない

D　シリアルコンソールはブートやネットワーク障害時の緊急手段であり日常の接続方法ではない

正解：C

A　その瞬間に方針違反となり、付け外しの運用も事故のもと

B　ピアリングはGoogle CloudのVPC同士の接続機能で、自宅や任意の端末との接続には使えない

C（正解）　正解。IAPトンネル経由なら外部IPなしのVMへIAMで認可されたユーザーだけがSSHでき、踏み台も不要。35.235.240.0/20からの上り許可が必要

D　Cloud NATはVMからの外向き通信専用で、外からVMへの接続はできない

正解：A

A（正解）　正解。スナップショットスケジュールは取得の時刻・頻度と保持期間を定義でき、ディスクに割り当てるだけで自動運用になる

B　自前運用は可能だがVM障害時に動かず、標準機能があるのに自作するのは保守性が低い

C　Cloud Storageの機能であり、永続ディスクのスナップショットには適用されない

D　同期レプリカによる冗長化であり、世代管理されたバックアップの代替にはならない

正解：D

A　毎回フルで保存されるわけではない。スナップショットは増分方式

B架空　そのようなサービスは実在しない。スナップショットは追加契約なしで世代管理できる

C　世代数の上限はスケジュールの保持設定で決めるもので、7世代という固定制限はない

D（正解）　正解。スナップショットは増分バックアップで、変更ブロックだけを保存する。参照されなくなったブロックは世代削除時に整理される

正解：B

A　起動のたびに構成時間がかかり、バージョン固定・再現性の面でもイメージ方式に劣る

B（正解）　正解。カスタムイメージで標準構成を配布し、イメージファミリーを指定すれば利用者は常に最新の非推奨でないイメージを自動的に参照できる

C　スナップショットは復元用途で、イメージのような最新版管理(ファミリー)の仕組みがない

D　社内配布にマーケットプレイス公開は不要で、イメージ共有はIAMで行える

正解：C

A　describeは単一インスタンスの詳細表示コマンドで、一覧のフィルタ表示には使えない

B　ゾーンの一覧でありインスタンスは表示されない

C（正解）　正解。instances listにフィルタ式を与えれば状態で絞り込める。表示列は--formatで調整できる

D　--zonesはゾーン名を指定するフラグであり、状態での絞り込みには使えない

正解：A

A（正解）　正解。vCPUとメモリの課金は停止で止まるが、ディスクの保存容量と未使用または停止中VMに予約された静的外部IPは課金が継続する

B　停止中のvCPU/メモリは課金されない。課金が残るのはディスクやIPなどの付随リソース

C　遅延ではなく、停止中も課金対象のリソースが実在する

D　停止操作自体への手数料は存在しない

正解：B

A　マシンタイプ変更は停止中のVMにしか実行できず、稼働中に実行するとエラーになる

B（正解）　正解。set-machine-typeは停止状態が前提。永続ディスクのデータは停止・再起動で失われない

C　削除は不要。停止すればマシンタイプはその場で変更できる

D　ライブマイグレーションはホスト保守時の移動であり、マシンタイプは変わらない

正解：C

A　ノードVMの一覧は見られるがPodの状態はわからない

B　調査の前に全Podを消すのは乱暴で、原因究明の手がかりも失う

C（正解）　正解。get podsでSTATUS・RESTARTS・NODEを俯瞰し、describeでイベントや失敗理由を確認するのが定石の初動

D　最終手段であり、初動の調査ステップとして不適切

正解：A

A（正解）　正解。ノードプールはマシン構成ごとのノード集合で、gcloud container node-pools createでGPU付きプールを追加すれば既存プールと共存できる

B　ノードプールのマシン構成は後から編集できない。構成を変えたい場合は新プールを作って移行する

C架空　そのようなツールは実在しない。GPUはノード作成時の構成で決まる

D　既存ワークロードを残す要件に反する。ノードプール追加で十分

正解：B

A　ロールの種類と課金は無関係。問題はコストではなく権限の広さ

B（正解）　正解。editorなどの基本ロールはサービス横断の数千の権限を含む。業務に必要な事前定義ロールへ置き換えるのが推奨

C　基本ロールに自動失効はない。期限を付けたい場合はIAM Conditionsを使う

D　付与自体は可能(そして同様に非推奨)。制約の問題ではない

正解：C

A　全サービスに及ぶ基本ロールで過剰

B　カスタムロールは維持管理の負担があるため、まず要件に合う事前定義ロールを探すのが順序

C（正解）　正解。roles/compute.instanceAdmin.v1など、サービスごとに用途別の事前定義ロールが用意されておりGoogleが権限セットを保守してくれる。要件に合うものがなければカスタムロールを検討する

D　閲覧のみで起動・停止の要件を満たさない

正解：A

A（正解）　正解。カスタムロールはcompute.instances.list/start/stopのような個別権限を選んで構成できる。事前定義ロールで足りない粒度の要件に使う

B　技術的に作成・削除が可能なままで、ルール頼みは監査要件を満たさない

C　ownerが含まれる時点で全権となり、粒度の制御と正反対

D　OS内の権限ではGoogle CloudのAPI操作(起動・停止)を制御できない

正解：D

A　IAM変更は通常数分内に反映される。30日もかかることはない

B　ロールのバインディングはいつでも削除できる

C　画面キャッシュで実際のAPIアクセスが通り続けることはない

D（正解）　正解。IAMポリシーは上位からの継承の和で評価される。上位で付与された権限は下位の設定変更では取り消せないため、付与元の階層を確認する

正解：B

A　カスタムロールを新規作成するコマンドであり、既存ロールの付与ではない

B（正解）　正解。add-iam-policy-bindingでプリンシパルとロールのバインディングをプロジェクトのIAMポリシーへ追加する

C　set-iam-policyはポリシー全体をファイルで置き換える操作で、引数も誤り。誤用すると既存の権限を消しかねない

D　authはgcloud自体の認証管理でIAM付与のコマンドではない

正解：C

A　VMの一覧でありIAM情報は含まれない

B　申告は不正確になりがちで監査の証跡にもならない

C（正解）　正解。get-iam-policyはメンバーとロールのバインディングを一覧出力でき、棚卸しやレビューの基本手段になる

D　実際のアクセスの記録であり、付与されている権限の一覧とは別物

正解：A

A（正解）　正解。IAM Recommenderは過去の権限使用状況を分析し、未使用権限の多いバインディングに対しより狭いロールへの置き換えを提案する

B　アプリのCPU/メモリ使用を分析する性能ツールで、IAMの分析はしない

C　コスト通知の機能で権限とは無関係

D　外形監視の機能で権限とは無関係

正解：B

A　人手頼みでは削除漏れが起きる。技術的に失効させる仕組みがある

B（正解）　正解。条件付きバインディングは指定日時以降アクセスを自動的に無効化でき、剥奪漏れを防げる

C　キーの配布は漏えいリスクが高く、期限管理の問題も解決しない

D　外部者にオーナーは論外で、期限の要件も満たさない