Q1. ある組織の一般的なネットワークおよびセキュリティのレビューは、アプリケーションの通信経路、リクエストの処理、ファイアウォールルールの分析で構成されています。
この組織は、開発チームがこの完全なレビューの負担を負うことなく、新しいアプリケーションをデプロイできるようにしたいと考えています。
この組織にどのように助言すべきですか？
A. Forseti をファイアウォールフィルタと組み合わせて使用し、本番環境で不要な構成を検出する。
B. Infrastructure as Code（IaC）の使用を義務付け、ポリシーを強制するために CI/CD パイプライン内で静的解析を提供する。
C. すべての VPC トラフィックをカスタマー管理のルーター経由でルーティングし、本番環境で悪意あるパターンを検出する。
D. すべての本番アプリケーションはオンプレミスで実行する。
GCP は開発・QA プラットフォームとして扱い、開発者に自由な権限を与える。
回答
- B. Infrastructure as Code（IaC）の使用を義務付け、CI/CD パイプライン内で静的解析を提供する。
-
毎回の手動レビューは開発の重い負担になるため、インフラをコード化（IaC）し、CI/CDパイプライン内の静的解析で自動的にポリシー違反を検出する手法が最適です。デプロイ前に自動でセキュリティとコンプライアンス基準を検証できるため、開発速度を保ちながら統制を維持できます。ForsetiやVPCルーター経由の検査は本番環境での事後検出にとどまり、予防的な統制にはなりません。試験では、レビューを自動化しガードレールを前倒しで適用する「シフトレフト」の考え方として、IaC＋パイプライン内ポリシーチェックが正答になる点を押さえましょう。
Google Cloud ドキュメント：Terraform 構成のポリシー検証
Q2. PCI DSS の要件を満たすため、ある顧客はすべての送信（アウトバウンド）トラフィックが許可されていることを保証したいと考えています。
追加の補完的コントロールなしにこの要件を満たすクラウドサービスはどれですか（2 つ選択してください）。
A. App Engine
B. Cloud Functions
C. Compute Engine
D. Google Kubernetes Engine
E. Cloud Storage
回答
- C. Compute Engine、D. Google Kubernetes Engine
-
App EngineやCloud Functionsなどのマネージドサービスでは、上りのファイアウォールルールは設定できても、下り（egress）方向の送信トラフィックを制御する仕組みが標準では提供されません。PCI DSS の要件では、すべての送信トラフィックが許可済みであることを保証する必要があります。Compute EngineとGKEはVPCのファイアウォールルールで下りトラフィックを明示的に制御できるため、補完的コントロールを追加せずに要件を満たせます。試験では、egress制御が必要な要件では、ネットワークを直接制御できるIaaS／コンテナ基盤を選ぶ点が判断基準になります。
Google Cloud ドキュメント：Google Cloud における PCI DSS コンプライアンス
Q3. あなたの会社は、Google Cloud Platform 上に個人を特定できる情報（PII）を保存するウェブサイトを運営しています。
データプライバシー規制に準拠するため、このデータは特定の期間だけ保存でき、その期間の経過後は完全に削除する必要があります。
まだ期間に達していないデータは削除してはなりません。
この規制への準拠プロセスを自動化したいと考えています。
どうすべきですか？
A. データを 1 つの永続ディスク（Persistent Disk）に保存し、有効期限にそのディスクを削除する。
B. データを 1 つの BigQuery テーブルに保存し、適切なテーブルの有効期限を設定する。
C. データを Cloud Storage バケットに保存し、そのバケットのオブジェクトのライフサイクル管理（Object Lifecycle Management）機能を構成する。
D. データを 1 つの Bigtable テーブルに保存し、列ファミリーに有効期限を設定する。
回答
- C. データを Cloud Storage バケットに保存し、オブジェクトのライフサイクル管理機能を構成する。
-
Cloud Storageのオブジェクトのライフサイクル管理では、オブジェクトの経過日数（age）などの条件に基づき、期限を過ぎたオブジェクトのみを自動的に削除できます。期限に達していないデータは保持したまま、期限を過ぎたPIIだけを自動削除できるため、要件に正確に合致します。BigQueryのテーブル有効期限はテーブル全体、Persistent Diskはディスク単位でしか削除できず、個々のデータの経過期間に応じたきめ細かい削除には向きません。試験では、保存期間ベースの自動削除にはCloud Storageのライフサイクル管理が定番の正答です。
Google Cloud ドキュメント：オブジェクトのライフサイクル管理
Q4. あなたの組織は、ターゲットを絞ったマーケティングキャンペーンのために顧客行動を予測する高度な機械学習（ML）モデルを開発しています。
トレーニングに使用する BigQuery のデータセットには機密性の高い個人情報が含まれています。
あなたは AI/ML パイプライン周辺のセキュリティ制御を設計する必要があります。
モデルのライフサイクル全体でデータプライバシーを維持し、個人データがトレーニングプロセスで使用されないようにする必要があります。
さらに、このデータセットへのアクセスを、認可された一部の担当者のみに制限する必要があります。
どうすべきですか？
A. 顧客管理の暗号鍵（CMEK）を用いてパイプラインの保存データ暗号化を実装する。
BigQuery へのアクセスを制御するために厳格な IAM ポリシーを実装する。
B. Cloud Data Loss Prevention（DLP）API を用いてモデルトレーニング前に機密データを匿名化（de-identify）し、BigQuery へのアクセスを制御するために厳格な IAM ポリシーを実装する。
C. Identity-Aware Proxy を実装し、ユーザー ID とデバイスに基づくコンテキストアウェアなアクセスを BigQuery とモデルに強制する。
D. データとコードを使用中も保護するため、モデルを Confidential VM 上にデプロイする。
BigQuery へのアクセスを制御するために厳格な IAM ポリシーを実装する。
回答
- B. DLP API で機密データを匿名化し、厳格な IAM ポリシーで BigQuery へのアクセスを制御する。
-
中核となる要件は「個人データをトレーニングに使用させない」ことで、これはデータの匿名化（de-identification）によって実現します。Cloud DLP（現在の Sensitive Data Protection）は、機密要素をマスキングやトークン化で変換し、有用性を保ちつつリスクを下げる専用ツールです。CMEKやConfidential VMは暗号化・実行時保護には有効ですが、個人データ自体をトレーニングから除外する手段ではありません。アクセス制限はIAMで担保します。試験では、データ内容そのもののプライバシー確保はDLP／SDPが正答になる点を押さえましょう。
Google Cloud ドキュメント：機密データの匿名化（de-identification）
Q5. あなたの会社では、セキュリティチームとネットワークエンジニアリングチームが、VPC 内および VPC 間のすべてのネットワーク異常、VM から VM への内部トラフィック、インターネット上のエンドポイントと VM 間のトラフィック、そして本番環境における VM から Google Cloud サービスへのトラフィックを特定できるようにする必要があります。
どの方法を使用すべきですか？
A. 組織のポリシー制約（organization policy constraint）を定義する。
B. パケットミラーリング（Packet Mirroring）ポリシーを構成する。
C. サブネットで VPC フローログ（VPC Flow Logs）を有効にする。
D. Cloud Audit Logs を監視・分析する。
回答
- B. パケットミラーリング（Packet Mirroring）ポリシーを構成する。
-
パケットミラーリングは、対象VMの受発信トラフィックのパケット全体（ペイロードを含む）を複製し、IDS等の検査ツールへ送って詳細に分析できます。VM間・インターネットとVM間・VMからGoogleサービスへの通信まで幅広く捕捉し、深いネットワーク異常検知を実現できます。VPCフローログはフローのメタデータ（送信元・宛先・量など）のサンプルのみで、ペイロードレベルの異常は検知できません。Cloud Audit Logsは管理操作の記録であり通信内容ではありません。試験では、完全なパケット内容に基づく異常検知が必要ならパケットミラーリングが正答です。
Google Cloud ドキュメント：パケットミラーリングの概要
Q6. セキュリティ脆弱性評価を完了した結果、クラウド管理者が Google Cloud CLI のセッションを何日も開いたままにしていることが判明しました。
攻撃者がこれらの開いたままのセッションを悪用するリスクを軽減するため、これらのセッションを最小限の継続時間に設定する必要があります。
どうすべきですか？
A. Google セッション制御（Google session control）のセッション継続時間を 1 時間に設定する。
B. Google Cloud セッション制御（Google Cloud Session Control）の再認証頻度を 1 時間に設定する。
C. 組織のポリシー制約 constraints/iam.allowServiceAccountCredentialLifetimeExtension を 1 時間に設定する。
D. 組織のポリシー制約 constraints/iam.serviceAccountKeyExpiryHours を 1 時間に、inheritFromParent を false に設定する。
回答
- B. Google Cloud セッション制御の再認証頻度を 1 時間に設定する。
-
Google Cloud セッション制御の再認証頻度を設定すると、gcloud CLIのリフレッシュトークンが指定期間で失効し、ユーザーは定期的な再認証を求められます。頻度を最小の1時間にすることで、開いたままのセッションを攻撃者が悪用できる時間窓を最小化できます。選択肢AのGoogleサービス向けセッション制御はGmail等のWebセッションを対象とし、Google Cloud/gcloudの再認証は制御しません。CとDはサービスアカウント資格情報に関する制約でCLIの対話セッションとは無関係です。試験では、両者の対象範囲の違いを区別することが重要です。
Google Cloud ドキュメント：gcloud CLI の OAuth トークン侵害を緩和するベストプラクティス
Q7. あなたのチームは、あるサービスアカウントを使用して、特定の Compute Engine 仮想マシンインスタンスから指定した Cloud Storage バケットへのデータ転送を認証しています。
あるエンジニアが誤ってそのサービスアカウントを削除してしまい、アプリケーションの機能が壊れてしまいました。
セキュリティを損なうことなく、できるだけ早くアプリケーションを復旧させたいと考えています。
どうすべきですか？
A. Cloud Storage バケットの認証を一時的に無効にする。
B. undelete コマンドを使用して、削除されたサービスアカウントを復元する。
C. 削除されたサービスアカウントと同じ名前で新しいサービスアカウントを作成する。
D. 別の既存サービスアカウントの権限を更新し、その認証情報をアプリケーションに供給する。
回答
- B. undelete コマンドを使用して、削除されたサービスアカウントを復元する。
-
削除後 30 日以内であれば、gcloud iam service-accounts undelete で元の一意な ID（サブジェクト ID）を保ったままサービスアカウントを復元でき、既存の権限や参照がそのまま有効になります。同名で作り直しても内部の一意 ID が変わるため、以前の IAM バインディングは復旧せず、期待どおりに動作しません。認証の無効化はセキュリティを損ない、他アカウントの流用は最小権限に反します。試験では、削除直後のサービスアカウントは復元が第一選択で、同名再作成は同一性を回復しない点を押さえましょう。
Google Cloud ドキュメント：サービスアカウントの削除と復元（undelete）
Q8. あなたのチームは、ファイアウォールルール、サブネット、ルートといったネットワークリソースの制御を一元化できるように、Google Cloud Platform（GCP）環境を構成したいと考えています。
また、オンプレミス環境があり、そのリソースからプライベート VPN 接続を通じて GCP リソースへアクセスできる必要があります。
これらのネットワークリソースはネットワークセキュリティチームが制御する必要があります。
これらの要件を満たすには、どのタイプのネットワーク設計を使用すべきですか？
A. ホストプロジェクトとサービスプロジェクトを持つ共有 VPC（Shared VPC）ネットワーク。
B. 各エンジニアリングプロジェクトについて、ネットワークチームに Compute 管理者（Compute Admin）ロールを付与する。
C. ハブアンドスポークモデルを用いて、すべてのエンジニアリングプロジェクト間で VPC ピアリングを行う。
D. ハブアンドスポークモデルを用いて、すべてのエンジニアリングプロジェクト間に Cloud VPN ゲートウェイを配置する。
回答
- A. ホストプロジェクトとサービスプロジェクトを持つ共有 VPC ネットワーク。
-
共有 VPC では、ホストプロジェクトでサブネット・ファイアウォールルール・ルートを一元管理し、複数のサービスプロジェクトがその共通ネットワークを利用します。ネットワークセキュリティチームがホストプロジェクトを管理することで、ネットワーク統制の一元化と職務分掌を同時に実現できます。VPCピアリングはネットワークを接続するだけで一元管理はできず、各プロジェクトへのCompute管理者付与は権限が分散し統制を弱めます。オンプレミスとはホストプロジェクト側のVPNで接続できます。試験では、ネットワーク管理の集中化＝共有VPCが定番の正答です。
Google Cloud ドキュメント：共有 VPC（Shared VPC）
Q9. あなたは、Compute Engine 上にホストされた CI/CD クラスタを使用してクラウドインフラをデプロイする予定です。
その認証情報が第三者に盗まれるリスクを最小化したいと考えています。
どうすべきですか？
A. クラスタ専用の Cloud Identity ユーザーアカウントを作成する。
堅牢な自己ホスト型 Vault ソリューションを使用して、ユーザーの一時的な認証情報を保存する。
B. クラスタ専用の Cloud Identity ユーザーアカウントを作成する。
プロジェクトレベルで constraints/iam.disableServiceAccountCreation 組織ポリシーを有効にする。
C. クラスタ用のカスタムサービスアカウントを作成する。
プロジェクトレベルで constraints/iam.disableServiceAccountKeyCreation 組織ポリシーを有効にする。
D. クラスタ用のカスタムサービスアカウントを作成する。
プロジェクトレベルで constraints/iam.allowServiceAccountCredentialLifetimeExtension 組織ポリシーを有効にする。
回答
- C. カスタムサービスアカウントを作成し、disableServiceAccountKeyCreation 組織ポリシーを有効にする。
-
Compute Engine上のワークロードには、ユーザーアカウントではなく専用のカスタムサービスアカウントをアタッチして認証させるのがベストプラクティスです。disableServiceAccountKeyCreation 制約でサービスアカウントキー（長期の静的な認証情報）の作成を禁止すると、盗難対象となる鍵ファイル自体が存在しなくなります。VMにアタッチされたサービスアカウントは自動的に短期トークンを取得するため、鍵を配布・保管する必要がありません。Vault保管やユーザーアカウント方式は長期認証情報の漏えいリスクが残ります。試験では、鍵の作成禁止＝漏えいリスク低減の定番手段です。
Google Cloud ドキュメント：組織ポリシーによるサービスアカウントの制限
Q10. あなたは、Compute Engine の VM のみを使用する新しいアプリケーションを開発しています。
このアプリケーションは 1 日に 1 回、5 つの異なるバッチジョブを実行します。
各バッチジョブは、アプリケーションの外部にある Google Cloud リソースに対して、専用の権限セットを必要とします。
最小権限の原則に従う、バッチジョブ向けの安全なアクセス設計を行う必要があります。
どうすべきですか？
A. バッチジョブを実行する汎用サービスアカウント「g-sa」を 1 つ作成する。
バッチジョブの実行に必要な権限をすべて g-sa に付与する。
g-sa の権限でバッチジョブを実行する。
B. バッチジョブをオーケストレーションする汎用サービスアカウント「g-sa」を作成する。
バッチジョブごとに 1 つずつサービスアカウント「b-sa-[1-5]」を作成し、各ジョブの実行に必要な権限のみを付与する。
g-sa に Service Account Token Creator ロールを付与し、g-sa を使って b-sa-[1-5] の短命なアクセストークンを取得して、各 b-sa の権限でバッチジョブを実行する。
C. ワークロード ID プール（workload identity pool）を作成し、各バッチジョブ用のプロバイダを構成する。
各プロバイダに構成した ID に Workload Identity ユーザーロールを割り当てる。
バッチジョブごとにサービスアカウント「b-sa-[1-5]」を作成し、必要な権限のみを付与する。
各プロバイダの認証情報構成ファイルを生成し、それを用いて b-sa-[1-5] の権限でバッチジョブを実行する。
D. バッチジョブをオーケストレーションする汎用サービスアカウント「g-sa」を作成する。
バッチジョブごとにサービスアカウント「b-sa-[1-5]」を作成し、必要な権限のみを付与したうえで、各サービスアカウントのキーを生成する。
そのキーを Secret Manager に保存し、g-sa に Secret Manager へのアクセスを付与して、b-sa-[1-5] の権限でバッチジョブを実行する。
回答
- B. g-sa がオーケストレーションし、ジョブごとの b-sa に対して Service Account Token Creator で短命トークンを取得して実行する。
-
ジョブごとに専用サービスアカウント（b-sa-[1-5]）を用意し、それぞれに必要な権限だけを与えることで最小権限を徹底できます。g-sa に Service Account Token Creator ロールを付与してサービスアカウントの権限借用（impersonation）を行い、短命なアクセストークンで各ジョブを実行するため、長期的なキーを一切扱いません。選択肢Dのようにキーを生成・保存する方式は、鍵の漏えいリスクを新たに抱えます。ワークロードID連携は主に外部IdPからの連携用途です。試験では、GCP内のジョブ分離は「専用SA＋権限借用＋短命トークン」が正答です。
Google Cloud ドキュメント：短命の認証情報の作成（権限借用）