問題集 セクション1：アクセスの構成
Google Cloud Professional Cloud Security Engineer のセクション1「アクセスの構成」をシナリオ形式で固める問題集。
使い方
- 全 15 問。本番に近いシナリオ形式が中心。
- 形式：単一選択（4択）12 問 ＋ 複数選択（2つ選べ）3 問。
- まず自力で解答 →
▶ 正解と解説を開いて答え合わせ。 - 解説の「なぜ他の選択肢がダメか（❌）」まで必ず読むこと。
- 目標正答率：80%（15問中12問）以上。
難易度
- 📘 基礎：Q1・Q5・Q9・Q13
- 🔧 応用：Q2・Q3・Q6・Q8・Q11・Q12・Q14
- 🎯 発展：Q4・Q7・Q10・Q15
Q1 📘 単一選択
スタートアップが GCP に組織を作り、最初の IAM 戦略を考えている。Google が推奨するベストプラクティスとして最も適切なものはどれか。
- A. すべての社員に
roles/ownerを付与し、運用速度を優先する - B. 各社員に個別に事前定義ロールを直接付与する
- C. Google グループに事前定義ロールを最小権限で付与し、社員はグループに所属
- D. サービスアカウントの鍵ファイルを社員に配布し、その鍵で操作させる
▶ 正解と解説
正解：C
解説： IAM ベストプラクティスは「最小権限」+「Google グループへの付与」。グループに付与すれば、異動・退職時はメンバー変更だけで権限管理が完結。
- ❌ A：基本ロール（Owner / Editor）は広すぎて非推奨
- ❌ B：個人付与は管理破綻、退職時の剥奪漏れリスク
- ❌ D：SA 鍵を人間に配るのはアンチパターン
Q2 🔧 単一選択
CI/CD パイプライン（GitHub Actions）から GCP の Cloud Run へデプロイしたい。サービスアカウント鍵をリポジトリに置きたくない。最適な方式は？
- A. SA 鍵 JSON を GitHub Secrets に保管し、ワークフローで参照
- B. Workload Identity Federation を構成し、GitHub Actions の OIDC トークンで SA を impersonate
- C. 個人開発者の Cloud Identity アカウントを共有して使う
- D. SA を Cloud Functions として実装し、HTTP 経由で呼び出す
▶ 正解と解説
正解：B
解説： Workload Identity Federation は CI/CD から GCP API を呼ぶ際に鍵を一切配布しない正解パターン。GitHub の OIDC トークンを GCP の Workload Identity Pool で検証し、対象 SA を impersonate。
- ❌ A：鍵を Secrets に置いてもローテーション・漏洩管理の負担、ベストプラクティス違反
- ❌ C：人間アカウントの共有は監査不能・退職時に詰む
- ❌ D：Cloud Functions 化は本質的な解決ではない（結局誰かが認証する必要）
Q3 🔧 単一選択
組織全体で「storage.buckets.delete 権限を絶対に行使できないようにしたい」。Owner ロールを持つ管理者でも削除できないように設計したい。使うべき機能は？
- A. すべてのバケットに retention policy + bucket lock を設定
- B. 組織レベルで IAM Deny ポリシーで
storage.buckets.deleteを Deny - C. Owner ロールを誰にも付与しない
- D. Organization Policy で
compute.disableSerialPortAccessを有効化
▶ 正解と解説
正解：B
解説： IAM Deny ポリシー は Allow より強い。組織レベルで Deny を設定すれば、Owner でも実行不可。
- ❌ A：個別バケットを保護できるがバケット削除以外の権限管理にはならず、適用範囲も限定
- ❌ C：運用上不可避な場面でも Owner が必要になることがあり、現実的でない
- ❌ D：シリアルポートアクセスとは無関係
Q4 🎯 複数選択（2 つ選べ）
開発者が本番環境の SA を必要時のみ短時間 impersonate して操作したい。設計に必要な仕組みを 2 つ選べ。
- A. 開発者に
roles/iam.serviceAccountTokenCreatorを本番 SA に付与 - B. 開発者に
roles/ownerを組織レベルで付与 - C. Privileged Access Manager (PAM) で時間制限付き Entitlement を構成
- D. 本番 SA の鍵を開発者に配布
▶ 正解と解説
正解：A・C
解説： Impersonate に必要なのは serviceAccountTokenCreator（User は SA をリソース割り当て時のみ）。さらに PAM で時間制限付き昇格を組み合わせれば JIT アクセスが実現。
- ❌ B：Owner を付けたら最小権限の原則に違反
- ❌ D：鍵配布は禁忌
Q5 📘 単一選択
スーパー管理者（Super Admin）アカウントの推奨運用は？
- A. 日常業務に使う
- B. 通常運用には別アカウント（Organization Admin など）を使い、緊急用に複数人で分散保管、ハードウェアキーで保護
- C. 全管理者で共有する 1 つのアカウントとして使う
- D. 自動化スクリプトで定期実行する SA 化する
▶ 正解と解説
正解：B
解説： スーパー管理者は組織全体への絶対権限を持つため、緊急時専用の break-glass として複数人に分け、必ず ハードウェアセキュリティキー で保護。日常業務には組織管理者ロールを持つ別アカウントを使う。
- ❌ A：絶対権限を日常利用するのはリスク過大
- ❌ C：共有アカウントは監査不能
- ❌ D：SA 化はそもそも認可モデル違反（人間用のため）
Q6 🔧 単一選択
「業務時間内・日本 IP・企業端末からのみ Cloud Console にアクセス」を実現したい。組み合わせとして最適は？
- A. IAM Condition のみ
- B. Access Context Manager で Access Level を定義し、IAM Condition でそれを参照
- C. VPC Service Controls のみ
- D. Cloud Armor の地理ブロック
▶ 正解と解説
正解：B
解説： Access Context Manager で「時間 × IP × デバイス」の Access Level を定義し、IAM Condition で参照するのが BeyondCorp の標準。
- ❌ A：IAM Condition だけだと再利用性低、Access Level なしでは複合条件が表現しづらい
- ❌ C：VPC SC はサービス境界の話で、Console アクセス制御とは別レイヤ
- ❌ D：Cloud Armor は L7 公開 LB 向けで Console には適用されない
Q7 🎯 単一選択
組織全体で IAM ポリシー上「90 日間アクセスしていない権限を棚卸して削減提案を得たい」。使うツールは？
- A. Policy Troubleshooter
- B. IAM Recommender
- C. Policy Analyzer
- D. Cloud Audit Logs
▶ 正解と解説
正解：B
解説： IAM Recommender は 90 日間使われていないロールを検出し、より絞った推奨ロールを提案する。
- ❌ A：Policy Troubleshooter は「なぜ Bob が deny されたか」を診断する別ツール
- ❌ C：Policy Analyzer は「誰が何にアクセスできるか」の検索
- ❌ D：Audit Log はイベント記録、自動提案はしない
Q8 🔧 複数選択（2 つ選べ）
外部の委託会社の従業員に、その会社の Okta アカウントで GCP コンソールに期限付きアクセスさせたい。組み合わせは？
- A. Workforce Identity Federation で Okta と連携
- B. Workload Identity Federation で Okta と連携
- C. IAM Condition で期限を指定（
request.time < timestamp("2026-12-31T23:59:59Z")） - D. SA 鍵を Okta 経由で配布
▶ 正解と解説
正解：A・C
解説： 委託会社の 人間 ユーザーには Workforce Identity Federation（Cloud Identity ライセンス不要）。期限は IAM Condition で表現。
- ❌ B：Workload は マシン 向け
- ❌ D：SA 鍵配布は禁忌、しかも委託会社の人間に SA は不適切
Q9 📘 単一選択
GCP の組織階層の正しい順序は？
- A. 組織 → プロジェクト → フォルダ → リソース
- B. 組織 → フォルダ → プロジェクト → リソース
- C. ドメイン → 組織 → プロジェクト → リソース
- D. フォルダ → 組織 → プロジェクト → リソース
▶ 正解と解説
正解：B
解説： 組織 → フォルダ → プロジェクト → リソース。IAM や組織ポリシーは上位から下位に 継承 される。
Q10 🎯 単一選択
組織内のすべての GCP プロジェクトで「サービスアカウント鍵の作成」を全面禁止したい。最も適切な手段は？
- A. 個別プロジェクトで IAM Deny ポリシーで
iam.serviceAccountKeys.createを Deny - B. 組織ポリシー
iam.disableServiceAccountKeyCreationを Enforce - C. すべてのプロジェクトの Owner ロールを剥奪
- D. SCC のカスタム検出器で鍵作成を検出してアラート
▶ 正解と解説
正解：B
解説： 組織ポリシー iam.disableServiceAccountKeyCreation を組織レベルで Enforce することで、配下すべてのプロジェクトに強制可能。
- ❌ A：プロジェクトごとに Deny を作る運用は煩雑、また組織ポリシーで一括可能
- ❌ C：Owner なしでは運用不能
- ❌ D：検出は事後対応、防止策ではない
Q11 🔧 単一選択
「Bob がなぜ secret-foo を読めないのか」を診断したい。使うツールは？
- A. IAM Recommender
- B. Policy Troubleshooter
- C. Policy Analyzer
- D. Security Command Center
▶ 正解と解説
正解：B
解説： Policy Troubleshooter はプリンシパル・リソース・パーミッションを指定し、なぜ Allow/Deny されたかを評価結果で説明する。
- ❌ A：Recommender は余剰権限の検出
- ❌ C：Analyzer は「誰が何にアクセスできるか」の網羅検索
- ❌ D：SCC は脅威/構成検出のダッシュボード
Q12 🔧 単一選択
開発者に SA を VM に 割り当てる ことだけを許可し、SA トークンを発行する権限は与えたくない。付与するロールは？
- A.
roles/iam.serviceAccountUser - B.
roles/iam.serviceAccountTokenCreator - C.
roles/iam.serviceAccountKeyAdmin - D.
roles/owner
▶ 正解と解説
正解：A
解説： serviceAccountUser = SA をリソース（VM / Cloud Run 等）に割り当てる権限。serviceAccountTokenCreator = トークン発行（impersonate）権限で、別物。
- ❌ B：トークン発行までできてしまう
- ❌ C：鍵管理権限。論外
- ❌ D：Owner は広すぎる
Q13 📘 単一選択
全社員に強制すべき 最も強い MFA 方式はどれか。
- A. SMS 認証
- B. TOTP（Authenticator アプリ）
- C. ハードウェアセキュリティキー（FIDO / WebAuthn）
- D. メール認証
▶ 正解と解説
正解：C
解説： ハードウェアセキュリティキー は フィッシング耐性 が最も高く、特権アカウントには必須レベル。SMS は SIM スワップに弱く、メール認証は GCP では使えない。
Q14 🔧 単一選択
「自社ドメイン（example.com）以外のユーザーには絶対に IAM 付与できない」を全プロジェクトに強制したい。組織ポリシーは？
- A.
iam.allowedPolicyMemberDomains - B.
gcp.resourceLocations - C.
iam.disableServiceAccountKeyCreation - D.
iam.automaticIamGrantsForDefaultServiceAccounts
▶ 正解と解説
正解：A
解説： iam.allowedPolicyMemberDomains で許可ドメインを列挙すれば、それ以外のメンバーに IAM 付与しようとした時点で失敗する。
Q15 🎯 複数選択（2 つ選べ）
開発者の常時保有特権をなくし、必要時のみ承認制で時間制限の特権付与を実現する設計の要素を 2 つ選べ。
- A. Privileged Access Manager (PAM) で Entitlement / 承認者を定義
- B. すべての権限を IAM Condition で
request.time制限 - C. SA 鍵ファイルを開発者の個人 PC に置き、必要時にのみ復号
- D. Audit Logs で昇格イベントの記録を有効化（Admin Activity）
▶ 正解と解説
正解：A・D
解説： PAM で JIT 昇格、Audit Logs で「誰がいつ昇格したか」を記録するのが標準。
- ❌ B：IAM Condition の時間制限だけでは "申請・承認" の概念がない
- ❌ C：SA 鍵を開発者 PC に置くのは典型的アンチパターン
採点と振り返り
- 12 問以上正解：合格圏。次のセクションへ
- 9〜11 問：要復習。誤答箇所を 02_応用.md と 03_要点と暗記.md で復習
- 8 問以下：01_基礎.md からやり直し