Case Study

Google Cloud – EHR Healthcare Case Study

~ Last updated on : ~ jayendrapatil

Google Cloud – EHR Healthcare Case Study

EHR Healthcare is a leading provider of electronic health record software to the medical industry. EHR Healthcare provides its software as a service to multi-national medical offices, hospitals, and insurance providers.

📋 Exam Relevance (2025-2026): EHR Healthcare remains one of the four active case studies on the Google Cloud Professional Cloud Architect (PCA) exam. The case study focuses on healthcare workload migration, HIPAA compliance, hybrid connectivity, container orchestration, and centralized observability. Key service updates include GKE Autopilot (recommended for containerized workloads), Cloud Deployment Manager deprecation (March 2026, replaced by Terraform/Infrastructure Manager), and GKE Enterprise (formerly Anthos) for multi-cluster management.

Executive statement

Our on-premises strategy has worked for years but has required a major investment of time and money in training our team on distinctly different systems, managing similar but separate environments, and responding to outages. Many of these outages have been a result of misconfigured systems, inadequate capacity to manage spikes in traffic, and inconsistent monitoring practices. We want to use Google Cloud to leverage a scalable, resilient platform that can span multiple environments seamlessly and provide a consistent and stable user experience that positions us for future growth.

EHR Healthcare wants to move to Google Cloud to expand, build scalable and highly available applications. It also wants to leverage automation and IaaC to provide consistency across environments and reduce provisioning errors.

Solution Concept

Due to rapid changes in the healthcare and insurance industry, EHR Healthcare’s business has been growing exponentially year over year. They need to be able to scale their environment, adapt their disaster recovery plan, and roll out new continuous deployment capabilities to update their software at a fast pace. Google Cloud has been chosen to replace its current colocation facilities.

EHR wants to build a scalable, Highly Available, Disaster Recovery setup and introduce Continuous Integration and Deployment in their setup.

Existing Technical Environment

EHR’s software is currently hosted in multiple colocation facilities. The lease on one of the data centers is about to expire.
Customer-facing applications are web-based, and many have recently been containerized to run on a group of Kubernetes clusters. Data is stored in a mixture of relational and NoSQL databases (MySQL, MS SQL Server, Redis, and MongoDB).
EHR is hosting several legacy file- and API-based integrations with insurance providers on-premises. These systems are scheduled to be replaced over the next several years. There is no plan to upgrade or move these systems at the current time.
Users are managed via Microsoft Active Directory. Monitoring is currently being done via various open-source tools. Alerts are sent via email and are often ignored.

  • As the lease of one of the data centers is about to expire, time is critical
  • Some web applications are containerized and have SQL and NoSQL databases and can be moved
  • Some of the systems are legacy and would be replaced and need not be migrated
  • Team has multiple monitoring tools and might need consolidation

Business requirements

On-board new insurance providers as quickly as possible.

Provide a minimum 99.9% availability for all customer-facing systems.

  • Availability can be increased by hosting applications across multiple zones and using managed services which span multiple AZs
  • GKE regional clusters with Autopilot mode provide built-in high availability across zones with automated node management

Provide centralized visibility and proactive action on system performance and usage.

  • Google Cloud Observability (Cloud Monitoring + Cloud Logging + Cloud Trace) provides a unified platform for centralized visibility, alerting, and proactive action
  • Application Monitoring (launched 2025) automatically labels and correlates telemetry for registered applications
  • Cloud Logging can be used for log monitoring, analysis, and alerting

Increase ability to provide insights into healthcare trends.

  • Data can be pushed and analyzed using BigQuery (now a unified AI-ready data platform) and insights visualized using Data Studio
  • BigQuery ML enables building predictive ML models directly within BigQuery for healthcare trend analysis

Reduce latency to all customers.

  • Performance can be improved using Global Load Balancer to expose the applications
  • Applications can also be hosted across regions for low latency access
  • Cloud CDN or Media CDN can further reduce latency for static content delivery

Maintain regulatory compliance.

  • Regulatory compliance (HIPAA, HITRUST) can be maintained using data localization, data retention policies, as well as security measures
  • Assured Workloads helps configure compliant environments with guardrails
  • VPC Service Controls provides data exfiltration protection for sensitive healthcare data
  • Cloud Healthcare API provides HIPAA-compliant FHIR, HL7v2, and DICOM data management

Decrease infrastructure administration costs.

  • Infrastructure administration costs can be reduced using automation with Terraform or Infrastructure Manager (Google’s managed Terraform service)
  • Note: Cloud Deployment Manager reached End of Life on March 31, 2026. Use Terraform or Infrastructure Manager for all new IaC deployments

Make predictions and generate reports on industry trends based on provider data.

  • Data can be pushed and analyzed using BigQuery with built-in ML capabilities (BigQuery ML) for predictions
  • Vertex AI can be used for advanced ML model training on healthcare data

Technical requirements

Maintain legacy interfaces to insurance providers with connectivity to both on-premises systems and cloud providers.

  • Hybrid connectivity can be established using Cloud VPN, Dedicated Interconnect, or Partner Interconnect
  • Cross-Cloud Interconnect enables private connectivity to other cloud providers (AWS, Azure) if needed
  • Network Connectivity Center provides centralized hub-and-spoke network management for multi-cloud and hybrid environments

