Q1. 新しいGKE標準クラスタを作成しています。
Pod（ポッド）が、Google Cloud内の192.168.0.0/24サブネットにある他のVM（仮想マシン）へ、GKEノードのソースIPを使って到達できるようにクラスタを構成する必要があります。
どうすればよいですか。
A. GKEのPod IPアドレス範囲を10.0.0.0/8に収まるように設定する。–disable-default-snatフラグを構成する。
B. GKEのPod IPアドレス範囲を10.0.0.0/8に収まるように設定する。–disable-default-snatフラグは構成しない。
C. GKEのPod IPアドレス範囲を10.0.0.0/8に収まらないように設定する。–disable-default-snatフラグは構成しない。
D. GKEのPod IPアドレス範囲を10.0.0.0/8に収まらないように設定する。–disable-default-snatフラグを構成する。
回答
- B
-
GKEはデフォルトで、Podからクラスタ外かつRFC 1918のプライベート範囲（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）宛てのegress（下り）トラフィックにSNAT（送信元NAT）を行い、送信元IPをノードのIPに変換します。
ノードのソースIPで192.168.0.0/24に到達させるには、このデフォルトSNATを効かせる必要があります。
Pod範囲を宛先とは別のRFC 1918範囲である10.0.0.0/8に収め、かつ–disable-default-snatフラグを設定しないことで、GKEがSNATを行いノードのIPが送信元になります。
フラグを設定するとPod自身のIPが送信元になり、要件を満たしません。
GKE ドキュメント – IP マスカレード エージェント
Q2. Compute Engine上で稼働するアプリケーションがBigQueryを使って結果を生成し、それをCloud Storageに保存しています。
アプリケーションのインスタンスのいずれにも外部IPアドレスを持たせないようにしたいと考えています。
これを実現できる方法を2つ選んでください。（2つ選択）
A. すべてのサブネットでPrivate Google Accessを有効にする。
B. VPCでPrivate Google Accessを有効にする。
C. VPCでPrivate Services Accessを有効にする。
D. VPCとBigQueryの間でネットワークピアリングを作成する。
E. Cloud NATを作成し、アプリケーションのトラフィックをNATゲートウェイ経由でルーティングする。
回答
- A、E
-
外部IPを持たないインスタンスがBigQueryやCloud StorageなどのGoogle APIへ到達するには、egress（下り）経路を用意する必要があります。
Private Google Accessはサブネット単位で有効化する設定であり、VPC全体を単位とはできないため、正しくはすべてのサブネットで有効にします。
これにより外部IPなしでGoogle APIへアクセスできます。
またCloud NATを作成しトラフィックをNATゲートウェイ経由にすれば、外部IPを持たせずにegressを実現できます。
BはPrivate Google Accessの設定単位が誤り、CのPrivate Services Accessはマネージドサービス向け、DのピアリングはBigQuery相手には利用できません。
VPC ドキュメント – 限定公開の Google アクセス
Q3. 御社は、各部門用のサブフォルダを持つ親フォルダを含むリソース階層を定義しています。
各部門は割り当てられたフォルダ内に自部門のプロジェクトとVPCを定義し、Google Cloudのファイアウォールルールを作成する適切な権限を持っています。
VPC間ではトラフィックを流さないようにする必要があります。
他のVPCを含むあらゆる送信元からのトラフィックをすべてブロックしつつ、VPC内部（intra-VPC）のファイアウォールルールのみを各部門に委譲する必要があります。
どうすればよいですか。
A. 各VPCに、あらゆる送信元からのトラフィックを優先度0でブロックするVPCファイアウォールルールを作成する。
B. 各VPCに、あらゆる送信元からのトラフィックを優先度1000でブロックするVPCファイアウォールルールを作成する。
C. 部門ごとのフォルダに、2つのルールを持つ階層型ファイアウォールポリシーを2つ作成する。高優先度のルールで当該VPCに割り当てられたプライベートCIDRからのトラフィックに一致させてアクション「allow」を設定し、低優先度のルールでそれ以外の送信元からのトラフィックをブロックする。
D. 部門ごとのフォルダに、2つのルールを持つ階層型ファイアウォールポリシーを2つ作成する。高優先度のルールで当該VPCに割り当てられたプライベートCIDRからのトラフィックに一致させてアクション「goto_next」を設定し、低優先度のルールでそれ以外の送信元からのトラフィックをブロックする。
回答
- D
-
階層型ファイアウォールポリシーは組織・フォルダレベルで一元管理でき、下位のルールで上書きできません。
VPC内部の判断を各部門へ委譲するには、そのVPCのプライベートCIDRに一致させて「goto_next」を設定し、下位のVPCファイアウォールルールへ評価を引き継がせます。
そのうえで低優先度のルールで他の送信元をブロックすれば、VPC間の通信を遮断できます。
Cの「allow」は最終判断となり部門への委譲になりません。
A・BのVPC単位ルールは部門側で変更でき、集中的な遮断にはなりません。
Cloud NGFW ドキュメント – 階層型ファイアウォール ポリシー
Q4. サブネットレベルの分離を実現するため、あるサブネットのinstance-Aを、別のサブネットにあるセキュリティアプライアンス（instance-B）経由でルーティングさせたいと考えています。
どうすればよいですか。
A. システムが自動生成するサブネットルートよりも詳細な（より具体的な）ルートを作成し、ネクストホップをinstance-Bに指定する。タグは付けない。
B. システムが自動生成するサブネットルートよりも詳細なルートを作成し、ネクストホップをinstance-Bに指定する。instance-Aに適用したタグを付ける。
C. システムが自動生成するサブネットルートを削除し、instance-Aに適用したタグを付けてinstance-Bへの具体的なルートを作成する。
D. instance-Bを別のVPCへ移動し、マルチNICを使ってinstance-Bのインターフェースをinstance-Aのネットワークに接続する。instance-A経由でトラフィックを強制するよう適切なルートを構成する。
回答
- B
-
特定インスタンスのトラフィックだけをアプライアンス経由にするには、システム生成のサブネットルートより詳細なカスタムルートを作成し、ネクストホップをinstance-Bに指定します。
そのルートにinstance-Aへ付与したネットワークタグを設定することで、対象をinstance-Aのみに限定でき、他のインスタンスに影響を与えません。
自動生成のサブネットルートは削除できないためCは不可、タグなしのAは全インスタンスに影響し、Dは過剰で不要な構成です。
VPC ドキュメント – ルート
Q5. Google Cloud内でHA VPNをデプロイしています。
オンプレミスのゲートウェイとGoogle Cloudの間でルートを動的に交換する必要があります。
すでにHA VPNゲートウェイとピアVPNゲートウェイリソースは作成済みです。
どうすればよいですか。
A. Cloud Routerを作成し、VPNトンネルを追加してから、BGPセッションを構成する。
B. 2つ目のHA VPNゲートウェイを作成し、VPNトンネルを追加してグローバル動的ルーティングを有効にする。
C. Cloud Routerを作成し、VPNトンネルを追加してグローバル動的ルーティングを有効にする。
D. Cloud Routerを作成し、VPNトンネルを追加してから、サブネット範囲への静的ルートを構成する。
回答
- A
-
オンプレミスとGoogle Cloudの間でルートを動的に交換するにはBGPを使用します。
Cloud Routerを作成してVPNトンネルを追加し、BGPセッションを構成することで、両環境間で経路情報が自動的にやり取りされます。
グローバル動的ルーティングはVPC全体のルート伝播モードの設定であり、動的交換そのものを成立させる直接の手順ではありません。
Dの静的ルートは動的交換になりません。
BはHA VPNゲートウェイをもう1つ作る必要はなく、要件に合致しません。
Cloud VPN ドキュメント – HA VPN の作成
Q6. 御社の現在のネットワークアーキテクチャには、3つのVPC Service Controlsの境界（perimeter）があります。
・本番用ストレージバケットを保護する境界（PERIMETER_PROD）
・非本番用ストレージバケットを保護する境界（PERIMETER_NONPROD）
・単一のVPC（VPC_ONE）を含む境界（PERIMETER_VPC）
この単一のVPC（VPC_ONE）では、IP_RANGE_PRODが本番ワークロードのサブネットに、IP_RANGE_NONPRODが非本番ワークロードのサブネットに割り当てられています。
ワークロードはこの2つの範囲外には作成できません。
本番ワークロードは本番ストレージバケットのみ、非本番ワークロードは非本番ストレージバケットのみにアクセスできるようにし、なおかつセットアップの手間を最小限にする必要があります。
どうすればよいですか。
A. IP_RANGE_PRODとIP_RANGE_NONPRODを用いて2つのアクセスレベルを作成し、各アクセスレベルが1つの範囲を参照する設計にする。2つのイングレス（ingress）アクセスポリシーを作成し、各ポリシーが2つのアクセスレベルのいずれかを参照するようにする。PERIMETER_PRODとPERIMETER_NONPRODを更新する。
B. PERIMETER_VPC境界を削除する設計にする。PERIMETER_NONPROD境界を更新してVPC_ONEを含むプロジェクトを含める。PERIMETER_PROD境界を削除する。
C. VPC_ONEと同じプロジェクトに新しいVPC（VPC_NONPROD）を作成する設計にする。すべての非本番ワークロードをVPC_ONEからPERIMETER_NONPROD境界へ移行する。PERIMETER_VPC境界を削除する。PERIMETER_PROD境界を更新してVPC_ONEを含め、PERIMETER_NONPROD境界を更新してVPC_NONPRODを含める。
D. PERIMETER_VPC境界を削除する設計にする。PERIMETER_PROD境界を更新してVPC_ONEを含むプロジェクトを含める。PERIMETER_NONPROD境界を削除する。
回答
- A
-
同一VPC内でも、サブネットのIP範囲によって本番と非本番を区別できます。
IP範囲ベースのアクセスレベルを2つ作成し、それぞれをイングレスポリシーで各境界に紐付けることで、本番サブネットは本番バケットのみ、非本番サブネットは非本番バケットのみへのアクセスに限定でき、既存構成を大きく変えずに実現できます。
B・C・Dは境界の削除やVPCの新規作成・ワークロード移行を伴い、手間が大きく分離要件も満たしにくい構成です。
VPC Service Controls ドキュメント – アクセスレベル
Q7. オンプレミスとGCPの間でCloud VPNの利用を拡大しており、単一トンネルで処理できる以上のトラフィックをサポートしたいと考えています。
Cloud VPNを使って利用可能な帯域幅を増やしたいです。
どうすればよいですか。
A. オンプレミスのVPNゲートウェイのMTUを1460バイトから2920バイトへ倍にする。
B. 同じCloud VPNゲートウェイ上に、同じ宛先VPNゲートウェイIPアドレスを指す2つのVPNトンネルを作成する。
C. 異なるパブリックIPアドレスを持つ2つ目のオンプレミスVPNゲートウェイを追加する。既存のCloud VPNゲートウェイ上に、同じIP範囲を転送しつつ新しいオンプレミスゲートウェイIPを指す2つ目のトンネルを作成する。
D. 既存のVPNゲートウェイとは別のリージョンに2つ目のCloud VPNゲートウェイを追加する。2つ目のCloud VPNゲートウェイ上に、同じIP範囲を転送しつつ既存のオンプレミスVPNゲートウェイIPを指す新しいトンネルを作成する。
回答
- C
-
Cloud VPNの帯域を増やすには、複数のトンネルを用意してECMP（等コストマルチパス）でトラフィックを分散させます。
異なるパブリックIPを持つ2つ目のオンプレミスゲートウェイを追加し、既存のCloud VPNゲートウェイ上に同じIP範囲を転送する2つ目のトンネルを作成することで、複数トンネル間で負荷を分散し帯域を拡大できます。
AのMTU変更は帯域増加になりません。
同一宛先IPへの単純な追加や別リージョン化は冗長性向けの構成であり、帯域拡大というこの要件には適しません。
Cloud VPN ドキュメント – Classic VPN のトポロジ
Q8. WebServicesチームのIdentity and Access Management（IAM）権限とメール配信を、可能な限り効率的に一元化する必要があります。
どうすればよいですか。
A. WebServicesチーム用のGoogleグループを作成する。
B. WebServicesチーム用のG Suiteドメインを作成する。
C. WebServicesチーム用の新しいCloud Identityドメインを作成する。
D. WebServicesチームの全メンバー用の新しいカスタムロールを作成する。
回答
- A
-
Googleグループを作成し、そのグループにIAMロールを付与すれば権限を一元管理でき、同じグループがメール配信リストとしても機能するため、権限管理とメール配信を最も効率的に統合できます。
メンバーの追加・削除もグループ操作だけで両方に反映されます。
B・Cのドメイン作成は過大で、単一チームの権限・配信一元化には不要です。
Dのカスタムロールは権限定義であり、メール配信の一元化には寄与しません。
IAM ドキュメント – グループによるアクセス制御
Q9. 大学向けに勤務しており、Google Cloudへの移行を進めています。
クラウドの要件は次のとおりです。
・オンプレミス接続は10 Gbps
・クラウドへの最も低いレイテンシでのアクセス
・ネットワーク管理チームの一元化
新しい部門が、自部門のプロジェクトへのオンプレミス接続を求めています。
キャンパスとGoogle Cloudを接続する、最もコスト効率の高いインターコネクトソリューションをデプロイしたいと考えています。
どうすればよいですか。
A. 共有VPC（Shared VPC）を使用し、VLANアタッチメントとDedicated Interconnectをホストプロジェクトにデプロイする。
B. 共有VPCを使用し、VLANアタッチメントをサービスプロジェクトにデプロイする。VLANアタッチメントを共有VPCのホストプロジェクトに接続する。
C. スタンドアロンのプロジェクトを使用し、VLANアタッチメントを各プロジェクトにデプロイする。VLANアタッチメントを各スタンドアロンプロジェクトのDedicated Interconnectに接続する。
D. スタンドアロンのプロジェクトを使用し、VLANアタッチメントとDedicated Interconnectを各プロジェクトにデプロイする。
回答
- A
-
10 Gbpsと最低レイテンシの要件からDedicated Interconnectを用います。
共有VPCを採用し、Dedicated InterconnectとVLANアタッチメントをホストプロジェクトに集約すれば、1つのインターコネクトを全サービスプロジェクトで共有でき、ネットワーク管理を一元化しながら最もコスト効率良く各部門へ接続を提供できます。
C・Dのようにプロジェクトごとにインターコネクトを持つと重複投資となり非効率で、一元管理の要件にも反します。
Cloud Interconnect ドキュメント – 他のプロジェクトでの相互接続の使用
Q10. Google Kubernetes Engine（GKE）にデプロイしたアプリケーションに、新しいCloud Armorポリシーを適用したいと考えています。
Cloud Armorポリシーのターゲットとして何を使うべきかを知りたいです。
どのGKEリソースを使用すべきですか。
A. GKEノード（GKE Node）
B. GKEポッド（GKE Pod）
C. GKEクラスタ（GKE Cluster）
D. GKE Ingress
回答
- D
-
Cloud Armorのセキュリティポリシーはロードバランサに対して適用されます。
GKEではIngressリソースが外部Application Load Balancerをプロビジョニングするため、Cloud ArmorポリシーのターゲットとしてはGKE Ingress（BackendConfig経由で関連付け）を使用します。
ノード・ポッド・クラスタはロードバランサではないため、Cloud Armorの適用対象にはなりません。
GKEのデフォルトIngressコントローラとセキュリティポリシーを組み合わせて構成します。
GKE ドキュメント – Ingress の機能