Google Professional Cloud Network Engineer 1-10

表示モード
画像位置
文字位置
理解度の自動記録
STATUS FILTER

表示する理解度を選択

読み込み中...
Q1Google Professional Cloud Network Engineer
解答を見る
正解:B. GKEのPodに割り当てるIPアドレス範囲を10.0.0.0/8内に収める。–disable-default-snatフラグは設定しない。
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 マスカレード エージェント
Q2Google Professional Cloud Network Engineer
解答を見る
正解: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 アクセス
Q3Google Professional Cloud Network Engineer
解答を見る
正解:D. 部門ごとのフォルダに、2つのルールを持つ階層型ファイアウォールポリシーを2つ作成する。高優先度のルールで当該VPCに割り当てられたプライベートCIDRからのトラフィックに一致させてアクション「goto_next」を設定し、低優先度のルールでそれ以外の送信元からのトラフィックをブロックする。
階層型ファイアウォールポリシーは組織・フォルダレベルで一元管理でき、下位のルールで上書きされません。
VPC内部の判断だけを各部門へ委譲するには、そのVPCのプライベートCIDRに一致するトラフィックに「goto_next」を設定し、評価を下位のVPCファイアウォールルールへ引き継がせます。
そのうえで低優先度のルールで他の送信元をブロックすれば、VPC間の通信を遮断できます。
Cの「allow」はその時点で最終判断となり部門への委譲になりません。
A・BのVPC単位ルールは部門側で変更できてしまい、集中的な遮断にはなりません。
Cloud NGFW ドキュメント – 階層型ファイアウォール ポリシー
Q4Google Professional Cloud Network Engineer
解答を見る
正解:B. システムが自動生成するサブネットルートよりも詳細なルートを作成し、ネクストホップをinstance-Bに指定する。instance-Aに適用したタグを付ける。
特定インスタンスのトラフィックだけをアプライアンス経由にするには、システム生成のサブネットルートより詳細なカスタムルートを作成し、ネクストホップをinstance-Bに指定します。
そのルートにinstance-Aへ付与したネットワークタグを設定することで、適用対象をinstance-Aのみに限定でき、他のインスタンスへ影響を与えません。
自動生成のサブネットルートは削除できないためCは不可、タグなしのAは全インスタンスに影響が及び、Dは構成が過剰でこの要件には不要です。
VPC ドキュメント – ルート
Q5Google Professional Cloud Network Engineer
解答を見る
正解:A. Cloud Routerを作成し、VPNトンネルを追加してから、BGPセッションを構成する。
オンプレミスとGoogle Cloudの間でルートを動的に交換するにはBGPを使用します。
Cloud Routerを作成してVPNトンネルを追加し、BGPセッションを構成することで、両環境間の経路情報が自動的にやり取りされます。
グローバル動的ルーティングはVPC全体のルート伝播モードの設定であり、動的交換そのものを成立させる直接の手順ではありません。
Dの静的ルートは動的交換になりません。
BはHA VPNゲートウェイをもう1つ用意する必要はなく、要件に合致しません。
Cloud VPN ドキュメント – HA VPN の作成
Q6Google Professional Cloud Network Engineer
解答を見る
正解:A. IP_RANGE_PRODとIP_RANGE_NONPRODを用いて2つのアクセスレベルを作成し、各アクセスレベルが1つの範囲を参照する設計にする。2つのイングレス(ingress)アクセスポリシーを作成し、各ポリシーが2つのアクセスレベルのいずれかを参照するようにする。PERIMETER_PRODとPERIMETER_NONPRODを更新する。
同一VPC内でも、サブネットのIP範囲によって本番と非本番を区別できます。
IP範囲ベースのアクセスレベルを2つ作成し、それぞれをイングレスポリシーで各境界に紐付けることで、本番サブネットは本番バケットのみ、非本番サブネットは非本番バケットのみへのアクセスに限定でき、既存構成を大きく変えずに実現できます。
B・C・Dは境界の削除やVPCの新規作成・ワークロード移行を伴うため、手間が大きく分離要件も満たしにくい構成です。
VPC Service Controls ドキュメント – アクセスレベル
Q7Google Professional Cloud Network Engineer
解答を見る
正解:C. 異なるパブリックIPアドレスを持つ2つ目のオンプレミスVPNゲートウェイを追加する。既存のCloud VPNゲートウェイ上に、同じIP範囲を転送しつつ新しいオンプレミスゲートウェイIPを指す2つ目のトンネルを作成する。
Cloud VPNの帯域を増やすには、複数のトンネルを用意してECMP(等コストマルチパス)でトラフィックを分散させます。
異なるパブリックIPを持つ2つ目のオンプレミスゲートウェイを追加し、既存のCloud VPNゲートウェイ上に同じIP範囲を転送する2つ目のトンネルを作成することで、複数トンネル間で負荷を分散し帯域を拡大できます。
AのMTU変更は帯域の増加になりません。
同一宛先IPへの単純な追加や別リージョン化は冗長性向けの構成であり、帯域拡大というこの要件には適していません。
Cloud VPN ドキュメント – Classic VPN のトポロジ
Q8Google Professional Cloud Network Engineer
解答を見る
正解:A. WebServicesチーム用のGoogleグループを作成する。
Googleグループを作成し、そのグループにIAMロールを付与すれば権限を一元管理でき、同じグループがメール配信リストとしても機能するため、権限管理とメール配信を最も効率的に統合できます。
メンバーの追加・削除もグループ操作だけで両方に反映されます。
B・Cのドメイン作成は過大であり、単一チームの権限・配信一元化には不要です。
Dのカスタムロールは権限の定義であって、メール配信の一元化には寄与しません。
IAM ドキュメント – グループによるアクセス制御
Q9Google Professional Cloud Network Engineer
解答を見る
正解:A. 共有VPC(Shared VPC)を使用し、VLANアタッチメントとDedicated Interconnectをホストプロジェクトにデプロイする。
10 Gbpsと最低レイテンシの要件からDedicated Interconnectを用います。
共有VPCを採用し、Dedicated InterconnectとVLANアタッチメントをホストプロジェクトに集約すれば、1つのインターコネクトを全サービスプロジェクトで共有でき、ネットワーク管理を一元化しながら最もコスト効率良く各学部へ接続を提供できます。
C・Dのようにプロジェクトごとにインターコネクトを持つと重複投資となり非効率で、一元管理の要件にも反します。
Cloud Interconnect ドキュメント – 他のプロジェクトでの相互接続の使用
Q10Google Professional Cloud Network Engineer
解答を見る
正解:D. GKE Ingress
Cloud Armorのセキュリティポリシーはロードバランサに対して適用されます。
GKEではIngressリソースが外部Application Load Balancerをプロビジョニングするため、Cloud ArmorポリシーのターゲットとしてはGKE Ingress(BackendConfig経由で関連付け)を使用します。
ノード・ポッド・クラスタはロードバランサではないため、Cloud Armorの適用対象にはなりません。
GKEのデフォルトIngressコントローラとセキュリティポリシーを組み合わせて構成します。
GKE ドキュメント – Ingress の機能