PROFESSIONAL-CLOUD-ARCHITECT Question #330: Real Exam Question with Answer & Explanation

Question

Case Study: 9 - Helicopter Racing League Company overview Helicopter Racing League (HRL) is a global sports league for competitive helicopter racing. Each year HRL holds the world championship and several regional league competitions where teams compete to earn a spot in the world championship. HRL offers a paid service to stream the races all over the world with live telemetry and predictions throughout each race. Solution concept HRL wants to migrate their existing service to a new platform to expand their use of managed AI and ML services to facilitate race predictions. Additionally, as new fans engage with the sport, particularly in emerging regions, they want to move the serving of their content, both real-time and recorded, closer to their users. Existing technical environment HRL is a public cloud-first company; the core of their mission-critical applications runs on their current public cloud provider. Video recording and editing is performed at the race tracks, and the content is encoded and transcoded, where needed, in the cloud. Enterprise-grade connectivity and local compute is provided by truck-mounted mobile data centers. Their race prediction services are hosted exclusively on their existing public cloud provider. Their existing technical environment is as follows: Existing content is stored in an object storage service on their existing public cloud provider. Video encoding and transcoding is performed on VMs created for each job. Race predictions are performed using TensorFlow running on VMs in the current public cloud provider. Business requirements HRL's owners want to expand their predictive capabilities and reduce latency for their viewers in emerging markets. Their requirements are: Support ability to expose the predictive models to partners. Increase predictive capabilities during and before races: ○ Race results ○ Mechanical failures ○ Crowd sentiment Increase telemetry and create additional insights. Measure fan engagement with new predictions. Enhance global availability and quality of the broadcasts. Increase the number of concurrent viewers. Minimize operational complexity. Ensure compliance with regulations. Create a merchandising revenue stream. Technical requirements Maintain or increase prediction throughput and accuracy. Reduce viewer latency. Increase transcoding performance. Create real-time analytics of viewer consumption patterns and engagement. Create a data mart to enable processing of large volumes of race data. Executive statement Our CEO, S. Hawke, wants to bring high-adrenaline racing to fans all around the world. We listen to our fans, and they want enhanced video streams that include predictions of events within the race (e.g., overtaking). Our current platform allows us to predict race outcomes but lacks the facility to support real-time predictions during races and the capacity to process season-long results. For this question, refer to the Helicopter Racing League (HRL) case study. Recently HRL started a new regional racing league in Cape Town, South Africa. In an effort to give customers in Cape Town a better user experience, HRL has partnered with the Content Delivery Network provider, Fastly. HRL needs to allow traffic coming from all of the Fastly IP address ranges into their Virtual Private Cloud network (VPC network). You need to configure the update that will allow only the Fastly IP address ranges through the External HTTP(S) load balancer. Which should you do?

Options

• AApply a Cloud Armor security policy to external load balancers using a named IP list for Fastly.
• BApply a Cloud Armor security policy to external load balancers using the IP addresses that Fastly
• CApply a VPC firewall rule on port 443 for Fastly IP address ranges.
• DApply a VPC firewall rule on port 443 for network resources tagged with sourceiplist-fastly.

Explanation

Option A is correct because Google Cloud Armor supports named IP lists - pre-configured, automatically maintained sets of IP ranges for well-known CDN providers like Fastly - and Cloud Armor policies are the proper mechanism to control traffic at the External HTTP(S) load balancer layer, sitting upstream of the VPC.

Option B is wrong because manually specifying individual Fastly IP addresses is operationally burdensome and fragile; Fastly's IP ranges change over time, making named IP lists the correct managed approach for exactly this use case.

Options C and D are wrong because VPC firewall rules apply to traffic reaching VM instances inside the VPC, not to an External HTTP(S) load balancer - that load balancer is a Google-managed global service that doesn't sit inside your VPC. Additionally, the tag sourceiplist-fastly (Option D) is a Cloud Armor concept, not a valid VPC firewall tag.

Memory tip: Think of it as layers - Cloud Armor guards the front door (external load balancer), while VPC firewall rules guard the inside rooms (VM instances). CDN allowlisting happens at the front door, and named IP lists let Google maintain the guest list for you automatically.

No community discussion yet for this question.