Forem: Abraham Naiborhu

Terraform Outputs on GCP: Querying Useful Data from a VPC, Subnet, and VM

Abraham Naiborhu — Tue, 05 May 2026 16:08:17 +0000

Hi, we are back again. Previously, I created a simple Google Cloud VPC and then improved the configuration by introducing variables.

This time, I want to continue with another Terraform concept: outputs. But, we will not be using the previous code, because adding outputs for one vpc is too simple. So, I made the lab slightly more practical.

In this lab, I will create:

a custom VPC network
a subnet with a defined CIDR range
a small Compute Engine VM
Terraform outputs to query useful information after provisioning

The goal is to understand how Terraform outputs can expose important infrastructure data after resources are created.

Reference: Hasicorp website about gcp tutorial

Why Outputs Matter

When Terraform creates infrastructure, it stores a lot of resource data in the state file. However, as users, we usually do not need to read everything.

Most of the time, we only care about specific values, such as:

the VM internal IP address
the VPC name
the subnet CIDR range
the VM self-link
a structured summary of the created resources

This is where outputs are useful.

Outputs allow us to expose selected resource information after terraform apply.

They can also be queried later using:

terraform output

What This Lab Builds

This lab creates three Google Cloud resources:

Resource	Purpose
`google_compute_network.vpc_network`	Custom VPC network
`google_compute_subnetwork.subnet`	Regional subnet inside the VPC
`google_compute_instance.vm_instance`	Small Compute Engine VM inside the subnet

The VM will be created without an external public IP address.

This happens because the network_interface block does not include an access_config block.

For this lab, that is fine because the goal is not to SSH into the VM or expose an application. The goal is to learn how Terraform outputs work.

Create a new lab folder

Because this is a new lab, I created a new folder.

mkdir learn-terraform-gcp-lab-output
cd learn-terraform-gcp-lab-output

Then create three files:

touch main.tf variables.tf outputs.tf

The folder should look like this:

learn-terraform-gcp-lab-output/
├── main.tf
├── variables.tf
└── outputs.tf

Create `variables.tf`

First, open variables.tf.

nano variables.tf

Then add the following variable declarations:

variable "project" {
  description = "The Google Cloud project ID where resources will be created."
  type        = string
}

variable "region" {
  description = "The Google Cloud region where regional resources will be created."
  type        = string
  default     = "us-central1"
}

variable "zone" {
  description = "The Google Cloud zone where the VM instance will be created."
  type        = string
  default     = "us-central1-c"
}

variable "network_name" {
  description = "The name of the VPC network."
  type        = string
  default     = "terraform-output-network"
}

variable "subnet_name" {
  description = "The name of the subnet."
  type        = string
  default     = "terraform-output-subnet"
}

variable "subnet_cidr_range" {
  description = "The CIDR range for the subnet."
  type        = string
  default     = "10.10.0.0/24"
}

variable "instance_name" {
  description = "The name of the Compute Engine VM instance."
  type        = string
  default     = "terraform-output-vm"
}

variable "machine_type" {
  description = "The machine type for the Compute Engine VM instance."
  type        = string
  default     = "e2-micro"
}

This file only declares the input variables Terraform can accept.

The important distinction is:

variables.tf declares input variables.
main.tf uses those variables.
outputs.tf exposes selected resource data after apply.

Create `main.tf`

Next, open main.tf.

nano main.tf

Then add the following Terraform configuration:

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "6.8.0"
    }
  }
}

provider "google" {
  project = var.project
  region  = var.region
  zone    = var.zone
}

resource "google_compute_network" "vpc_network" {
  name                    = var.network_name
  auto_create_subnetworks = false
}

resource "google_compute_subnetwork" "subnet" {
  name          = var.subnet_name
  region        = var.region
  network       = google_compute_network.vpc_network.id
  ip_cidr_range = var.subnet_cidr_range
}

resource "google_compute_instance" "vm_instance" {
  name         = var.instance_name
  machine_type = var.machine_type
  zone         = var.zone

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-12"
    }
  }

  network_interface {
    subnetwork = google_compute_subnetwork.subnet.id
  }
}

Understanding `main.tf`

Google Provider