Provide a consistent way to manage customer-facing applications that are container-based.

  • Container-based applications can be deployed on GKE (Autopilot mode recommended for reduced operational overhead) or Cloud Run for serverless containers
  • GKE Enterprise (formerly Anthos) enables consistent multi-cluster management across environments with fleet-level policies
  • Cloud Deploy provides managed continuous delivery pipelines for GKE and Cloud Run

Provide a secure and high-performance connection between on-premises systems and Google Cloud.

  • Cloud VPN (HA VPN), Dedicated Interconnect, or Partner Interconnect connections can be established between on-premises and Google Cloud
  • Dedicated Interconnect provides 10/100 Gbps connections with 99.99% SLA when configured with recommended topology

Provide consistent logging, log retention, monitoring, and alerting capabilities.

  • Cloud Monitoring and Cloud Logging (part of Google Cloud Observability) provide a single pane of glass for monitoring, logging, and alerting
  • Managed Service for Prometheus enables Kubernetes-native monitoring with PromQL
  • OpenTelemetry Protocol (OTLP) support (2025) enables standardized telemetry collection

Maintain and manage multiple container-based environments.

  • Use Terraform or Infrastructure Manager to provide consistent implementations across environments
  • GKE Enterprise fleet management enables centralized policy and configuration across multiple GKE clusters
  • Cloud Service Mesh (replaced Anthos Service Mesh, GA June 2024) provides traffic management, security, and observability across microservices

Dynamically scale and provision new environments.

  • GKE Autopilot automatically provisions and scales nodes based on workload demands (recommended mode for new clusters)
  • GKE Standard clusters can use Cluster Autoscaler and HPA/VPA for deployments
  • Cloud Run provides automatic scaling from zero to thousands of instances

Create interfaces to ingest and process data from new providers.

  • Cloud Healthcare API provides FHIR R4, HL7v2, and DICOM interfaces for healthcare data ingestion and exchange
  • Pub/Sub enables real-time streaming data ingestion from multiple providers
  • Dataflow provides serverless stream and batch data processing pipelines

Key Google Cloud Services for EHR Healthcare

Requirement Google Cloud Service
Container Orchestration GKE (Autopilot mode), Cloud Run
Multi-cluster Management GKE Enterprise (fleet management)
Hybrid Connectivity Cloud VPN (HA), Dedicated/Partner Interconnect
Infrastructure as Code Terraform, Infrastructure Manager
Observability Cloud Monitoring, Cloud Logging, Cloud Trace
Data Analytics BigQuery, Data Studio, BigQuery ML
Healthcare Data Cloud Healthcare API (FHIR, HL7v2, DICOM)
Service Mesh Cloud Service Mesh
CI/CD Cloud Build, Cloud Deploy
Compliance Assured Workloads, VPC Service Controls
Relational Databases Cloud SQL (MySQL, SQL Server), AlloyDB
NoSQL Databases Memorystore (Redis), MongoDB Atlas on GCP
Identity Management Cloud Identity, Google Cloud Directory Sync (for AD)

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. For this question, refer to the EHR Healthcare case study. In the past, configuration errors put IP addresses on backend servers that should not have been accessible from the internet. You need to ensure that no one can put external IP addresses on backend Compute Engine instances and that external IP addresses can only be configured on the front end Compute Engine instances. What should you do?
    1. Create an organizational policy with a constraint to allow external IP addresses on the front end Compute Engine instances
    2. Revoke the compute.networkadmin role from all users in the project with front end instances
    3. Create an Identity and Access Management (IAM) policy that maps the IT staff to the compute.networkadmin role for the organization
    4. Create a custom Identity and Access Management (IAM) role named GCE_FRONTEND with the compute.addresses.create permission

    Explanation: The constraints/compute.vmExternalIpAccess organization policy constraint controls which VM instances can have external IP addresses. By configuring this constraint at the organization or project level and specifying only the front-end instances, you prevent backend instances from being assigned external IPs while allowing them on designated front-end instances.

  2. For this question, refer to the EHR Healthcare case study. EHR Healthcare needs to ensure consistent environments across development, staging, and production while reducing provisioning errors. Their infrastructure team currently uses manual processes. What should you recommend?
    1. Use Cloud Console to manually configure all environments and document the steps
    2. Create custom scripts using gcloud CLI to provision resources
    3. Use Terraform with Infrastructure Manager to define infrastructure as code and automate deployments across all environments
    4. Use Cloud Deployment Manager templates to provision all environments

    Explanation: Terraform with Infrastructure Manager (Google’s managed Terraform service) provides a declarative, version-controlled approach to infrastructure provisioning. Cloud Deployment Manager was deprecated and reached End of Life on March 31, 2026. Infrastructure Manager enables plan/apply workflows with built-in IAM, logging, and governance.

  3. For this question, refer to the EHR Healthcare case study. EHR Healthcare wants centralized visibility and proactive alerting for their containerized applications running on GKE. They want to consolidate their current fragmented monitoring tools. What should you recommend?
    1. Deploy Prometheus and Grafana on each GKE cluster independently
    2. Use Google Cloud Observability with Cloud Monitoring, Cloud Logging, and Managed Service for Prometheus for unified observability across all clusters
    3. Use a third-party monitoring solution deployed in a separate project
    4. Configure email alerts from each application individually

    Explanation: Google Cloud Observability (Cloud Monitoring + Cloud Logging + Cloud Trace + Managed Service for Prometheus) provides a unified, fully managed observability platform. Managed Service for Prometheus allows teams familiar with Prometheus to continue using PromQL while benefiting from global, managed storage and querying.

  4. For this question, refer to the EHR Healthcare case study. EHR Healthcare needs to manage multiple containerized environments consistently while ensuring security best practices. They want to reduce the operational overhead of managing Kubernetes clusters. What is the recommended approach?
    1. Deploy all workloads on Compute Engine instances with Docker
    2. Use GKE Standard mode with manual node pool management in each environment
    3. Use GKE Autopilot mode with GKE Enterprise fleet management for centralized policy and configuration across environments
    4. Deploy each application as a separate Cloud Run service without orchestration

    Explanation: GKE Autopilot mode provides a fully managed Kubernetes experience where Google manages nodes, scaling, and security hardening. GKE Enterprise fleet management enables centralized governance with fleet-level policies, Config Sync for GitOps, and Policy Controller for guardrails across multiple clusters and environments.

  5. For this question, refer to the EHR Healthcare case study. EHR Healthcare needs to maintain connectivity between their legacy on-premises insurance provider integrations and their new Google Cloud environment with high bandwidth and low latency. What should you recommend?
    1. Set up a standard VPN tunnel between on-premises and Google Cloud
    2. Use Dedicated Interconnect with redundant connections for high-bandwidth, low-latency, SLA-backed connectivity
    3. Use public internet with SSL/TLS encryption for all communications
    4. Migrate all legacy systems to Google Cloud immediately

    Explanation: Dedicated Interconnect provides 10/100 Gbps private connections between on-premises networks and Google Cloud with up to 99.99% SLA when configured with recommended redundant topology. The case study specifies legacy systems cannot be migrated immediately and require high-performance connectivity.

