Question

Difficulty: HardImplementing Infrastructure as Code using Terraform and Deployment Manager

A global media streaming organization currently manages its core Google Cloud Virtual Private Cloud (VPC) subnets and Compute Engine template deployments using legacy Google Cloud Deployment Manager deployments. The enterprise platform team is executing a strategic migration to standardize all infrastructure automation on Terraform. The Cloud Architect must establish a state migration workflow that imports existing live resources into Terraform without destroying active workloads or causing configuration drift, while ensuring automated CI/CD execution complies with Google Cloud identity and state management security best practices. Which migration and operational workflow should the Cloud Architect recommend?

  1. A
    Export existing Deployment Manager manifests to local disk, configure a remote Terraform state backend using a Cloud Storage bucket, and grant the CI/CD pipeline service account the primitive Owner role (roles/owner) on the target project to ensure terraform import bypasses granular permission checks.
  2. Define equivalent HCL resource declarations in Terraform, configure a remote Cloud Storage backend with object versioning and state locking enabled, authenticate the automated CI/CD pipeline using short-lived Service Account impersonation via Workload Identity Federation, and execute terraform import commands for existing resources.Answer
  3. C
    Define equivalent HCL resource declarations, store state files locally within the CI/CD build worker directory using a Git commit hook to sync state back to Cloud Source Repositories, and execute gcloud deployment-manager deployments delete with the ABANDON flag prior to running terraform apply.
  4. D
    Grant the deployment service account the Service Account Admin role (roles/iam.serviceAccountAdmin) across the organization hierarchy, download static JSON service account keys into the CI/CD pipeline secrets, and execute terraform apply to recreate all managed resources from scratch.

Answer

Define equivalent HCL resource declarations in Terraform, configure a remote Cloud Storage backend with object versioning and state locking enabled, authenticate the automated CI/CD pipeline using short-lived Service Account impersonation via Workload Identity Federation, and execute terraform import commands for existing resources.
The recommended approach combines remote state governance in Cloud Storage with state locking and object versioning, keyless pipeline authentication using Workload Identity Federation, and non-destructive state ingestion via terraform import. This ensures active live resources managed by Cloud Deployment Manager are seamlessly mapped into Terraform management without service downtime, while enforcing Google Cloud security standards.

Step-by-Step Solution

1
Configure Remote State Management
Establish a Cloud Storage backend configured with object versioning and state locking (via Cloud KMS or native GCS state lock support) to prevent state corruption and enable state history recovery.
Enterprise Terraform execution requires centralized, locked, and versioned state storage to allow concurrent pipeline executions safely.
2
Implement Keyless CI/CD Pipeline Authentication
Configure Workload Identity Federation to allow external CI/CD pipelines to impersonate dedicated deployment service accounts with fine-grained IAM roles without static JSON keys.
Eliminates security risks associated with managing and storing long-lived service account keys.
3
Import Legacy Deployment Manager Resources into Terraform State
Write corresponding HCL resource blocks matching existing cloud infrastructure parameters and execute `terraform import` targeting existing Google Cloud resource IDs.
Binds existing live infrastructure to the Terraform state file without destroying or redeploying running workloads, avoiding downtime.

Key Concept

Terraform Remote State Locking, Resource Import, and Workload Identity Impersonation
Estimated Time:2m 30s
Rate this question