The provider block tells Terraform which Google Cloud project, region, and zone to use.

provider "google" {
  project = var.project
  region  = var.region
  zone    = var.zone
}

The values come from the variables declared in variables.tf.

Custom VPC Network

resource "google_compute_network" "vpc_network" {
  name                    = var.network_name
  auto_create_subnetworks = false
}

This creates a custom VPC network.

The important part is:

auto_create_subnetworks = false

This means Google Cloud will not automatically create subnets for us.

Instead, we will define our own subnet manually.

Subnet

resource "google_compute_subnetwork" "subnet" {
  name          = var.subnet_name
  region        = var.region
  network       = google_compute_network.vpc_network.id
  ip_cidr_range = var.subnet_cidr_range
}

This creates a subnet inside the VPC.

The subnet uses this CIDR range:

10.10.0.0/24

This value comes from:

var.subnet_cidr_range

Compute Engine VM

resource "google_compute_instance" "vm_instance" {
  name         = var.instance_name
  machine_type = var.machine_type
  zone         = var.zone

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-12"
    }
  }

  network_interface {
    subnetwork = google_compute_subnetwork.subnet.id
  }
}

This creates a small Compute Engine VM using:

e2-micro

The VM is attached to the subnet using:

subnetwork = google_compute_subnetwork.subnet.id

Because there is no access_config block, this VM does not get an external public IP address.

It only receives an internal IP address from the subnet.

Create `outputs.tf`

Now we create the output definitions.

Open outputs.tf.

nano outputs.tf

Then add:

output "vpc_network_name" {
  description = "The name of the VPC network created by Terraform."
  value       = google_compute_network.vpc_network.name
}

output "vpc_network_id" {
  description = "The ID of the VPC network created by Terraform."
  value       = google_compute_network.vpc_network.id
}

output "subnet_name" {
  description = "The name of the subnet created by Terraform."
  value       = google_compute_subnetwork.subnet.name
}

output "subnet_cidr_range" {
  description = "The CIDR range of the subnet created by Terraform."
  value       = google_compute_subnetwork.subnet.ip_cidr_range
}

output "vm_instance_name" {
  description = "The name of the VM instance created by Terraform."
  value       = google_compute_instance.vm_instance.name
}

output "vm_instance_zone" {
  description = "The zone where the VM instance was created."
  value       = google_compute_instance.vm_instance.zone
}

output "vm_internal_ip" {
  description = "The internal IP address of the VM instance."
  value       = google_compute_instance.vm_instance.network_interface[0].network_ip
}

output "vm_self_link" {
  description = "The self-link of the VM instance."
  value       = google_compute_instance.vm_instance.self_link
}

output "lab_summary" {
  description = "A structured summary of the resources created in this lab."

  value = {
    project        = var.project
    region         = var.region
    zone           = var.zone
    vpc_name       = google_compute_network.vpc_network.name
    subnet_name    = google_compute_subnetwork.subnet.name
    subnet_cidr    = google_compute_subnetwork.subnet.ip_cidr_range
    vm_name        = google_compute_instance.vm_instance.name
    vm_internal_ip = google_compute_instance.vm_instance.network_interface[0].network_ip
  }
}

This is the main focus of the lab.

Instead of only creating resources, we are selecting which resource attributes should be easy to view after provisioning.

Format the Terraform Files

Run:

terraform fmt

This formats the Terraform configuration files.

Initialize Terraform

Run:

terraform init

This initializes the working directory and downloads the Google provider.

Validate the Configuration

Run:

terraform validate

Expected output:

Success! The configuration is valid.

Apply the Configuration

Run:

terraform apply

Because the project variable does not have a default value, Terraform will ask for it.

var.project
  The Google Cloud project ID where resources will be created.

  Enter a value:

Enter your Google Cloud project ID.

Terraform will show the execution plan.

In my case, Terraform planned to create three resources:

Plan: 3 to add, 0 to change, 0 to destroy.

The resources were:

google_compute_network.vpc_network
google_compute_subnetwork.subnet
google_compute_instance.vm_instance

Terraform also showed that some output values were only known after apply:

vm_internal_ip = (known after apply)
vm_self_link   = (known after apply)

That makes sense because the VM internal IP and self-link do not exist until Google Cloud creates the VM.

