Google Professional Cloud Network Engineer (PCNE) 덤프 및 해설

Your company operates a single Google Cloud project with three VPC networks (prod, stage, dev) across two regions; you must ensure that API calls to Cloud Bigtable and Artifact Registry are allowed only when requests originate from your corporate egress NAT public IP ranges 203.0.113.0/24 and 198.51.100.0/24, and on-prem systems access Google APIs over the public internet via those NATs; what should you do?

Your team manages a VPC named Studio that was created in auto mode for a global video-rendering platform; auto-mode VPCs reserve 10.128.0.0/9 for their subnets across regions. You must create a new VPC named Archive in the same project and connect it to Studio using VPC Network Peering so that internal RFC1918 traffic routes privately end-to-end without NAT; the two VPCs must have non-overlapping IP ranges now and as they scale. How should you configure the Archive VPC?

You are a network engineer at a global streaming company migrating core APIs to Google Cloud. These are the connectivity requirements: - On-premises connectivity with at least 20 Gbps from a single metro data center - Lowest-latency private access to Google Cloud (target: <5 ms one-way to nearest POP) - A centralized Network Engineering team must administer all WAN links and routing New product groups are creating separate Google Cloud projects and require private access to on-prem services from their workloads. You need the most cost-efficient design to connect the data center to Google Cloud while meeting the above requirements. What should you do?

Your company operates a globally available ticketing API for live events that is fronted by a global external HTTP(S) load balancer, and during flash sales traffic spikes to 250,000 requests per minute from more than 40 countries while your security team detects application-layer patterns such as SQL injection, cross-site scripting, and anomalous headers. You must protect the service against these application-level attacks at the edge without changing application code and attach the control to the existing load balancer backend; what should you do?

Your hardware startup distributes a critical smart door lock firmware globally via Cloud CDN in front of an external HTTP(S) load balancer with a Cloud Storage backend bucket. During a staggered rollout, you discover that the wrong firmware build (2.4.1-debug) was uploaded and has been cached worldwide; the object is served with Cache-Control: max-age=86400, and tens of thousands of devices have already pulled it. Your communications team has instructed customers to re-download the corrected firmware using the same URL (https://updates.example.com/locks/fw.bin). You must ensure that all subsequent downloads fetch the corrected firmware immediately from the same URL across all edge locations. What should you do?