Question

Difficulty: HardAssessing and Mitigating Technical Debt in Cloud Architectures

A global logistics enterprise migrated its order tracking platform to Google Cloud under tight deadline constraints. A post-migration architecture review identified two primary sources of technical debt causing operational friction:
1. Infrastructure deployment pipelines fail frequently due to state corruption and concurrency conflicts because Terraform state files are stored on local build worker drives.
2. A simple, stateless HTTP microservice used solely for tracking payload validation is hosted on a dedicated standard Google Kubernetes Engine (GKE) cluster, resulting in high operational management overhead and idle compute costs.

Which combination of architectural refactoring actions best mitigates this technical debt while adhering to Google Cloud recommended practices?

  1. Store Terraform state in a Google Cloud Storage bucket configured with object versioning and state locking, and refactor the tracking payload validation microservice to run on Cloud Run.Answer
  2. B
    Commit Terraform state files directly into the application source control repository for versioning, and refactor the tracking payload validation microservice to run on Cloud Run.
  3. C
    Store Terraform state in a Google Cloud Storage bucket configured with object versioning, and migrate the stateless payload validation logic into a high-availability Cloud Spanner instance.
  4. D
    Store Terraform state in a Google Cloud Storage bucket configured with object versioning, and assign the primitive Project Owner role to CI/CD pipeline service accounts to resolve deployment permission errors.

Answer

Store Terraform state in a Google Cloud Storage bucket configured with object versioning and state locking, and refactor the tracking payload validation microservice to run on Cloud Run.
Migrating Terraform state management to a Google Cloud Storage bucket with object versioning provides automated object locking during concurrent execution pipelines, preventing configuration drift and state file corruption. Concurrently, migrating a simple stateless HTTP payload validation service from standard GKE to Cloud Run eliminates Kubernetes cluster management overhead, control plane costs, and manual node pool maintenance while enabling serverless scale-to-zero compute.

Step-by-Step Solution

1
Analyze the technical debt accrued in the Infrastructure as Code (IaC) lifecycle.
Identified that local Terraform state storage causes concurrency conflicts and state file corruption across deployment runners.
Google Cloud Storage provides native remote backend support for Terraform with automated file locking and versioning.
2
Evaluate compute engine requirements for the stateless validation microservice.
Hosting a lightweight, stateless HTTP validation microservice on standard GKE imposes unnecessary cluster management overhead, master node baseline costs, and scaling configuration complexity.
Cloud Run is a fully managed serverless container platform ideal for stateless HTTP workloads, removing cluster infrastructure maintenance entirely while reducing cost via scale-to-zero capabilities.
3
Synthesize the optimal mitigation strategy adhering to GCP best practices.
Combine Cloud Storage for centralized Terraform state management with Cloud Run for serverless container execution.
This paired solution directly addresses operational toil, cost inefficiency, and deployment instability.

Key Concept

Mitigating operational and architectural technical debt using managed serverless compute (Cloud Run) and centralized remote IaC state backends (Cloud Storage).
Estimated Time:2m 0s
Rate this question