After reviewing the plan, type:

yes

Apply Result

After Terraform finished provisioning, my output looked like this:

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

Outputs:

lab_summary = {
  "project" = "terraform-gcp-learning-lab"
  "region" = "us-central1"
  "subnet_cidr" = "10.10.0.0/24"
  "subnet_name" = "terraform-output-subnet"
  "vm_internal_ip" = "10.10.0.2"
  "vm_name" = "terraform-output-vm"
  "vpc_name" = "terraform-output-network"
  "zone" = "us-central1-c"
}
subnet_cidr_range = "10.10.0.0/24"
subnet_name = "terraform-output-subnet"
vm_instance_name = "terraform-output-vm"
vm_instance_zone = "us-central1-c"
vm_internal_ip = "10.10.0.2"
vpc_network_id = "projects/terraform-gcp-learning-lab/global/networks/terraform-output-network"
vpc_network_name = "terraform-output-network"

At this point, Terraform had created:

one VPC network
one subnet
one VM instance

It also exposed selected infrastructure data through outputs.

Query the Outputs

After apply, we can query all outputs using:

terraform output

Example output:

lab_summary = {
  "project" = "terraform-gcp-learning-lab"
  "region" = "us-central1"
  "subnet_cidr" = "10.10.0.0/24"
  "subnet_name" = "terraform-output-subnet"
  "vm_internal_ip" = "10.10.0.2"
  "vm_name" = "terraform-output-vm"
  "vpc_name" = "terraform-output-network"
  "zone" = "us-central1-c"
}
subnet_cidr_range = "10.10.0.0/24"
subnet_name = "terraform-output-subnet"
vm_instance_name = "terraform-output-vm"
vm_instance_zone = "us-central1-c"
vm_internal_ip = "10.10.0.2"
vpc_network_id = "projects/terraform-gcp-learning-lab/global/networks/terraform-output-network"
vpc_network_name = "terraform-output-network"

We can also query one specific output.

For example:

terraform output vm_internal_ip

The result:

"10.10.0.2"

This is useful because I do not need to inspect the full Terraform state just to find the VM internal IP address.

Query a Structured Output

I also created a structured output called lab_summary.

Run:

terraform output lab_summary

Example result:

{
  "project" = "terraform-gcp-learning-lab"
  "region" = "us-central1"
  "subnet_cidr" = "10.10.0.0/24"
  "subnet_name" = "terraform-output-subnet"
  "vm_internal_ip" = "10.10.0.2"
  "vm_name" = "terraform-output-vm"
  "vpc_name" = "terraform-output-network"
  "zone" = "us-central1-c"
}

This is more readable than scanning the full state file.

Output as JSON

Terraform can also return outputs in JSON format.

Run:

terraform output -json

This returns structured JSON data.

Example:

{
  "vm_internal_ip": {
    "sensitive": false,
    "type": "string",
    "value": "10.10.0.2"
  },
  "vpc_network_name": {
    "sensitive": false,
    "type": "string",
    "value": "terraform-output-network"
  }
}

We can also save the output into a JSON file:

terraform output -json > terraform-outputs.json

This can be useful when another script, pipeline, or tool needs to consume Terraform output data.

Inspect Terraform State

Outputs are useful, but they do not replace state.

Terraform still stores resource information in the state file.

To list resources tracked by Terraform, run:

terraform state list

My result:

google_compute_instance.vm_instance
google_compute_network.vpc_network
google_compute_subnetwork.subnet

Then I tried to inspect the Compute Engine instance with:

terraform state show google_compute_instance

Terraform returned an error:

Error parsing instance address: google_compute_instance

This command requires that the address references one specific instance.
To view the available instances, use "terraform state list". Please modify
the address to reference a specific instance.

This happened because google_compute_instance is only the resource type.

Terraform needs the full resource address.

The correct command is:

terraform state show google_compute_instance.vm_instance

This command showed detailed information about the VM, including:

machine type
zone
internal IP
boot disk
subnet
scheduling configuration
shielded instance configuration

This was a useful mistake because it clarified the difference between:

resource type

and:

resource address

Destroy the Infrastructure

Because this lab creates a VM, I destroyed the resources after testing.