EHR Healthcare References

Google Cloud – HipLocal Case Study

~ Last updated on : ~ jayendrapatil

⚠️ Case Study Retired from PCA Exam (October 2025)

The HipLocal case study was retired from the Google Cloud Professional Cloud Architect (PCA) exam as of October 30, 2025 (exam version 6.1).

The updated PCA exam now includes the following case studies:

  • EHR Healthcare – Retained from the previous version
  • Altostrat Media – New; focuses on content management and AI-powered personalization
  • Cymbal Retail – New; focuses on real-time personalization and inventory optimization
  • KnightMotives Automotive – New; focuses on edge computing and IoT data ingestion

All new case studies incorporate AI integration as core business requirements, reflecting Google Cloud’s expanded Vertex AI and generative AI services.

This content is maintained for historical reference and for understanding Google Cloud architectural patterns related to global scaling, observability, and hybrid connectivity.

Google Cloud – HipLocal Case Study

HipLocal is a community application designed to facilitate communication between people in close proximity. It is used for event planning and organizing sporting events, and for businesses to connect with their local communities. HipLocal launched recently in a few neighborhoods in Dallas and is rapidly growing into a global phenomenon. Its unique style of hyper-local community communication and business outreach is in demand around the world.

Key point here is HipLocal is expanding globally

HipLocal Solution Concept

HipLocal wants to expand their existing service with updated functionality in new locations to better serve their global customers. They want to hire and train a new team to support these locations in their time zones. They will need to ensure that the application scales smoothly and provides clear uptime data, and that they analyze and respond to any issues that occur.

Key points here are HipLocal wants to expand globally, with an ability to scale and provide clear observability, alerting and ability to react.

HipLocal Existing Technical Environment

HipLocal’s environment is a mixture of on-premises hardware and infrastructure running in Google Cloud. The HipLocal team understands their application well, but has limited experience in globally scaled applications. Their existing technical environment is as follows:

  • Existing APIs run on Compute Engine virtual machine instances hosted in Google Cloud.
  • Expand availability of the application to new locations.
  • Support 10x as many concurrent users.
  • State is stored in a single instance MySQL database in Google Cloud.
  • Release cycles include development freezes to allow for QA testing.
  • The application has no consistent logging.
  • Applications are manually deployed by infrastructure engineers during periods of slow traffic on weekday evenings.
  • There are basic indicators of uptime; alerts are frequently fired when the APIs are unresponsive.

Business requirements

