CertPass

Question 156

あなたはGoogle Cloud環境のフォルダのネットワークトラフィックを制御しています。あなたのフォルダには、複数のプロジェクトとVirtual Private Cloud (VPC) ネットワークが含まれています。フォルダレベルで、送信接続をIP範囲 10.58.5.0/24 のみに限定し、かつVPCネットワーク「dev-vpc」からのみに強制したいと考えています。実装とメンテナンスの労力を最小限に抑えたいと考えています。どうすべきですか？

1. 対象範囲のVMのネットワーク構成は変更しません。 2. 新しいVPCネットワーク「new-vpc」を含む新しいプロジェクトを作成します。 3. 「new-vpc」にネットワークアプライアンスをデプロイし、アクセスリクエストをフィルタリングして、「dev-vpc」から10.58.5.0/24への送信接続のみを許可します。

1. 対象範囲のVMのネットワーク構成は変更しません。 2. 「dev-vpc」に対してCloud NATを有効にし、Cloud NATのターゲット範囲を10.58.5.0/24に制限します。

1. 対象範囲のVMに外部IPアドレスを割り当てます。 2. フォルダレベルで階層型ファイアウォールポリシーを定義・適用し、すべての送信接続を拒否し、VPCネットワーク「dev-vpc」からIP範囲10.58.5.0/24への送信を許可します。

1. 対象範囲のVMに外部IPアドレスを割り当てます。 2. 「dev-vpc」にVPCファイアウォールルールを設定し、このネットワーク内のすべての送信元アドレスからIP範囲10.58.5.0/24への送信接続を許可します。

Question 157

ある企業のアプリケーションが、ユーザー管理のサービスアカウントキーを使用してデプロイされています。Googleが推奨するプラクティスに従ってキーをローテーションしたいと考えています。何をすべきでしょうか？

Cloud Shellを開き、`gcloud iam service-accounts enable-auto-rotate --iam-account=IAM_ACCOUNT` を実行する。

Cloud Shellを開き、`gcloud iam service-accounts keys rotate --iam-account=IAM_ACCOUNT --key=NEW_KEY` を実行する。

新しいキーを作成し、アプリケーションで新しいキーを使用する。古いキーをサービスアカウントから削除する。

新しいキーを作成し、アプリケーションで新しいキーを使用する。古いキーをバックアップキーとしてシステムに保存する。

Question 158

お客様は、オンプレミスに認証局（CA）を持つ公開鍵基盤（PKI）を運用しています。多数のHTTPロードバランサーのフロントエンド用に証明書を発行する必要があります。オンプレミスのPKIは手動プロセスが多いため、その影響を最小限に抑える必要があり、かつソリューションはスケーラブルである必要があります。あなたは何をすべきですか？

Certificate Managerを使用してGoogleマネージド公開証明書を発行し、Infrastructure as Code（IaC）でHTTPロードバランサーに設定します。

オンプレミスのPKIシステムからGoogle Certificate Authority Serviceに従属CAを構成し、ロードバランサー用の証明書を発行します。

Certificate Managerを使用して、オンプレミスPKIから発行された証明書をフロントエンド用にインポートします。インポートにはgcloudツールを利用します。

オンプレミスのOpenSSLベースの従属CAから発行されたPKCS12証明書をウェブアプリケーションで使用します。インポートにはgcloudツールを使用します。外部HTTPロードバランサーの代わりに外部TCP/UDPネットワークロードバランサーを使用します。

Question 159

あなたは、Compute Engine VM のみを排他的に使用する新しいアプリケーションを開発しています。このアプリケーションは、1日に1回、5つの異なるバッチジョブを実行します。各バッチジョブは、アプリケーション外部の Google Cloud リソースに対する専用の権限セットを必要とします。あなたは、最小権限の原則に従った、バッチジョブのための安全なアクセスコンセプトを設計する必要があります。どうすべきですか？

1. バッチジョブをオーケストレーションするための汎用サービスアカウント「g-sa」を作成します。 2. バッチジョブごとにサービスアカウント「b-sa-[1-5]」を1つ作成します。個々のバッチジョブの実行に必要な権限のみをこれらのサービスアカウントに付与し、各サービスアカウントのサービスアカウントキーを生成します。 3. サービスアカウントキーを Secret Manager に保存します。「g-sa」に Secret Manager へのアクセス権を付与し、「b-sa-[1-5]」の権限でバッチジョブを実行します。

1. バッチジョブを実行するための汎用サービスアカウント「g-sa」を作成します。 2. バッチジョブの実行に必要な権限を「g-sa」に付与します。 3. 「g-sa」に付与された権限でバッチジョブを実行します。

1. Workload Identity プールを作成し、各バッチジョブに対して Workload Identity プールプロバイダを設定します。 2. プロバイダで設定された各アイデンティティに Workload Identity ユーザーロールを割り当てます。 3. バッチジョブごとにサービスアカウント「b-sa-[1-5]」を1つ作成し、個々のバッチジョブの実行に必要な権限のみをこれらのサービスアカウントに付与します。 4. 各プロバイダの認証情報設定ファイルを生成します。これらのファイルを使用して、「b-sa-[1-5]」の権限でバッチジョブを実行します。

1. バッチジョブをオーケストレーションするための汎用サービスアカウント「g-sa」を作成します。 2. バッチジョブごとにサービスアカウント「b-sa-[1-5]」を1つ作成し、個々のバッチジョブの実行に必要な権限のみをこれらのサービスアカウントに付与します。 3. 「g-sa」にサービスアカウントトークン作成者ロールを付与します。「g-sa」を使用して「b-sa-[1-5]」の短期アクセストークンを取得し、「b-sa-[1-5]」の権限でバッチジョブを実行します。

Question 160

あなたのGoogle Cloud環境には、1つの組織ノード、"Apps"という名前の1つのフォルダ、そしてそのフォルダ内にいくつかのプロジェクトがあります。組織ノードは、terramearth.com組織のメンバーを許可するconstraints/iam.allowedPolicyMemberDomains組織ポリシーを適用しています。"Apps"フォルダは、flowlogistic.com組織のメンバーを許可するconstraints/iam.allowedPolicyMemberDomains組織ポリシーを適用しており、inheritFromParent: falseプロパティも設定されています。あなたは、"Apps"フォルダ内のプロジェクトへのアクセス権をユーザーtestuser@terramearth.comに付与しようとしています。この操作の結果とその理由は何ですか？

アクションは成功します。なぜなら、terramearth.comまたはflowlogistic.comの両方の組織のメンバーが「Apps」フォルダ内のプロジェクトで許可されているからです。

アクションは成功し、新しいメンバーはプロジェクトのIdentity and Access Management (IAM)ポリシーに正常に追加されます。なぜなら、すべてのポリシーは下位のフォルダやプロジェクトに継承されるからです。

アクションは失敗します。なぜなら、制約を一時的に無効化するために、現在のプロジェクトでconstraints/iam.allowedPolicyMemberDomains組織ポリシーを定義する必要があるからです。

アクションは失敗します。なぜなら、constraints/iam.allowedPolicyMemberDomains組織ポリシーが設定されており、flowlogistic.com組織のメンバーのみが許可されているからです。

Professional Cloud Security Engineer