I Started Learning Terraform the Hard Way. Now I’m Teaching It to Others.

01The problem Terraform is trying to solve

Belinda begins with a scenario rather than a definition. Imagine you are an engineer who has to provision a system on a cloud platform: ten EC2 instances, three buckets, two databases, networking, access permissions. Then imagine doing it again for development, again for testing, again for production.

Done through the console it becomes tedious and fragile, because you are depending largely on your own memory of what you configured last time. Her summary of the manual approach: you click, you configure, you repeat, and hope nothing was missed.

Infrastructure as Code is introduced as the alternative: a tool that lets you define and manage infrastructure through configuration files. You define the resources once in a module, and inherit that module for every environment instead of recreating it.

02Why Infrastructure as Code matters

Belinda works through the reasons one at a time.

• Repeatability: build the same environment consistently, without relying on memory
• Version control: track and review infrastructure changes, and roll back to a commit you understand
• Automation: define a module once and reuse it across every environment
• Collaboration: give teams a shared definition of the infrastructure, instead of asking a teammate what the state file says
• Safer changes: preview what will change before applying it

03Repeatability, automation, and the difference between them

Tarak stops the slide to ask what actually separates repeatability from automation, since both appear on the same list. Belinda answers through the workflow: you run init, plan and apply, and everything is provisioned together rather than one resource at a time.

Tarak offers his own framing, that you automate something you have already done manually many times, and connects it to not repeating yourself. The exchange settles on a conclusion they both accept: automation is a consequence of repeatability.

The same instinct produces a second clarification a few minutes later. When Belinda says apply, Tarak asks what that means for someone less technical. It means provisioning the declared resources in the targeted cloud provider.

04The house analogy

To give the group a mental model, Belinda asks them to imagine being an architect with one blueprint and many clients. The base house is a three bedroom house with white walls. One client wants five bedrooms; another wants blue paint. You do not design a new house. You change the variables.

Tarak reads it back as roughly 90 percent reusable and 10 percent specific to the use case, and that stays the working model for the rest of the session.

From the same analogy she derives the four concepts the session is built on. Variables: what can change. Resources: what am I building, the walls, the door, the windows. Outputs: what information do I need back afterwards, the address, the meter number. State: what does Terraform remember about what it manages.

Variables: what can change → Resources: what am I building → Outputs: what do I need back → State: what does Terraform remember

05Best practice before the demo: shared state

Tarak asks whether there are best practices she would share, particularly around state files and modules, because he has seen teams at both small and enterprise companies struggle with them.

Belinda's answer is to store state remotely, in an S3 bucket when working on AWS, so the whole team can reach it. Remote state also brings state locking: while one engineer is applying changes, everyone else is locked out, and when the run finishes the others can see what was changed. It prevents two people deploying similar changes at the same time.

She notes that the DynamoDB table previously used for locking is deprecated in current Terraform, and that S3 with locking enabled is now enough on its own.

06From slides to a real Terraform workflow

Belinda deliberately uses the local provider for the demonstration, so nobody in the room needs an AWS, Azure or GCP account to follow along. The point is to understand Terraform itself before attaching it to a particular cloud.

She writes the configuration live: a terraform block covering Terraform's own configuration and the dependencies it needs, a provider block for the local provider, and a single resource. The resource type is local_file, the name is welcome, and it declares a filename, welcome.txt, and the content that file should contain.

Tarak asks whether a cloud provider session could follow. Belinda agrees to look at doing Terraform with AWS specifically in a future session.

07The error

The first terraform init fails. Tarak's reaction is instant: “Oh, this is interesting. I love errors.” His reasoning is that you learn considerably more from troubleshooting than from watching something work perfectly the first time.

Rather than fixing it silently, he asks Belinda why she thinks the error appeared. She traces it back herself: the source value was written without quotation marks. She adds the quotes, runs the command again, and Terraform reports that it has been successfully initialised.

It is a two minute detour, and it is one of the most instructive parts of the hour.

08The Terraform workflow, command by command

With initialisation working, Belinda walks through the rest of the workflow, explaining each command before running it.

• terraform init — initialises the working directory and installs the provider the configuration requires
• terraform fmt — formats the configuration using Terraform's standard conventions, without creating anything
• terraform validate — checks whether the configuration is syntactically valid and internally consistent
• terraform plan — “a teaser” of what is about to happen; here it reports 1 to add, 0 to change, 0 to destroy
• terraform apply — moves from proposed changes to actually making them

