Inspecting resources – Infrastructure as Code (IaC) with Terraform

Let’s use the az command to list the resource groups. As we know, our resource groups have a resource group prefix of terraform-ws. Therefore, use the following command to list all resource groups containing the prefix:
$ az group list | grep name | grep terraform-ws
“name”: “terraform-ws-dev”,
“name”: “terraform-ws-test”,

As we can see, we have two resource groups, terraform-ws-dev and terraform-ws-test.
So, two resource groups have been created successfully.
You can also verify this in the Azure portal, as shown in the following screenshot:

Figure 8.3 – Resource groups

Now, let’s go ahead and inspect the resources on the terraform-ws-dev resource group using the Azure portal by clicking on terraform-ws-dev:

Figure 8.4 – Terraform dev resource group

We have a virtual network, a network interface, an OS disk, and a VM within the resource group. We should expect similar resources with the same names in the terraform-ws-test resource group. Let’s go ahead and have a look:

Figure 8.5 – Terraform test resource group

As we can see, we also have similar resources in the terraform-ws-test resource group.

We did all this using a single configuration, but there should be two state files for each workspace since they are two sets of resources. Let’s have a look.

Inspecting state files

If we had used the local backend for the state files, we would get the following structure:
|– terraform.tfstate.d
|– dev
|     -- terraform.tfstate — test
`– terraform.tfstate

So, Terraform creates a directory called terrafom.tfstate.d; within that, it creates directories for each workspace. Within the directories, it stores the state file for each workspace as terraform. tfstate.

But since we are using a remote backend and using Azure Blob Storage for it, let’s inspect the files within it using the Azure console:

Figure 8.6 – Terraform workspace state

As we see, there are two state files, one for each environment. Therefore, the state files are suffixed with an env:dev or env:test string. That is how workspaces are managed in Azure Blob Storage. The remote backend’s structure for maintaining state files depends on the provider plugins, and therefore, there might be different ways of managing multiple states for various backends. However, the Terraform CLI will interpret workspaces the same way, irrespective of the backends, so nothing changes for the end user from a CLI perspective.