Run:

terraform destroy

Terraform will ask for the project value again if it was not provided through another method.

Then it will show a destroy plan.

In my case, the destroy plan showed:

Plan: 0 to add, 0 to change, 3 to destroy.

It also showed that outputs would be removed:

Changes to Outputs:
  - lab_summary       = {...} -> null
  - vm_internal_ip    = "10.10.0.2" -> null
  - vpc_network_name  = "terraform-output-network" -> null

After reviewing the destroy plan, type:

yes

Important: wait until Terraform shows:

Destroy complete! Resources: 3 destroyed.

After that, you can also verify from the Google Cloud Console that the VM, subnet, and VPC have been removed.

What I Learned

From this lab, I learned that Terraform outputs are not just decoration at the end of terraform apply.

Outputs are a clean way to expose the specific infrastructure values that matter.

Instead of manually searching through the state file or Google Cloud Console, I can query useful values directly:

terraform output
terraform output vm_internal_ip
terraform output lab_summary
terraform output -json

The most important idea for me is:

Terraform creates infrastructure, state tracks infrastructure, and outputs expose selected infrastructure data.

I also learned that outputs can be simple values or structured objects.

For example, vm_internal_ip is a simple string output, while lab_summary is a structured output that groups multiple values together.

This makes outputs useful not only for humans, but also for automation.

Next Step

This lab still asks me to manually enter the project variable during terraform apply and terraform destroy.

In the next lab, I want to improve that by using:

terraform.tfvars
terraform.tfvars.example
safer variable value management
avoiding repeated manual input

That should make the Terraform workflow cleaner and more practical.

Terraform Variables: Cleaning Up My First GCP VPC Configuration

Abraham Naiborhu — Mon, 04 May 2026 10:40:26 +0000

In my previous Terraform article, I created my first Terraform-managed Google Cloud resource: a simple VPC network.

The first version worked, but the configuration was still very basic. As someone who has written a lot of JavaScript code, one thing immediately felt uncomfortable: too many values were hardcoded directly inside main.tf.

That made me wonder:

There should be something similar to variables in Terraform, right?

After checking Terraform’s documentation, the answer is yes.

Terraform supports input variables, which allow configuration values to be reused and changed without directly modifying the main infrastructure logic.

In this article, I will improve the previous Terraform configuration by introducing:

variables.tf
input variables
default values
variable usage inside main.tf

Reference: Terraform GCP variables tutorial

Previous Configuration

To recap, this was the previous main.tf configuration:

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "6.8.0"
    }
  }
}

provider "google" {
  project = "<PROJECT_ID>"
  region  = "us-central1"
  zone    = "us-central1-c"
}

resource "google_compute_network" "vpc_network" {
  name = "terraform-network"
}

This configuration works.

However, several values are hardcoded directly inside the provider block:

project = "<PROJECT_ID>"
region  = "us-central1"
zone    = "us-central1-c"

For a small lab, this is acceptable.

But as the configuration grows, hardcoded values become harder to maintain. If I want to change the project, region, or zone, I need to edit the source configuration directly.

A cleaner approach is to declare these values as variables.

Creating `variables.tf`

First, create a new file called variables.tf.

touch variables.tf

Then add the following variable definitions:

variable "project" {}

variable "region" {
  default = "us-central1"
}

variable "zone" {
  default = "us-central1-c"
}

The file name variables.tf is a common convention.

Technically, Terraform reads all .tf files in the current working directory. However, separating variables into variables.tf makes the configuration easier to understand and maintain.

Understanding the Variables

`project`

variable "project" {}

The project variable does not have a default value.

This means Terraform will ask for the value when we run a command that needs it, such as:

terraform plan

or:

terraform apply

This is useful because the Google Cloud project ID may be different depending on the user or environment.

`region`

variable "region" {
  default = "us-central1"
}

The region variable has a default value.

If I do not provide another value, Terraform will use:

us-central1

`zone`

variable "zone" {
  default = "us-central1-c"
}

The zone variable also has a default value.

For this simple VPC lab, the zone is not very important because a VPC network is a global resource in Google Cloud.

However, keeping the zone in the provider configuration is useful because future resources, such as Compute Engine instances, may need it.

