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?
- 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
- BCommit Terraform state files directly into the application source control repository for versioning, and refactor the tracking payload validation microservice to run on Cloud Run.
- CStore 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.
- DStore 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.