HipLocal’s investors want to expand their footprint and support the increase in demand they are experiencing. Their requirements are:

  • Expand availability of the application to new locations.
    • Availability can be achieved using either
      • scaling the application and exposing it through Global Load Balancer OR
      • deploying the applications across multiple regions.
  • Support 10x as many concurrent users.
    • As the APIs run on Compute Engine, the scale can be implemented using Managed Instance Groups frontend by a Load Balancer OR App Engine OR Container-based application deployment
    • Scaling policies can be defined to scale as per the demand.
    • Modern Alternative: Cloud Run provides a fully managed serverless container platform with automatic scaling to zero and per-request billing, making it an ideal choice for API workloads requiring global scale.
  • Ensure a consistent experience for users when they travel to different locations.
    • Consistent experience for the users can be provided using either
      • Google Cloud Global Load Balancer which uses GFE and routes traffic close to the users
      • multi-region setup targeting each region
  • Obtain user activity metrics to better understand how to monetize their product.
    • User activity data can also be exported to BigQuery for analytics and monetization
    • Cloud Monitoring and Cloud Logging (part of Google Cloud Observability) can be configured for application logs and metrics to provide observability, alerting, and reporting.
    • Cloud Logging can be exported to BigQuery for analytics
  • Ensure compliance with regulations in the new regions (for example, GDPR).
    • Compliance is shared responsibility, while Google Cloud ensures compliance of its services, application hosted on Google Cloud would be customer responsibility
    • GDPR or other regulations for data residency can be met using setup per region, so that the data resides with the region
    • Update: Google Cloud now offers Assured Workloads and data sovereignty controls to help enforce regional data residency and compliance requirements.
  • Reduce infrastructure management time and cost.
    • As the infrastructure is spread across on-premises and Google Cloud, it would make sense to consolidate the infrastructure into one place i.e. Google Cloud
    • Consolidation would help in automation, maintenance, as well as provide cost benefits.
    • Update: Google Cloud Migration Center provides automated workload assessment, dependency mapping, and migration planning to streamline the migration from on-premises.
  • Adopt the Google-recommended practices for cloud computing:
    • Develop standardized workflows and processes around application lifecycle management.
    • Define service level indicators (SLIs) and service level objectives (SLOs).
      • Update: Cloud Monitoring now provides built-in SLI/SLO monitoring with configurable burn rate alerts and error budgets, aligned with Google’s Site Reliability Engineering (SRE) practices.

Technical requirements

  • Provide secure communications between the on-premises data center and cloud hosted applications and infrastructure
    • Secure communications can be enabled between the on-premise data centers and the Cloud using Cloud VPN and Interconnect.
  • The application must provide usage metrics and monitoring.
    • Cloud Monitoring and Cloud Logging (part of Google Cloud Observability) can be configured for application logs and metrics to provide observability, alerting, and reporting.
    • Update: Google Cloud Observability now supports OpenTelemetry Protocol (OTLP) for both traces and metrics, enabling vendor-agnostic instrumentation. Application Monitoring in Cloud Observability provides pre-curated dashboards with SRE best practices.
  • APIs require authentication and authorization.
    • APIs can be configured for various Authentication mechanisms.
    • APIs can be exposed through Apigee API management platform for full lifecycle API management including authentication, rate limiting, and analytics.
    • Internal Applications can be exposed using Cloud Identity-Aware Proxy (IAP), which enforces the BeyondCorp zero-trust security model for secure access without VPN.
  • Implement faster and more accurate validation of new features.
    • QA Testing can be improved using automated testing
    • Production Release cycles can be improved using canary deployments to test the applications on a smaller base before rolling out to all.
    • Application can be deployed to App Engine which supports traffic splitting out of the box for canary releases
    • Modern Alternative: Cloud Run supports traffic splitting between revisions for canary deployments and gradual rollouts. Cloud Deploy provides managed continuous delivery with approval workflows and promotion across environments.
  • Logging and performance metrics must provide actionable information to be able to provide debugging information and alerts.
    • Cloud Monitoring and Cloud Logging (part of Google Cloud Observability) can be configured for application logs and metrics to provide observability, alerting, and reporting.
    • Cloud Logging can be exported to BigQuery for analytics using log sinks.
    • Update: Cloud Trace and Cloud Profiler provide distributed tracing and continuous profiling for identifying performance bottlenecks. Log Analytics enables SQL-based log querying directly within Cloud Logging.
  • Must scale to meet user demand.
    • As the APIs run on Compute Engine, the scale can be implemented using Managed Instance Groups frontend by a Load Balancer and using scaling policies as per the demand.
    • Single instance MySQL instance can be migrated to Cloud SQL. This would not need any application code changes and can be as-is migration. With read replicas to scale both horizontally and vertically seamlessly.
    • Update: AlloyDB for PostgreSQL is now available as a high-performance, PostgreSQL-compatible database with up to 4x faster transactional workloads and 100x faster analytical queries than standard PostgreSQL. For applications requiring global scale with strong consistency, Cloud Spanner remains an option.

Key Architectural Patterns (Updated for 2025-2026)

While HipLocal is no longer an active exam case study, the architectural patterns it illustrates remain relevant:

Modern Compute Options for API Workloads

  • Cloud Run – Fully managed serverless containers with automatic scaling, ideal for stateless API workloads. Supports traffic splitting for canary deployments.
  • GKE Autopilot – Fully managed Kubernetes for complex microservices architectures with automatic node provisioning.
  • Compute Engine MIGs – Still valid for stateful workloads or when specific VM configurations are required.

Modern Observability Stack

  • Google Cloud Observability (formerly Stackdriver/Operations Suite) – Unified platform for monitoring, logging, tracing, and profiling.
  • SLO Monitoring – Built-in SLI/SLO tracking with error budgets and burn rate alerts.
  • OpenTelemetry Support – OTLP for metrics and traces enables vendor-agnostic instrumentation.
  • Log Analytics – SQL-based log querying and BigQuery-linked log buckets for advanced analysis.

Modern API Management

  • Apigee – Full lifecycle API management with security policies, rate limiting, analytics, and developer portals. (Note: Cloud Endpoints Portal was deprecated in March 2023.)
  • Identity-Aware Proxy (IAP) – BeyondCorp zero-trust access for internal applications without VPN.