Updating `main.tf` to Use Variables

Now we can update main.tf to use the variables.

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "6.8.0"
    }
  }
}

provider "google" {
  project = var.project
  region  = var.region
  zone    = var.zone
}

resource "google_compute_network" "vpc_network" {
  name = "terraform-network"
}

The important change is inside the provider block:

project = var.project
region  = var.region
zone    = var.zone

Terraform uses the var.<variable_name> syntax to reference input variables.

For example:

var.project

means Terraform will use the value provided for the project variable.

Running Terraform Apply

After updating the configuration, run:

terraform fmt

Then validate the configuration:

terraform validate

If the configuration is valid, the output should look like this:

Success! The configuration is valid.

Next, run:

terraform apply

Because the project variable does not have a default value, Terraform will ask for it:

var.project
  Enter a value:

Enter your Google Cloud project ID.

Terraform will then show the execution plan and ask for confirmation:

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value:

Type:

yes

Example output:

google_compute_network.vpc_network: Creating...
google_compute_network.vpc_network: Still creating... [00m10s elapsed]
google_compute_network.vpc_network: Still creating... [00m20s elapsed]
google_compute_network.vpc_network: Still creating... [00m30s elapsed]
google_compute_network.vpc_network: Still creating... [00m40s elapsed]
google_compute_network.vpc_network: Creation complete after 43s [id=projects/terraform-gcp-learning-lab/global/networks/terraform-network]

At this point, Terraform has created the VPC network using values from the input variables.

Destroying the Infrastructure

Because this is only a learning lab, I destroyed the resource after testing.

Run:

terraform destroy

Terraform will ask for the project variable again if it was not provided through another method.

Then Terraform will show the destroy plan and ask for confirmation.

Type:

yes

This removes the VPC network managed by this Terraform configuration.

What Changed?

Previously, the provider configuration looked like this:

provider "google" {
  project = "<PROJECT_ID>"
  region  = "us-central1"
  zone    = "us-central1-c"
}

Now it looks like this:

provider "google" {
  project = var.project
  region  = var.region
  zone    = var.zone
}

The configuration is still simple, but it is now cleaner.

Instead of hardcoding every value inside main.tf, Terraform can read those values from input variables.

What I Learned

From this lab, I learned that Terraform variables help separate configuration values from infrastructure logic.

The key idea is simple:

main.tf defines what Terraform should create.
variables.tf defines what values Terraform can accept.

This makes the configuration easier to reuse and modify.

The most important distinction for me is that variables.tf declares variables, but it does not always provide the actual values.

If a variable has a default value, Terraform can use it automatically.

If a variable does not have a default value, Terraform will ask for the value during execution.

Next Step

This article only introduced basic input variables.

In the next article, I want to continue improving this configuration by learning:

how to provide variable values using terraform.tfvars
how to avoid typing the project ID repeatedly
how to expose useful resource information using Terraform outputs

That should make the configuration more practical and easier to reuse.

Provisioning My First GCP VPC with Infrastructure as Code

Abraham Naiborhu — Sun, 03 May 2026 10:09:18 +0000

In my previous article, I documented how I installed Terraform on macOS using Homebrew and fixed a Zsh autocomplete issue.

In this article, I am going to be using terraform to provision, update, and destroy a simple set of infrastructure using the sample configuration provided by hashicorp

The goal is to understand the basic Terraform workflow:

Write configuration
Authenticate to Google Cloud
Initialize Terraform
Format and validate the configuration
Review the execution plan
Apply the configuration
Inspect Terraform state
Destroy the infrastructure after the lab

Prerequisites

macOS
Visual Studio Code
Terraform CLI v1.15.1
Google Cloud CLI installed locally
A Google Cloud account
A Google Cloud project with billing enabled
Compute Engine API enabled

Notes about Prerequisites

To install gcloud cli, go to google cloud documentation
To install terraform, go to my previous documentation about installation

Set up GCP

Before Terraform can create infrastructure in Google Cloud, we need to prepare the Google Cloud project.
For this lab, the project needs:

A Google Cloud project
Billing enabled
Compute Engine API enabled

Create or Select a Google Cloud Project

