Examkin

Question

Difficulty: HardBuilding and Managing Infrastructure as Code (IaC)

A telecommunications enterprise is onboarding manually provisioned core network billing resources—including custom VPC subnetworks, firewall rules, and Cloud SQL database instances—into a managed Infrastructure as Code (IaC) workflow using Terraform. The cloud architecture team must safely import these brownfield Google Cloud resources into a remote Cloud Storage (GCS) backend while ensuring zero downtime and preventing state corruption. What is the correct chronological sequence of operational steps to safely import and govern these existing resources using Terraform?

  1. 1Write the Terraform HCL resource declarations matching existing GCP resource attributes and configure the GCS remote backend in the root configuration module.
  2. 2Execute `terraform init` to initialize the working directory, download the Google provider plugins, and establish connectivity with the remote GCS backend bucket.
  3. 3Execute `terraform import` commands for each existing infrastructure component, mapping live GCP resource IDs to their corresponding Terraform resource addresses.
  4. 4Execute `terraform plan` to compare the declared HCL code against the newly imported state and verify that zero infrastructure changes or drift are reported.
  5. 5Commit the verified Terraform HCL code, module definitions, and provider dependency lockfile (`.terraform.lock.hcl`) to the Git version control repository.

Answer

The correct sequence begins with writing matching HCL resource blocks and backend configuration, running `terraform init` to configure plugins and backend storage, executing `terraform import` to map live GCP resource IDs to state addresses, running `terraform plan` to confirm zero drift, and finally committing the verified configuration code to version control.
Safely bringing existing brownfield Google Cloud infrastructure into Terraform requires establishing matching HCL definitions and backend configuration first, initializing backend storage and provider plugins (`init`), mapping live GCP resource IDs into state metadata (`import`), verifying configuration alignment to ensure zero unexpected modifications (`plan`), and committing verified configuration files to Git.

Step-by-Step Solution

1
Construct matching HCL resource declarations and define the GCS backend block.
Target resource schemas and remote state storage mechanisms are declared.
Terraform requires existing HCL declarations and backend configurations before state binding can take place.
2
Run `terraform init` in the root module directory.
Provider binaries are retrieved and GCS state locking is established.
Workspace initialization is mandatory for Terraform to load provider schemas and connect to state backends.
3
Execute `terraform import` for each live GCP resource.
Live resource attributes are populated into the state file without disrupting live services.
Import binds physical cloud resource unique identifiers to declared HCL state objects.
4
Run `terraform plan` to evaluate configuration alignment.
Plan output validates zero pending changes or unexpected resource replacements.
Verification ensures the manually written HCL matches all imported live infrastructure properties.
5
Commit code and lockfiles to version control.
Baseline IaC governance and CI/CD versioning are established.
Version controlling validated HCL configurations prevents state divergence across engineering teams.

Key Concept

Brownfield Resource Import and IaC State Governance
Rate this question

Topics

Building and Managing Infrastructure as Code (IaC)

More questions from this topic