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・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　コントロールプレーンまで自己管理となり、要件と正反対

正解：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（正解）　正解。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はゾーン名を指定するフラグであり、状態での絞り込みには使えない

正解：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付与のコマンドではない