In the Google Cloud Console, open the project selector at the top of the page. From there, either select an existing project or create a new one. For this lab, make sure the selected project has billing enabled because Terraform will create Google Cloud resources inside the project.

Enable the Compute Engine API

You can run the following commands either from your local terminal, if Google Cloud CLI is installed, or from Cloud Shell.

# make sure you are in the right project
gcloud config get-value project

# set the project config
gcloud config set project [YOUR_PROJECT_ID]

# run enablement
gcloud services enable compute.googleapis.com

# Verify enablement
gcloud services list --enabled --filter="name:compute.googleapis.com"

The response should be like this

NAME: compute.googleapis.com
TITLE: Compute Engine API

Write the Terraform Configuration

Next, we will write our first Terraform configuration to create a Google Cloud VPC network.

Each Terraform configuration should be placed in its own working directory.

now, create the directory

mkdir learn-terraform-gcp

Move into the directory:

cd learn-terraform-gcp

Create a file called main.tf.

touch main.tf

The name main.tf is a common convention, but Terraform actually reads all .tf files in the current working directory.

Open the file using Visual Studio Code or your preferred editor, then add the following configuration:

terraform {
  required_providers {
    google = {
      source = "hashicorp/google"
      version = "6.8.0"
    }
  }
}

provider "google" {
  project = "<PROJECT_ID>"
  region  = "us-central1"
  zone    = "us-central1-c"
}

resource "google_compute_network" "vpc_network" {
  name = "terraform-network"
}

Replace <PROJECT_ID> with your actual Google Cloud project ID.

Terraform Configuration Explanation

The terraform {} block contains Terraform-level settings.
In this example, it defines the required provider:

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "6.8.0"
    }
  }
}

The provider source hashicorp/google is shorthand for

registry.terraform.io/hashicorp/google

This tells Terraform to use the official Google provider from the Terraform Registry.

Required Provider

The required_providers block tells Terraform which provider plugin it needs to download.
In this case, Terraform needs the Google provider:

google = {
  source  = "hashicorp/google"
  version = "6.8.0"
}

Provider Configuration

The provider "google" block configures how Terraform connects to Google Cloud.

provider "google" {
  project = "<PROJECT_ID>"
  region  = "us-central1"
  zone    = "us-central1-c"
}

In this lab, the provider is configured with:

Google Cloud project ID
Region
Zone This tells Terraform where the infrastructure should be created.

Resource Block

The resource block defines the infrastructure component that Terraform should manage.

resource "google_compute_network" "vpc_network" {
  name = "terraform-network"
}

In this case:

google_compute_network is the resource type
vpc_network is the local Terraform name for the resource
terraform-network is the actual VPC network name that will be created in Google Cloud

This resource creates a VPC network in the selected Google Cloud project.

Authenticating to Google Cloud

Terraform must authenticate to Google Cloud before it can create infrastructure. In the terminal, run:

gcloud auth application-default login

Your browser will open and prompt you to log in to your Google Cloud account. After successful authentication, your terminal will display the path where the gcloud CLI saved your credentials.

The GCP provider automatically uses these credentials to authenticate against the Google Cloud APIs.

Format the Configuration

Before initializing or applying the configuration, I ran:

terraform fmt

Initialize the Directory

Next, initialize the Terraform working directory:

terraform init

This command prepares the working directory and downloads the provider plugins defined in the configuration.

Example output:

Initializing provider plugins found in the configuration...
- Finding hashicorp/google versions matching "6.8.0"...
- Installing hashicorp/google v6.8.0...
- Installed hashicorp/google v6.8.0 (signed by HashiCorp)

Initializing the backend...


Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Validate the configuration

After initialization, validate the configuration:

terraform validate

If the configuration is valid, the output should look like this:

Success! The configuration is valid.

Terraform returned an error like this:

│ Error: "name" ("terraform_network") doesn't match regexp "^(?:[a-z](?:[-a-z0-9]{0,61}[a-z0-9])?)$"
│ 
│   with google_compute_network.vpc_network,
│   on main.tf line 17, in resource "google_compute_network" "vpc_network":
│   17:   name = "terraform_network"

This happened because Google Cloud network names must follow a specific naming rule.
In this case, using:

terraform-network

is valid, while:

terraform_network

is not valid.

Review the Execution Plan

Before creating the infrastructure, run:

terraform plan

This command shows what Terraform intends to create, update, or destroy.

For this lab, Terraform planned to create one resource:

Plan: 1 to add, 0 to change, 0 to destroy.

This is one of the most important Terraform habits.

The plan phase is the safety checkpoint.

Before applying any change, I should understand whether Terraform is going to:

create a resource
update a resource
replace a resource
destroy a resource

For this first lab, the plan is simple. But in a real environment, reviewing the Terraform plan carefully is critical.

Create the Infrastructure

After reviewing the plan, apply the configuration:

terraform apply

Terraform will show the execution plan again and ask for confirmation.

the output usually like this

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # google_compute_network.vpc_network will be created
  + resource "google_compute_network" "vpc_network" {
      + auto_create_subnetworks                   = true
      + delete_default_routes_on_create           = false
      + gateway_ipv4                              = (known after apply)
      + id                                        = (known after apply)
      + internal_ipv6_range                       = (known after apply)
      + mtu                                       = (known after apply)
      + name                                      = "terraform-network"
      + network_firewall_policy_enforcement_order = "AFTER_CLASSIC_FIREWALL"
      + numeric_id                                = (known after apply)
      + project                                   = "terraform-gcp-learning-lab"
      + routing_mode                              = (known after apply)
      + self_link                                 = (known after apply)
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value:

now you enter value of yes

Enter a value: yes

Inspect Terraform State

Terraform state stores the IDs and properties of the resources that Terraform manages.

This allows Terraform to understand the relationship between the configuration file and the actual infrastructure in Google Cloud.

Inspect the current state:

terraform show

the response should be like this

# google_compute_network.vpc_network:
resource "google_compute_network" "vpc_network" {
    auto_create_subnetworks                   = true
    delete_default_routes_on_create           = false
    description                               = null
    enable_ula_internal_ipv6                  = false
    gateway_ipv4                              = null
    id                                        = "projects/terraform-gcp-learning-lab/global/networks/terraform-network"
    internal_ipv6_range                       = null
    mtu                                       = 0
    name                                      = "terraform-network"
    network_firewall_policy_enforcement_order = "AFTER_CLASSIC_FIREWALL"
    numeric_id                                = "2818444064827549422"
    project                                   = "terraform-gcp-learning-lab"
    routing_mode                              = "REGIONAL"
    self_link                                 = "https://www.googleapis.com/compute/v1/projects/terraform-gcp-learning-lab/global/networks/terraform-network"

This was one of the most important lessons from this lab.

Terraform is not only a tool that creates infrastructure. Terraform also tracks the infrastructure it manages through state.

For this beginner lab, the state is stored locally in:

terraform.tfstate

Check the Resource in Google Cloud Console

After Terraform finishes creating the VPC network, you can verify it in the Google Cloud Console.

Go to:

VPC network > VPC networks

You should see a network named:

terraform-network

At this point, the VPC exists in Google Cloud and is being managed by Terraform.

Destroy everything

Because this is only a learning lab, I do not want to leave unused resources running in my Google Cloud project.

To destroy the infrastructure managed by this Terraform configuration, run:

terraform destroy

Terraform will show a destroy plan and ask for confirmation.

Type:

yes

Important note: terraform destroy only destroys resources managed by the current Terraform state.

In this lab, it will destroy the VPC network created by this configuration.

After the destroy process is complete, you can check the Google Cloud Console again to confirm that the VPC network has been removed.

Installing Terraform on macOS with Homebrew and Fixing Zsh Autocomplete Error

Abraham Naiborhu — Sun, 03 May 2026 03:43:44 +0000

After passing Google Professional Cloud Architect, I started learning Terraform to turn cloud architecture knowledge into reproducible Infrastructure as Code.

This is my first Terraform learning note with a simple goal of

install Terraform on macOS
verify that it works
enable autocomplete
document one error I encountered during setup

Requirements

For this setup, I used Homebrew.
If you do not have Homebrew installed yet, you can install it from:
https://brew.sh/

What is Homebrew?

Small info, Homebrew is a package manager for macOS and Linux. It helps install, update, and manage developer tools directly from the terminal.

Reference: This note is based on HashiCorp’s official Terraform installation guide. I rewrote the steps in my own words as part of my personal Terraform learning documentation.

Install Terraform on macOS

First, add HashiCorp’s official Homebrew tap.

brew tap hashicorp/tap

Verify the Installation

After installation, check whether Terraform is available.

terraform --version

You can also list Terraform’s available commands.

terraform --help

To inspect a specific command, add -help. For example:

terraform plan -help

Enable Terraform Autocomplete

Because I am using Zsh on macOS, I first made sure that the Zsh configuration file exists.

touch ~/.zshrc

Or if you are not too sure, go check it with

ls -la .zshrc

It will output the path to that file.

Then I installed Terraform autocomplete.

terraform -install-autocomplete

After installing autocomplete, restart the shell or reload the Zsh configuration.

source ~/.zshrc

The Error

After running terraform -install-autocomplete, I encountered this error when opening a new terminal window:

complete:13: command not found: compdef

Why This Happened

Terraform autocomplete uses shell completion.

In my case, Zsh’s completion system was not properly initialized before Terraform’s autocomplete command was loaded.

Because of that, the terminal could not recognize compdef.

The Fix

Open the Zsh configuration file.

nano ~/.zshrc

Then make sure the Zsh completion system is initialized before the Terraform autocomplete line.

My configuration looked like this:

# Initialize Zsh completion system
autoload -Uz compinit && compinit

# Initialize Bash completion compatibility
autoload -U +X bashcompinit && bashcompinit

# Terraform CLI autocomplete
complete -o nospace -C /opt/homebrew/bin/terraform terraform

Important note: the Terraform path may be different depending on your Mac.

To check your Terraform path, run:

which terraform

For Apple Silicon Macs, it is commonly:

/opt/homebrew/bin/terraform

Use the path returned by which terraform.

Restart the Shell

After updating .zshrc, reload it:

source ~/.zshrc

Test Autocomplete

Type this without pressing Enter:

terraform provi

Then press tab. The result should usually be

terraform providers

What I Learned

This was a small setup issue, but it reminded me of an important Infrastructure as Code principle:

Tooling setup matters.

This is only the first step. Next, I will start learning Terraform providers, resources, variables, outputs, and how Terraform works with Google Cloud.

Forem: Abraham Naiborhu

Terraform Outputs on GCP: Querying Useful Data from a VPC, Subnet, and VM

Why Outputs Matter

What This Lab Builds

Create a new lab folder

Create variables.tf

Create main.tf

Understanding main.tf

Google Provider

Custom VPC Network

Subnet

Compute Engine VM

Create outputs.tf

Format the Terraform Files

Validate the Configuration

Apply the Configuration

Apply Result

Query the Outputs

Query a Structured Output

Output as JSON

Inspect Terraform State

Destroy the Infrastructure

Next Step

Terraform Variables: Cleaning Up My First GCP VPC Configuration

Previous Configuration

Creating variables.tf

Understanding the Variables

project

region

zone

Updating main.tf to Use Variables

Running Terraform Apply

Destroying the Infrastructure

What Changed?

What I Learned

Next Step

Provisioning My First GCP VPC with Infrastructure as Code

Prerequisites

Notes about Prerequisites

Set up GCP

Create or Select a Google Cloud Project

Enable the Compute Engine API

Write the Terraform Configuration

Terraform Configuration Explanation

Required Provider

Provider Configuration

Resource Block

Authenticating to Google Cloud

Format the Configuration

Initialize the Directory

Validate the configuration

Review the Execution Plan

Create the Infrastructure

Inspect Terraform State

Check the Resource in Google Cloud Console

Destroy everything

Installing Terraform on macOS with Homebrew and Fixing Zsh Autocomplete Error

Requirements

What is Homebrew?

Install Terraform on macOS

Verify the Installation

Enable Terraform Autocomplete

The Error

Why This Happened

The Fix

Restart the Shell

Test Autocomplete

What I Learned

Create `variables.tf`

Create `main.tf`

Understanding `main.tf`

Create `outputs.tf`

Creating `variables.tf`

`project`

`region`

`zone`

Updating `main.tf` to Use Variables