init → fmt → validate → plan → apply

09What the workflow was actually for

Before apply runs, Tarak presses a question Belinda finds harder than the commands: what is the objective of building this workflow? What is the end result meant to be? She says at the time that she is not sure how to define it, and they agree to discover the answer by finishing the run.

The answer arrives with apply. Terraform asks for confirmation, she approves, and it reports one added, zero changed, zero destroyed. On disk there is now a file, welcome.txt, containing the words “Welcome to Terraform”.

That was the goal of the workflow: to provision the declared resource. Tarak notes that the example is small, but the mechanism is the point, and once the commands are understood the same mechanism scales to far more complex infrastructure.

10Terraform does not recreate what already exists

Belinda runs terraform plan a second time without touching the configuration. Terraform answers: “No changes. Your infrastructure matches the configuration.”

This is where state becomes concrete. Terraform is not rebuilding the file simply because the command was run again; it compares the configuration against what it already knows exists.

Tarak takes the opportunity to ask for a definition of drift. Belinda describes it as the situation where the real resources no longer match what is recorded in state, and clarifies that deliberately editing your own configuration is not drift, it is simply a change Terraform will show you in the plan.

11Variables make the configuration reusable

So far everything has been hardcoded in a single main.tf. Belinda names the problem herself: what if the message should include someone's name, or the same configuration should serve several environments? Instead of editing the infrastructure every time a value changes, turn the value into an input.

She creates variables.tf with a single variable called name, typed as a string, with a default, and references it from the resource using interpolation. No init is needed, because the providers have not changed, so she goes straight to fmt, validate and plan.

The plan reports one to add and one to destroy, because the file's contents changed. After apply, welcome.txt reads “Welcome Belinda”. She changes the default to another name, plans, applies, and the file follows. The structure stayed; only the input moved. It is the house analogy, executed.

12Separating variable definitions from their values

The next problem is immediate: should you really edit variables.tf every time the value changes? Belinda introduces terraform.tfvars, which Terraform loads automatically, so the definition of a variable lives in one file and the supplied value lives in another.

She gives two reasons. The first is convenience across environments. The second is that values you supply can be sensitive, such as secrets or API keys, and keeping them in terraform.tfvars means the file can be added to .gitignore rather than pushed to GitHub.

Tarak suggests integrations, including GitHub, as material for a future session, since today's work is deliberately local.

13Outputs

Outputs are introduced through their absence: run terraform output now and there is nothing to see, because nothing has been declared.

Belinda creates outputs.tf and declares an output for the created resource, pointing at local_file.welcome and the file name attribute. The value is the important part, she explains, because it tells Terraform exactly which value to expose.

Outputs appear automatically at the end of an apply, and can be retrieved at any time with terraform output. Her practical point is that you cannot look up an output you never defined, so declare the values you will want later.

14State as Terraform's memory

The last concept is the one that has been quietly running underneath everything. “State is like Terraform's memory.” It is what allows Terraform to determine what already exists, what needs to change, what needs to be created and what needs to be removed.

The state file is created by Terraform when you apply. Rather than opening it and reading it line by line, Belinda runs terraform state list, which returns the single resource under management: local_file.welcome.

She closes the technical section where she opened the best practice discussion: state here is stored locally, and remote state becomes particularly important once a team is collaborating on the same infrastructure.

15What comes next

The session generates its own follow-ups. Both speakers name what a next conversation could cover.

• Terraform with AWS
• Terraform with Azure or GCP
• Remote state and team collaboration
• GitHub integration
• More advanced Terraform workflows
• How AI can reduce the repetitive parts of Infrastructure as Code work

16Teaching while still learning

The most important moment of the hour arrives after the demo is finished. Belinda explains that she also started working with Terraform this year, and only because a friend challenged her: instead of logging into the console and clicking everything together, use Terraform. “I started through the hard way,” she says.

Earlier, mid-demo, she had said something that sits alongside it: “sometimes it is even more challenging to explain simple things than to do them by yourself.” She was explaining something she had recently learned, live, to people who had not, and she names how hard that is.

Her argument for doing it anyway is that an introduction is enough: when someone gets one, they know how to move on from there. The evidence arrives on the recording. A participant who had never joined a session before asks how she should start learning these technologies.

Belinda was still learning. She taught what she knew. She hit an error. She fixed it. She explained the concepts. And someone else left knowing where to begin.