Cloud Digital Leader Scaling with Google Cloud operations Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Deploy identical origin servers in every Google Cloud region globally.

  Why it's wrong here

  Deploying identical origin servers in every Google Cloud region would mean maintaining full application state, storage, and compute redundancy in dozens of locations, with complex cross-region synchronization and data consistency challenges. This approach is not only operationally expensive but also unnecessary, since a CDN already caches the actual video bytes at edge locations—which are more numerous and closer to viewers than regional origins. For dynamic or personalized content, you would still need a centralized origin or a different strategy; for static video, the CDN gives the same latency benefit without the cost of global server replication.

• ✓

  Enable Cloud CDN to cache video content at Google's global edge PoPs, serving viewers from the nearest location.

  Why this is correct

  Cloud CDN leverages Google's global edge points of presence (PoPs) to cache and serve video content from the location geographically nearest to each viewer. When an Asian viewer requests a video, the request is routed to a nearby edge cache rather than traversing the long-haul network path to us-central1, which dramatically reduces round-trip time and jitter. Additionally, because edge caches absorb the bulk of repeated requests, the origin servers see far fewer direct hits, which reduces origin load and allows the infrastructure to scale cost-effectively for global audiences.

• ✗

  Use Cloud VPN to route viewer traffic through a direct tunnel to the origin servers.

  Why it's wrong here

  Cloud VPN establishes an encrypted IPsec tunnel between your VPC and an on-premises or other cloud network; it simply provides secure connectivity between fixed networks. Routing viewer traffic over a VPN to origin servers in us-central1 does not shorten the physical distance between Asian viewers and the origin, so latency remains high. In fact, IPsec encryption and encapsulation add CPU overhead and packet overhead, making streaming performance worse than a direct public internet path, and it provides no caching or edge delivery capability whatsoever.

• ✗

  Increase the origin servers' network bandwidth to handle more simultaneous viewer connections.

  Why it's wrong here

  Increasing the network bandwidth or egress capacity of the origin servers allows them to handle more simultaneous connections and throughput, but it does nothing to reduce the physical propagation delay between the origin's location (us-central1) and viewers in Asia. Distance-based latency—on the order of hundreds of milliseconds across continents—is a fundamental property of the speed of light in fiber, and additional bandwidth cannot overcome it. The correct solution is to move content closer to viewers via edge caching, not to make a single distant server faster.

Go deeper

Related to this question