Modern Database Options

  • Cloud SQL – Managed MySQL/PostgreSQL/SQL Server with high availability, read replicas, and automated backups. Best for lift-and-shift MySQL migrations.
  • AlloyDB for PostgreSQL – High-performance PostgreSQL-compatible database with AI-native features including vector search.
  • Cloud Spanner – Globally distributed, strongly consistent database for applications requiring global scale.

CI/CD and Deployment

  • Cloud Build – Serverless CI/CD platform for building, testing, and deploying.
  • Cloud Deploy – Managed continuous delivery service with promotion workflows across environments.
  • Terraform / Infrastructure Manager – Infrastructure as Code for Google Cloud. (Note: Cloud Deployment Manager reached end of support on March 31, 2026. Migrate to Terraform or Infrastructure Manager.)

GCP Certification Exam Practice Questions

  • ⚠️ The HipLocal case study was retired from the PCA exam in October 2025. These questions are maintained for learning purposes and to understand Google Cloud architectural patterns.
  • GCP services are updated regularly and both the answers and questions might be outdated soon, so research accordingly.
  • Open to further feedback, discussion and correction.
  1. Which database should HipLocal use for storing state while minimizing application changes?
    1. Firestore
    2. BigQuery
    3. Cloud SQL
    4. Cloud Bigtable

    Note: Cloud SQL for MySQL is the correct answer as it’s a managed MySQL-compatible service requiring minimal application changes. AlloyDB would be the modern high-performance alternative for PostgreSQL workloads.

  2. Which architecture should HipLocal use for log analysis?
    1. Use Cloud Spanner to store each event.
    2. Start storing key metrics in Memorystore.
    3. Use Cloud Logging with a BigQuery sink.
    4. Use Cloud Logging with a Cloud Storage sink.

    Note: Cloud Logging with BigQuery sink (now called log sink with BigQuery-linked dataset) remains the best approach for log analytics. Log Analytics also provides direct SQL querying within Cloud Logging.

  3. HipLocal wants to improve the resilience of their MySQL deployment, while also meeting their business and technical requirements. Which configuration should they choose?
    1. ​Use the current single instance MySQL on Compute Engine and several read-only MySQL servers on Compute Engine.​
    2. ​Use the current single instance MySQL on Compute Engine, and replicate the data to Cloud SQL in an external master configuration.​
    3. ​Replace the current single instance MySQL instance with Cloud SQL, and configure high availability.​
    4. ​Replace the current single instance MySQL instance with Cloud SQL, and Google provides redundancy without further configuration.​

    Note: Cloud SQL high availability requires explicit configuration (regional HA with failover replica). It is not automatic by default.

  4. Which service should HipLocal use to enable access to internal apps?
    1. Cloud VPN
    2. Cloud Armor
    3. Virtual Private Cloud
    4. Cloud Identity-Aware Proxy

    Note: IAP enforces the BeyondCorp zero-trust model, providing authenticated access to internal apps without requiring a VPN. Now part of Google Cloud’s broader security portfolio.

  5. Which database should HipLocal use for storing user activity?
    1. BigQuery
    2. Cloud SQL
    3. Cloud Spanner
    4. Cloud Datastore

    Note: BigQuery remains the correct answer for analytics workloads on user activity data. Cloud Datastore has been rebranded to Firestore in Datastore mode.

Additional Practice Questions (Architectural Patterns)

  1. HipLocal wants to modernize their API deployment for global scale with minimal infrastructure management. Which solution best meets their needs?
    1. Deploy APIs on Compute Engine MIGs behind a Global HTTP(S) Load Balancer
    2. Deploy containerized APIs on Cloud Run with a Global External Application Load Balancer
    3. Deploy APIs on App Engine flexible environment
    4. Deploy APIs on GKE Standard with cluster autoscaler

    Cloud Run provides automatic scaling (including to zero), global deployment, and minimal infrastructure management. Combined with the Global External Application Load Balancer, it provides the least operational overhead.

  2. HipLocal needs to implement Infrastructure as Code for their Google Cloud resources. Which is the recommended approach in 2026?
    1. Cloud Deployment Manager with YAML templates
    2. Terraform with the Google Cloud provider
    3. Custom scripts using gcloud CLI
    4. Pulumi with TypeScript

    Cloud Deployment Manager reached end of support on March 31, 2026. Terraform is the recommended IaC tool for Google Cloud and is now explicitly required knowledge for the PCA exam.

  3. HipLocal wants to define and monitor SLOs for their APIs. Which Google Cloud services should they use? (Choose 2)
    1. Cloud Monitoring with SLO monitoring
    2. Cloud Scheduler
    3. Cloud Logging with log-based metrics
    4. Cloud Tasks

    Cloud Monitoring provides built-in SLO monitoring with burn rate alerts. Log-based metrics from Cloud Logging can serve as SLIs (e.g., error rates) for SLO tracking.

Reference

Google Cloud – TerramEarth Case Study

~ Last updated on : ~ jayendrapatil ~ 2 Comments

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.

Key points here are 500 dealers and service centers are spread across the world and they want to 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

Key points here are TerramEarth has 2 million vehicles. Only critical data is transferred in real-time while the rest of the data is uploaded in bulk daily.

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.

Key point here is the company wants to improve further in operations, customer experience, and partner ecosystem by allowing them to reuse the data.

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.

