Google Cloud services
19 / 24
Google Cloud

Infrastructure as Code — Terraform & Config Connector

Define infrastructure in version control so environments are reproducible and changes are reviewable.

On GCP, Terraform is the mainstream answer rather than a first-party template language.

Architectural drawings rather than a building put up from memory. Changes are marked up and approved, and the same plans raise an identical building elsewhere.

Key Concepts

1
    Terraform          HCL, multi-cloud, the de facto standard here
    Config Connector   manage GCP resources as Kubernetes objects
    Deployment Manager  Google's original, now legacy
2
Terraform is the default because Google's own reference architectures, the Cloud Foundation Toolkit and most published modules are written in it. Deployment Manager is effectively deprecated for new work.
3
The plan is the safety mechanism.
    Plan: 2 to add, 1 to change, 1 to destroy.
4
    + google_monitoring_alert_policy.api_5xx
    ~ google_compute_instance_group_manager.api
        target_size: 2 -> 4                 in place, safe
    - google_sql_database_instance.orders
        forces replacement: database_version   DATA LOSS
5
Reading that fourth line is the skill. Some attribute changes force replacement, and for a database that is an empty database.
6
State must be remote and locked. A GCS backend gives both — object versioning for history and locking so two engineers applying at once cannot corrupt it. State also contains secrets in plain text, so the bucket needs tight IAM.
7
Drift happens the moment someone edits in the console. The next apply either reverts the fix or fails; terraform plan reports it, and discipline prevents it.
terraform plan
8
Config Connector is the Kubernetes-native option. GCP resources become custom resources in a cluster, reconciled continuously — so a manual change is actively corrected rather than merely detected. It suits teams already running everything through GitOps.
9
Keep configurations layered. Network, data and application in separate states, with remote state or data sources between them. One enormous state makes every change risky and slow.
10
Projects are the natural boundary. Because a GCP project is a cheap, hard container with its own IAM and quota, "one project per environment per service" is a common and clean Terraform layout.
11
What the interviewer is probing.1. "Why is Terraform the default on GCP?" Probing: the ecosystem. Stalls: "It is multi-cloud." Moves up: Google's own reference architectures and the Cloud Foundation Toolkit are written in it, and Deployment Manager is legacy.
12
2. "What do you look for in a plan?" Probing: the dangerous line. Stalls: "That it applies." Moves up: forces replacement — some attribute changes destroy and recreate, and for a database that is an empty database.
13
3. "Where does state belong and why?" Probing: locking and secrets. Stalls: "In version control." Moves up: a GCS backend with locking and versioning; it must never be in git, because it contains secrets in plain text.
14
4. "What does Config Connector add?" Probing: the GitOps option. Stalls: "Nothing new." Moves up: GCP resources become Kubernetes custom resources reconciled continuously, so a manual change is actively corrected rather than merely detected.
Use cases:terraformconfig-connectorstatedriftplan