Professional Cloud Network Engineer

あなたの組織の現在のアーキテクチャには、単一のVPC (SH_VPC) を含む共有VPCホストプロジェクト (SH_HOST_PRJ) が1つと、VPCを含まない共有VPCサービスプロジェクト (SP_ONE_PRJ と SP_TWO_PRJ) が2つあります。各共有VPCサービスプロジェクトは異なるチームに属しており、TEAM_ONEがSP_ONE_PRJを、TEAM_TWOがSP_TWO_PRJを管理しています。 各チームがそれぞれの共有VPCサービスプロジェクト内でのみ独自のDNSプライベートゾーンとDNSレコードを作成できるようにするソリューションを設計する必要があります。SP_ONE_PRJ内のワークロードはSP_TWO_PRJで定義されたすべてのDNSプライベートゾーンを解決でき、その逆も同様である必要があります。設計は、設定の手間が最も少ないものでなければなりません。どうすればよいですか？

あなたは、組織のGoogle Cloudネットワーク内で期待通りに機能していないアプリケーションのトラブルシューティングを行っています。どこかでパケットが失われているのではないかと疑っています。アプリケーションは、Compute Engine VMからオンプレミスネットワーク上の宛先へ、一対のCloud Interconnect VLANアタッチメントを経由して、断続的に低ボリュームのパケットを送信します。Cloud Next Generation Firewall (Cloud NGFW) ルールに下り（egress）トラフィックをブロックする拒否ステートメントがなく、明示的な許可ルールもないことを確認しました。Googleが推奨するプラクティスに従い、VMからパケットが正しく送信されているかを確認するためにフローを分析し、問題を切り分ける必要があります。どうすべきですか？

あなたは最近、外部グローバルアプリケーションロードバランサを使用する主要アプリケーションのユーザー行動を確認したところ、クライアントリクエストのレートの不規則な急増によりバックエンドサーバーが過負荷になっていることがわかりました。Google の推奨プラクティスに従いながら、同時セッション数を制限し、クライアントに HTTP 429 Too Many Requests レスポンスを返す必要があります。どうすればよいですか？

あなたの会社では、サードパーティのクラウドWAFプロバイダーが提供するWebアプリケーションファイアウォール（WAF）機能を使用しています。このWAFプロバイダーは、インターネットクライアントからのすべてのHTTPS接続をプロキシし、セキュリティポリシーを適用した後、Google Cloud上のグローバルアプリケーションロードバランサーのパブリックIPアドレスに対して新しいHTTPS接続を開きます。あなたのGoogle Cloudワークロードは、このグローバルアプリケーションロードバランサーのバックエンドです。現在、Cloud Armorは設定されていません。IP_RANGE_BLOCK IP範囲に属する送信元IPアドレスを持つインターネットクライアントからのセッションをブロックするCloud Armorセキュリティポリシーを作成する必要があります。このブロックはCloud Armorセキュリティポリシーによって実行される必要があり、サードパーティのクラウドWAFプロバイダーでは行われません。どうすればよいですか？

あなたの組織、TerramEarthは、クレジットカード決済を管理するためのグローバルアプリケーションをローンチします。アプリケーションと同じVPC内に、このアプリケーションにプライベートにアクセスする必要があるクライアントVMがいくつかあります。コンプライアンス要件のため、内部クライアントはアプリケーションのグローバル外部IPアドレスを使用できません。現在、Cloud DNSはパブリックゾーンを使用して、myglobalapp.terramearth.comをパブリックIPアドレスにのみ解決します。クライアントは、外部IPアドレスを使用せずにmyglobalapp.terramearth.comに到達する必要があります。Googleの推奨プラクティスに従いながら、この要件を満たすようにCloud DNSを設定する必要があります。どうすべきですか？