nerdexam
Google

PROFESSIONAL-CLOUD-ARCHITECT · Question #305

Case Study: 11 - TerramEarth Company overview TerramEarth manufactures heavy equipment for the mining and agricultural industries. They currently have over 500 dealers and service centers in 100…

The correct answer is A. Use an HTTP(S) Load Balancer C. Use Cloud Endpoints/Apigee D. Use Serverless NEGs for integration. This question tests knowledge of the GCP services appropriate for exposing and managing APIs when decomposing a monolithic application into microservices.

Submitted by kev92· Mar 30, 2026Designing and planning a cloud solution architecture

Question

Case Study: 11 - TerramEarth Company overview TerramEarth manufactures heavy equipment for the mining and agricultural industries. They currently have over 500 dealers and service centers in 100 countries. Their mission is to build products that make their customers more productive. Solution concept There are 2 million TerramEarth vehicles in operation currently, and we see 20% yearly growth. Vehicles collect telemetry data from many sensors during operation. A small subset of critical data is transmitted from the vehicles in real time to facilitate fleet management. The rest of the sensor data is collected, compressed, and uploaded daily when the vehicles return to home base. Each vehicle usually generates 200 to 500 megabytes of data per day. Existing technical environment TerramEarth's vehicle data aggregation and analysis infrastructure resides in Google Cloud and serves clients from all around the world. A growing amount of sensor data is captured from their two main manufacturing plants and sent to private data centers that contain their legacy inventory and logistics management systems. The private data centers have multiple network interconnects configured to Google Cloud. The web frontend for dealers and customers is running in Google Cloud and allows access to stock management and analytics. Business requirements - Predict and detect vehicle malfunction and rapidly ship parts to dealerships for just-in-time repair where possible. - Decrease cloud operational costs and adapt to seasonality. - Increase speed and reliability of development workflow. - Allow remote developers to be productive without compromising code or data security. - Create a flexible and scalable platform for developers to create custom API services for dealers and partners. Technical requirements - Create a new abstraction layer for HTTP API access to their legacy systems to enable a gradual move into the cloud without disrupting operations. - Modernize all CI/CD pipelines to allow developers to deploy container-based workloads in highly scalable environments. - Allow developers to run experiments without compromising security and governance requirements. - Create a self-service portal for internal and partner developers to create new projects, request resources for data analytics jobs, and centrally manage access to the API endpoints. - Use cloud-native solutions for keys and secrets management and optimize for identity-based access. - Improve and standardize tools necessary for application and network monitoring and troubleshooting. Executive statement Our competitive advantage has always been our focus on the customer, with our ability to provide excellent customer service and minimize vehicle downtimes. After moving multiple systems into Google Cloud, we are seeking new ways to provide best-in- class online fleet management services to our customers and improve operations of our dealerships. Our 5-year strategic plan is to create a partner ecosystem of new products by enabling access to our data, increasing autonomous operation capabilities of our vehicles, and creating a path to move the remaining legacy systems to the cloud. For this question, refer to the TerramEarth case study. TerramEarth needs to migrate legacy monolithic applications into containerized RESTful microservices. The development team is experimenting with the use of packaged procedures with containers in a completely serverless environment, using Cloud Run. Before migrating the existing code into production it was decided to perform a lift and shift of the monolithic application and to develop the new features that are required with serverless microservices. So, they want to carry out a gradual migration, activating the new microservice functionalities while maintaining the monolithic application for all the other activities. The problem now is how to integrate the legacy monolithic application with the new microservices to have a consistent interface and simple management. Which of the following techniques can be used (pick 3)?

Options

  • AUse an HTTP(S) Load Balancer
  • BDevelop a proxy inside the monolithic application for integration
  • CUse Cloud Endpoints/Apigee
  • DUse Serverless NEGs for integration
  • EUse App Engine flexible edition

How the community answered

(58 responses)
  • A
    71% (41)
  • B
    10% (6)
  • E
    19% (11)

Why each option

This question tests knowledge of the GCP services appropriate for exposing and managing APIs when decomposing a monolithic application into microservices.

AUse an HTTP(S) Load BalancerCorrect

An HTTP(S) Load Balancer distributes incoming traffic across microservice backends, provides SSL termination, and enables path-based routing necessary for a microservices architecture.

BDevelop a proxy inside the monolithic application for integration

Building a proxy inside the monolithic application re-centralizes traffic through the monolith, defeating the purpose of decomposition and creating a single point of failure.

CUse Cloud Endpoints/ApigeeCorrect

Cloud Endpoints or Apigee provides API management capabilities including authentication, rate limiting, monitoring, and developer portal features needed to securely expose microservices to internal and external consumers.

DUse Serverless NEGs for integrationCorrect

Serverless NEGs (Network Endpoint Groups) allow the Load Balancer to route traffic directly to serverless backends such as Cloud Run or Cloud Functions, enabling integration without running dedicated VMs.

EUse App Engine flexible edition

App Engine flexible edition is a compute platform for running applications, not an integration or API management service, and does not solve the problem of exposing and managing microservice APIs.

Concept tested: API management and load balancing for microservices migration

Source: https://cloud.google.com/architecture/microservices-architecture-on-google-cloud

Topics

#HTTP(S) Load Balancer#Cloud Endpoints#Apigee#Serverless NEGs

Community Discussion

No community discussion yet for this question.

Full PROFESSIONAL-CLOUD-ARCHITECT Practice