Question

Difficulty: Very hardBuilding and Managing Infrastructure as Code (IaC)

A principal cloud architect is tasked with bringing an unmanaged, production Google Cloud environment containing critical Compute Engine and VPC resources under Terraform management. The solution must enforce remote state locking, prevent resource destruction, ensure zero downtime, and align with Google Cloud security best practices. What is the correct sequence of operational steps to safely import the infrastructure and establish managed IaC execution?

  1. 1Configure a Terraform backend block specifying a Cloud Storage bucket with Object Versioning enabled and execute `terraform init` to establish remote state storage and state locking.
  2. 2Write minimal resource HCL configuration definitions corresponding to the existing GCP infrastructure components without running apply.
  3. 3Execute `terraform import` commands linking each specific GCP resource ID to its matching declared configuration address.
  4. 4Run `terraform plan` and iteratively align the configuration resource attributes with the imported state until zero diff is reported.
  5. 5Commit the reconciled configuration to version control and execute `terraform apply` via a CI/CD pipeline using a service account limited by least privilege IAM roles.

Answer

The correct sequence for adopting existing GCP resources into Terraform management is to first initialize a Cloud Storage remote backend with state locking, declare matching resource configurations, execute terraform import for existing resource IDs, run terraform plan to eliminate attribute drift, and finally commit the code to trigger a least-privilege CI/CD deployment pipeline.
Safely bringing existing live infrastructure under IaC management requires establishing a secure central backend first to maintain state integrity. Once initialized, target resource structures must be declared in code so `terraform import` can map live GCP resource IDs into state without destroying or replacing resources. A subsequent planning step is essential to reconcile discrepancies between code declarations and actual infrastructure attributes before handing off execution to an automated CI/CD pipeline configured with granular IAM permissions.

Step-by-Step Solution

1
Initialize remote Cloud Storage backend with state locking enabled using `terraform init`.
Establishes a centralized, lock-protected state environment.
Prevents state file loss and race conditions during initial resource onboarding.
2
Draft matching resource HCL blocks in configuration files.
Creates valid resource targets for the state import engine.
Terraform import requires a declared resource address to map imported attributes.
3
Run `terraform import <resource_address> <gcp_resource_id>` for each target component.
Metadata and current state of live cloud resources are written into the remote state file.
Connects live GCP resource IDs to Terraform state without modifying running infrastructure.
4
Run `terraform plan` and update local code attributes until no infrastructure changes are indicated.
Achieves parity between code configuration, state file, and live infrastructure.
Prevents unintended replacement or modification of critical production resources.
5
Commit configurations to Git and enforce pipeline execution with least-privilege service accounts.
Establishes secure, automated IaC lifecycle governance.
Eliminates manual console/CLI execution and enforces strict auditing and IAM control.

Key Concept

Brownfield IaC Adoption and State Import Workflow
Rate this question