Key point here is the company is hosting its infrastructure in Google Cloud and private data centers. GCP has web frontend and vehicle data aggregation & analysis. Data is sent to private data centers.

Business Requirements

Predict and detect vehicle malfunction and rapidly ship parts to dealerships for just-in-time repair where possible.

  • ⚠️ Note: Cloud IoT Core was shut down on August 16, 2023. For IoT device connectivity, Google Cloud now recommends a Pub/Sub-based architecture with a standalone MQTT broker (e.g., EMQX, HiveMQ, or ClearBlade IoT Core) for device management and ingestion. The downstream pipeline (Pub/Sub → Dataflow → BigQuery) remains the same.
  • A Pub/Sub-based device messaging architecture with a third-party MQTT broker can provide secure device connectivity, management, and data ingestion from globally dispersed vehicles.
  • Existing legacy inventory and logistics management systems running in the private data centers can be migrated to Google Cloud.
  • Existing data can be migrated one time using Transfer Appliance.

Decrease cloud operational costs and adapt to seasonality.

    • Google Cloud provides configuring elasticity and scalability for resources based on the demand.

Increase speed and reliability of development workflow.

    • Google Cloud CI/CD tools like Cloud Build and Cloud Deploy can be used to increase the speed and reliability of the deployments. Cloud Deploy is a fully managed continuous delivery service for GKE and Cloud Run.

Allow remote developers to be productive without compromising code or data security.

  • Cloud Run functions (formerly Cloud Functions) supports function-to-function authentication for secure internal communication.

Create a flexible and scalable platform for developers to create custom API services for dealers and partners.

  • Google Cloud provides multiple fully managed serverless and scalable application hosting solutions like Cloud Run and Cloud Run functions (formerly Cloud Functions). Cloud Run now supports GPU workloads, worker pools, and deploying via Compose files.
  • Managed Instance group with Compute Engines and GKE cluster with scaling can also be used to provide scalable, highly available compute services.

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.

    • Google Cloud API Gateway & Cloud Endpoints can be used to provide an abstraction layer to expose the data externally over a variety of backends. Cloud Endpoints now supports OpenAPI 3.0 specifications.

Modernize all CI/CD pipelines to allow developers to deploy container-based workloads in highly scalable environments.

Google Cloud CI/CD - Continuous Integration Continuous Deployment

    • Google Cloud provides DevOps tools like Cloud Build and Cloud Deploy (fully managed continuous delivery) to provide CI/CD features. Spinnaker remains supported as an open-source option for multi-cloud deployments.
    • ⚠️ Update: Cloud Source Repositories reached end-of-sale on June 17, 2024 and is no longer available to new customers. Secure Source Manager is the recommended replacement — a regionally deployed, single-tenant managed source code repository on Google Cloud.
    • Cloud Build is a fully-managed, serverless service that executes builds on Google Cloud’s infrastructure.
    • ⚠️ Update: Container Registry was shut down on March 18, 2025. Artifact Registry is the required replacement, supporting both container images and non-container artifacts (Maven, npm, Python, etc.).
    • Artifact Registry is the single artifact management service for container images, language packages, and OS packages on Google Cloud.
    • Cloud Deploy is a fully managed continuous delivery service that automates delivery to GKE and Cloud Run with promotion sequences, deploy policies, canary deployments, and automated rollbacks.

Allow developers to run experiments without compromising security and governance requirements

    • Google Cloud Deploy supports canary deployments and automated rollbacks. Cloud Run provides traffic splitting for A/B testing and gradual rollouts.

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

    • Google Cloud supports Cloud Key Management Service (Cloud KMS) and Secret Manager for managing secrets and key management. Cloud KMS now supports quantum-safe key encapsulation mechanisms, and Secret Manager supports integrated secret synchronization with GKE clusters.

Improve and standardize tools necessary for application and network monitoring and troubleshooting.

    • Google Cloud provides Cloud Operations Suite (Google Cloud Observability) which includes Cloud Monitoring and Logging to cover both on-premises and Cloud resources.
    • Cloud Monitoring collects measurements of key aspects of the service and of the Google Cloud resources used. It now integrates with App Hub for Application Monitoring dashboards with trace span visibility.
    • Cloud Monitoring Uptime check is a request sent to a publicly accessible IP address on a resource to see whether it responds.
    • Cloud Logging is a service for storing, viewing, and interacting with logs.
    • Error Reporting aggregates and displays errors produced in the running cloud services.
    • Cloud Profiler helps with continuous CPU, heap, and other parameters profiling to improve performance and reduce costs.
    • Cloud Trace is a distributed tracing system that collects latency data from the applications and displays it in the Google Cloud Console.
    • ⚠️ Update: Cloud Debugger was shut down on May 31, 2023. For production debugging capabilities, use Snapshot Debugger (open-source) or Cloud Logging and Cloud Trace for troubleshooting.

Reference Cellular Upload Architecture

Batch Upload Replacement Architecture

Key Updates for Certification Exam (2024-2026)

