An autonomous drone logistics enterprise manages multi-environment Google Cloud infrastructure using Terraform within a central continuous integration and continuous deployment (CI/CD) pipeline. The security engineering team requires that pipeline executions avoid using long-lived service account keys, prevent concurrent pipeline state corruption, and strictly enforce state file integrity across environments. Which architectural pattern should the cloud architect recommend?
- Configure a Google Cloud Storage (GCS) remote backend with object versioning enabled, and authenticate the Cloud Build CI/CD pipeline using Workload Identity Federation bound to a least-privilege service account.Cevap
- BStore Terraform state files on a local shared persistent disk attached to a Compute Engine instance running an NFS server, and execute terraform apply remotely over SSH.
- CExport a service account key JSON file with the Project Owner primitive role and securely store it as an encrypted environment variable inside the CI/CD pipeline system.
- DStore state files locally within the CI/CD runner container workspace and instruct operators to manually adjust out-of-sync Cloud Console resources whenever terraform plan reports differences.
Cevap
Configure a Google Cloud Storage (GCS) remote backend with object versioning enabled, and authenticate the Cloud Build CI/CD pipeline using Workload Identity Federation bound to a least-privilege service account.
Google Cloud Storage (GCS) is the recommended native backend for Terraform on GCP because it natively supports object locking to prevent concurrent state modifications and versioning for disaster recovery. Authenticating pipelines via Workload Identity Federation removes the security risk of managing static JSON keys, while scoped service accounts uphold least-privilege security controls.
Adım Adım Çözüm
Anahtar Kavram
Terraform Remote Backend Architecture & Keyless CI/CD Authentication on GCP
Tahmini Süre:1m 30s