Table of Contents
1. Recap of Week 4
2. What Are Output Values in Terraform ?
3. Why Are They Useful and Where Do I Use Them ?
4. Adding Outputs to Our Configuration
5. Common Output Pitfalls and Tips
6. Deploy to Azure
7. Wrap-Up
1. Recap of Week 4
Last week, we focused on improving the security of our Azure VM by introducing Network Security Groups (NSGs) into our Terraform configuration.
We created inbound security rules to control access to the VM and attached the NSG to the network interface to enforce those rules. We also used dynamic blocks to keep our configuration clean and avoid repeating ourselves when defining multiple security rules.
If you missed Week 4, you can check it out the full post here.
This week, we’ll shift our focus to output values and learn how to expose useful information from our Terraform deployments.
For this week’s .tf files, you can access them here.
2. What Are Output Values in Terraform ?
Output values allow Terraform to display information about your infrastructure after it has been created.
If you have been paying attention to the CLI output of some of our terraform plan and apply commands from previous weeks, we kept seeing some of the fields saying “known after apply”. Here is an example :
If you look at the screenshot, you will see information such as public ip address, dns server, and many more are saying “known after apply”.
And after the apply is complete, Terraform does not necessarily tell you “Here’s the public IP information”.
That’s where output values come in.
3. Why Are They Useful and Where Do I Use Them ?
A few reasons. Imagine you just deployed a web server using Terraform and you want to SSH or RDP into it to configure it. You will need the public IP address to connect. Without outputs, you would have to log into the Azure Portal and search for it manually.
With output values, Terraform prints that information directly in your terminal after the deployment finishes. This means you can connect immediately without leaving your terminal.
Output values also become extremely important once you start working with Terraform modules.
They allow you to pass values from one Terraform module to another ( more on this later when we introduce Terraform Modules in upcoming weeks) such as resource IDs, IP addresses, resource names, or endpoints.
If you have a software engineering background, you can think of Terraform outputs the same way you think about return values from a function or properties exposed by a class object.
Outputs are also useful in automation. A pipeline can deploy infrastructure, read output values, and then use them to configure software or run scripts automatically.
They make your infrastructure usable, not just deployable.
4. Adding Outputs to Our Configuration
Now let’s move into the hands on part and actually add output values to our infrastructure.
Just like we created a dedicated variables.tf file for our variables, we will do the same for outputs for the same reason. Having all outputs in a single place makes things easier to manage and gives you a clear view of what information your infrastructure is exposing.
Go ahead and create a file called outputs.tf in your project:
For our current infrastructure, we will output the following values :
The syntax for an output block looks like this :
The name after the output keyword is important. You want to give each output a name that clearly explains what value is being returned and which resource it belongs to.
The value section is where you reference the attribute you want from a resource or variable. In this example, the output refers to the name of the resource group we created in previous weeks.
For our setup, we will create outputs for the following values:
Private IP address of the virtual machine
Resource group name
Network security group name
The allowed ports defined for the network security group
Once you add all output blocks, your outputs.tf file should look like this:
Notice how the allowed ports output points directly to the list variable we used in our dynamic block. Since that variable already contains the allowed ports, we can simply expose it as an output.
This also shows that you are not limited to outputting resource attributes only. You can output variable values as well, which is useful when you want to verify exactly what Terraform is using during a deployment.
5. Common Output Pitfalls and Tips
While Outputs are useful, if they are not used correctly they can cause security concerns or deployment issues. Here’s a list of common output pitfalls and tips on how to best use Outputs :
Always make sure you reference the correct resource name and attribute. A small typo can result in empty or incorrect output values.
Do not reuse output names. Each output must have a unique name or Terraform will fail validation.
Avoid outputting sensitive information such as passwords or secrets. Outputs are shown in plain text and stored in the state file.
If an output is showing as null, the attribute may not exist or the value is not available at apply time.
Use descriptive names for outputs. The output name should clearly explain what value is being returned.
Only expose outputs that you actually use. If you are not consuming the value, there is no need to output it.
6. Deploy to Azure
As always, we begin by navigating to our Terraform Directory and issuing terraform init command.
Then we issue terraform plan command. Let’s have a look at the relevant parts of the plan output for this week :
As you can see in the picture, now we have an Output section that shows us the name of the output (the name we specified while defining the output block), and the values next to it. You can see all of the variables with the exception of private ip is available and reflects the correct values.
Then we use terraform apply -auto-approve command to deploy our infrastructure:
You can see that the output values are printed following the completion of the apply command, and the private ip information that was not available on the plan output is also printed.
Finally, don’t forget to issue terraform destroy -auto-approve command to avoid infrastructure costs:
7. Wrap-Up
In this week’s post, we focused on output values and how they help you expose useful information from your Terraform deployments.
We looked at how Terraform shows values as “known after apply”, how output blocks work, and how to structure outputs using an outputs.tf file. We also added real outputs to our Azure setup and saw how Terraform prints them after a successful deployment.
At this point, you are no longer just creating infrastructure. You are also making it easier to use, debug, and integrate.
Next week, we will continue building on this by introducing Terraform modules and start organizing our configuration in a more reusable way.
Hope to see you next week!