The TerramEarth case study remains part of the Professional Cloud Architect certification exam. When answering exam questions related to this case study, keep the following service changes in mind:

  • IoT Device Connectivity: Cloud IoT Core is no longer available. Use Pub/Sub with a standalone MQTT broker for device telemetry ingestion.
  • CI/CD Pipeline: Cloud Deploy is the preferred managed CD solution. Container Registry has been replaced by Artifact Registry. Cloud Source Repositories is replaced by Secure Source Manager.
  • Serverless: Cloud Functions is now Cloud Run functions, unified under the Cloud Run platform.
  • Observability: Cloud Debugger is no longer available. Use Cloud Trace, Cloud Logging, and Snapshot Debugger instead.
  • Security: Cloud KMS now supports quantum-safe encryption. Secret Manager supports GKE secret synchronization.

Reference

Google Cloud – Dress4win Case Study

~ Last updated on : ~ jayendrapatil

⚠️ Case Study No Longer on Current PCA Exam

The Dress4Win case study has been retired from the Google Cloud Professional Cloud Architect (PCA) exam.

The current PCA exam (v6.1, updated October 2025) uses four case studies: EHR Healthcare, Altostrat Media, Cymbal Retail, and KnightMotives Automotive. All now incorporate AI integration as core business requirements.

This content is maintained for historical reference and as a learning exercise for GCP migration architecture concepts. The architectural patterns discussed remain relevant for real-world cloud migrations.

Dress4Win is a web-based company that helps their users organize and manage their personal wardrobe using a web app and mobile application. The company also cultivates an active social network that connects their users with designers and retailers. They monetize their services through advertising, e-commerce, referrals, and a freemium app model. The application has grown from a few servers in the founder’s garage to several hundred servers and appliances in a colocated data center. However, the capacity of their infrastructure is now insufficient for the application’s rapid growth. Because of this growth and the company’s desire to innovate faster, Dress4Win is committing to a full migration to a public cloud.

The key here is the company wants to migrate completely to public cloud for the current infrastructures inability to scale

Solution Concept

For the first phase of their migration to the cloud, Dress4Win is moving their development and test environments. They are also building a disaster recovery site, because their current infrastructure is at a single location. They are not sure which components of their architecture they can migrate as is and which components they need to change before migrating them.

Key here is Dress4Win wants to move the development and test environments first. And also, they want to build a DR site for their current production site which would continue to be hosted on-premises

Executive Statement

Our investors are concerned about our ability to scale and contain costs with our current infrastructure. They are also concerned that a competitor could use a public cloud platform to offset their up-front investment and free them to focus on developing better features. Our traffic patterns are highest in the mornings and weekend evenings; during other times, 80% of our capacity is sitting idle.

Our capital expenditure is now exceeding our quarterly projections. Migrating to the cloud will likely cause an initial increase in spending, but we expect to fully transition before our next hardware refresh cycle. Our total cost of ownership (TCO) analysis over the next 5 years for a public cloud strategy achieves a cost reduction between 30% and 50% over our current model.

The key here is that the company wants to improve on the application scalability, efficiency (hardware sitting idle most of the time), capex cost reduction, and improve TCO over a period of time

Existing Technical Environment

The Dress4Win application is served out of a single data center location. All servers run Ubuntu LTS v16.04.

Databases:

  • MySQL. 1 server for user data, inventory, static data,
    • MySQL 5.8
    • 8 core CPUs
    • 128 GB of RAM
    • 2x 5 TB HDD (RAID 1)
  • Redis 3 server cluster for metadata, social graph, caching. Each server is:
    • Redis 3.2
    • 4 core CPUs
    • 32GB of RAM
  • MySQL server can be migrated directly to Cloud SQL, which is GCP managed relational database and supports MySQL. For PostgreSQL-compatible workloads requiring higher performance, AlloyDB (GA since 2022) is also an option offering up to 4x throughput vs. standard PostgreSQL.
  • For Redis cluster, Memorystore for Redis or Memorystore for Valkey (GA since 2025, recommended for new deployments) can be used. Valkey is a Redis-compatible open-source fork offering 99.99% SLA, cross-region replication, and supports versions 7.2, 8.0, and 9.0. Memorystore for Redis Cluster remains available for existing Redis workloads.
  • There would be no changes required to support the same.

Compute:

  • 40 Web Application servers providing micro-services based APIs and static content.
    • Tomcat – Java
    • Nginx
    • 4 core CPUs
    • 32 GB of RAM
  • 20 Apache Hadoop/Spark servers:
    • Data analysis
    • Real-time trending calculations
    • 8 core CPUs
    • 128 GB of RAM
    • 4x 5 TB HDD (RAID 1)
  • 3 RabbitMQ servers for messaging, social notifications, and events:
    • 8 core CPUs
    • 32GB of RAM
  • Miscellaneous servers:
    • Jenkins, monitoring, bastion hosts, security scanners
    • 8 core CPUs
    • 32GB of RAM
  • Web Application servers with Java and Nginx can be supported using Compute Engine, Cloud Run (for containerized microservices with automatic scaling), or Google Kubernetes Engine (GKE) (formerly Container Engine) with autoscaling configured. GKE Autopilot mode simplifies cluster management further.
  • Although the core and RAM combination would need a custom machine type, the same be configured or tuned to use an existing machine type
  • Apache Hadoop/Spark servers can be easily migrated to Dataproc (now part of the Managed Service for Apache Spark brand), which provides managed Hadoop and Spark clusters with autoscaling that can reduce VM costs by up to 40%.
  • RabbitMQ messaging service is currently not directly supported by Google Cloud and can be supported either with
    • Cloud Pub/Sub messaging – however this would need changes to the code and would not be a seamless migration. Pub/Sub now also supports streaming ingestion from external sources and export subscriptions to BigQuery/Cloud Storage.
    • Use Compute Engine to host the RabbitMQ servers
  • Jenkins, Bastion hosts, Security scanners can be hosted using Google Compute Engine (GCE). For CI/CD, Cloud Build is also available as a managed alternative to self-hosted Jenkins.
  • Monitoring can be provided using Google Cloud Operations Suite (formerly Stackdriver), which includes Cloud Monitoring, Cloud Logging, Cloud Trace, and Cloud Profiler.

