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