Google Professional Cloud Network Engineer (PCNE) ダンプと解説

あなたの会社は、2 つのリージョンにまたがる 3 つの VPC ネットワーク（prod、stage、dev）を持つ単一の Google Cloud プロジェクトを運用しています。Cloud Bigtable と Artifact Registry への API 呼び出しが、企業の egress NAT のパブリック IP レンジ 203.0.113.0/24 と 198.51.100.0/24 から発信されたリクエストの場合にのみ許可されるようにしなければなりません。オンプレミスのシステムは、これらの NAT を経由してパブリックインターネット越しに Google APIs にアクセスします。どうすべきですか？

あなたのチームは、グローバルな動画レンダリングプラットフォーム向けに auto mode で作成された Studio という VPC を管理しています。auto-mode の VPC は、複数リージョンにわたるサブネット用に 10.128.0.0/9 を確保します。 同じプロジェクト内に Archive という新しい VPC を作成し、VPC Network Peering を使用して Studio と接続し、内部の RFC1918 トラフィックが NAT を使わずにエンドツーエンドでプライベートにルーティングされるようにする必要があります。2 つの VPC は、現在も将来的なスケール時も IP 範囲が重複してはなりません。 Archive VPC はどのように構成すべきですか？

あなたは、グローバルなストリーミング企業で、コア API を Google Cloud へ移行しているネットワークエンジニアです。 接続要件は次のとおりです: - 単一の都市圏データセンターから少なくとも 20 Gbps のオンプレミス接続 - Google Cloud への最小レイテンシのプライベートアクセス（目標: 最寄りの POP まで片道 <5 ms） - 中央集権の Network Engineering チームがすべての WAN リンクとルーティングを管理すること 新しいプロダクトグループは個別の Google Cloud プロジェクトを作成しており、各ワークロードからオンプレミスのサービスへのプライベートアクセスを必要としています。 上記要件を満たしつつ、データセンターと Google Cloud を最もコスト効率よく接続する設計が必要です。 どうすべきでしょうか？

貴社は、global external HTTP(S) load balancerの背後で稼働するライブイベント向けのグローバル可用なチケット発券APIを運用している。フラッシュセール時には、40カ国以上からのトラフィックが1分あたり250,000リクエストに急増し、セキュリティチームはSQLインジェクション、クロスサイトスクリプティング（XSS）、異常なヘッダーといったアプリケーション層のパターンを検知している。アプリケーションコードを変更せず、エッジでこれらのアプリケーションレベル攻撃からサービスを保護し、既存のロードバランサのbackend serviceに制御をアタッチする必要がある。どうすべきか？

貴社のハードウェア系スタートアップは、Cloud Storage の backend bucket を持つ external HTTP(S) load balancer の前段に Cloud CDN を配置し、重要なスマートドアロック用ファームウェアをグローバルに配信しています。 段階的ロールアウト中に、誤ったファームウェアビルド (2.4.1-debug) がアップロードされ、世界中でキャッシュされていることが判明しました。対象オブジェクトは Cache-Control: max-age=86400 で配信されており、すでに数万台のデバイスがダウンロードしています。 コミュニケーションチームは、同一の URL (https://updates.example.com/locks/fw.bin) を用いて修正版ファームウェアを再ダウンロードするよう顧客に案内しました。 今後のダウンロードが、すべてのエッジロケーションで同一の URL から直ちに修正版ファームウェアを取得するように確実にする必要があります。どうすべきでしょうか。