Storage appliances:

  • iSCSI for VM hosts
  • Fiber channel SAN – MySQL databases
    • 1 PB total storage; 400 TB available
  • NAS – image storage, logs, backups
    • 100 TB total storage; 35 TB available
  • iSCSI for VM hosts can be supported using Cloud Persistent Disks (or Hyperdisk for higher performance requirements) as it needs a block level storage
  • SAN for MySQL databases can be supported using Cloud Persistent Disks as it needs a block level storage. However, a single disk cannot scale to 1PB and multiple disks need to be combined to create the storage
  • NAS for image storage, logs and backups can be supported using Cloud Storage which provides unlimited storage capacity. For file-system access (NFS), Filestore provides a managed NFS file server.

Business Requirements

  • Build a reliable and reproducible environment with scaled parity of production.
    • can be handled by provisioning services or using GCP managed services with the same scale as on-premises resources and with Terraform or Infrastructure Manager for creating repeatable deployments
  • Improve security by defining and adhering to a set of security and Identity and Access Management (IAM) best practices for cloud.
    • can be handled using IAM by implemented best practices like least privileges, separating dev/test/production projects to control access
  • Improve business agility and speed of innovation through rapid provisioning of new resources.
    • can be handled using Terraform or Infrastructure Manager for repeatable and automated provisioning of resources
    • deployments of applications and new releases can be handled efficiently using rolling updates, A/B testing, and Cloud Deploy for managed continuous delivery
  • Analyze and optimize architecture for performance in the cloud.
    • can be handled using autoscaling Compute Engine instances based on the demand
    • can be handled using Google Cloud Operations Suite (Cloud Monitoring, Cloud Logging) for monitoring and fine tuning the specs, plus Active Assist recommendations for rightsizing

Technical Requirements

  • Easily create non-production environments in the cloud.
    • most of the services can be created using GCP managed services and the environment creation can be standardized and automated using templates and configurations
  • Implement an automation framework for provisioning resources in cloud.
    • can be handled using Terraform (recommended) or Infrastructure Manager, which provide Infrastructure as Code (IaC) for provisioning resources in cloud. Note: Cloud Deployment Manager reached end of support on March 31, 2026 and should not be used for new projects.
  • Implement a continuous deployment process for deploying applications to the on-premises datacenter or cloud.
    • continuous deployments can be handled using tools like Jenkins available on both the environments, or Cloud Build with Cloud Deploy for GCP-native CI/CD pipelines
  • Support failover of the production environment to cloud during an emergency.
    • can be handled by replicating all the data to the cloud environment and ability to provision the servers quickly.
    • can be handled by using Cloud DNS to repoint from on-premises environment to cloud environment
  • Encrypt data on the wire and at rest.
    • All the GCP services, by default, provide encryption on wire and at rest. Encryption can be performed using Google-managed keys, Customer-Managed Encryption Keys (CMEK) via Cloud KMS, or Customer-Supplied Encryption Keys (CSEK)
  • Support multiple private connections between the production data center and cloud environment.
    • can be handled using Cloud VPN (multiple VPN tunnels with HA VPN for 99.99% SLA) or Dedicated Interconnect/Partner Interconnect connection between the production data center and the cloud environment. For multi-cloud connectivity, Cross-Cloud Interconnect is also available.

Updated GCP Service Mapping (2025-2026)

The following table summarizes the recommended GCP services for the Dress4Win migration, reflecting current service names and availability:

  • Relational Database: Cloud SQL (MySQL/PostgreSQL) or AlloyDB (for PostgreSQL-compatible high-performance workloads)
  • In-Memory Cache: Memorystore for Valkey (recommended for new deployments, 99.99% SLA) or Memorystore for Redis Cluster
  • Web Application Hosting: GKE (Google Kubernetes Engine), Cloud Run, or Compute Engine
  • Big Data/Analytics: Dataproc (Managed Service for Apache Spark) with autoscaling, or BigQuery for analytics
  • Messaging: Cloud Pub/Sub (managed) or self-hosted RabbitMQ on Compute Engine
  • Monitoring: Google Cloud Operations Suite (Cloud Monitoring, Cloud Logging, Cloud Trace)
  • IaC/Provisioning: Terraform or Infrastructure Manager (NOT Cloud Deployment Manager — deprecated)
  • CI/CD: Cloud Build + Cloud Deploy, or Jenkins on Compute Engine
  • Block Storage: Persistent Disk or Hyperdisk
  • Object/File Storage: Cloud Storage (objects), Filestore (NFS)
  • Networking: HA Cloud VPN, Dedicated/Partner Interconnect, Cross-Cloud Interconnect
  • Encryption: Google-managed keys, CMEK (Cloud KMS), or CSEK

References