Lesson 2: Advantages of IaC Patterns

Why teams bother with IaC

In level 1 you saw what infrastructure as code is: you describe infrastructure in files and a tool makes reality match. Objective 1b asks the next question: why is that better than clicking through a console or running ad-hoc scripts?

You have probably lived the problems already. Someone resized a server at 2 a.m. and nobody knows who. Staging "should be the same as production" but isn't. A new environment takes a week because the steps live in one person's head. Each IaC advantage is the fix for one of these.

Five advantages, five problems

HashiCorp's own summary is that you can version, reuse and share configuration files, then use one consistent workflow across the whole lifecycle. On the exam, the skill is matching the benefit to the pain.

Walkthrough: see the benefits at the terminal

Here is a deliberately tiny configuration. Don't worry about the block syntax yet; it just says "a file with this content should exist".

# main.tf: the desired end state, written as text
resource "local_file" "motd" {
  filename = "motd.txt"
  content  = "Managed by Terraform\n"
}

Version control. Because it is a file, the normal software workflow applies:

git add main.tf
git commit -m "Add message-of-the-day file"   # who, when, why, recorded for good

A teammate can now review the change in a pull request, exactly as they would application code.

Review before change. Ask Terraform what it would do:

$ terraform plan

Terraform will perform the following actions:

  # local_file.motd will be created
  + resource "local_file" "motd" {
      + content  = "Managed by Terraform\n"
      + filename = "motd.txt"
      ...                                  # output trimmed
    }

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

Nothing has changed yet. + means create, ~ means update in place, - means destroy. The summary line is the one to read every time: an unexpected "1 to destroy" is your cue to stop.

Automation. terraform apply shows the same plan, waits for you to type yes, then does the work:

$ terraform apply
...
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Idempotence: run it again, nothing happens

Now run the exact same command a second time without touching anything:

$ terraform apply
local_file.motd: Refreshing state...

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.

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

That is idempotence: applying the same configuration once or ten times leaves you with the same result. Terraform's language is declarative, so it describes the end state rather than the steps. When the end state already exists, there is nothing to do.

Compare a naive script containing create_server web-1. Run it twice and you get either a second server or an error. With Terraform, a re-run is safe, which is exactly what makes it sensible to put in a pipeline.

Gotcha: "No changes" is only guaranteed when neither the configuration nor the real infrastructure has changed. If someone edits a resource by hand, the next plan will propose putting it back. That is a feature, and a later level covers it properly.

Reuse and repeatability together

Once the configuration works, the same files can build dev, staging and production. Later you will package common pieces as modules so that ten teams use one reviewed network definition rather than ten home-made ones. The benefit is consistency, and less code to write is a bonus on top.

Honest trade-offs

• IaC does not prevent mistakes; it makes them visible. A plan nobody reads protects nobody.
• Discipline is required. Manual console changes undermine the "files are the source of truth" promise.
• It is slower for a one-off. Writing code beats clicking only when you need the thing again, need it reviewed, or need a record. In production that is almost always.

What the exam asks about this

Expect short scenario questions: a team has a problem, and you pick the IaC benefit that addresses it. Tips:

• Find the key symptom. "No record of who changed it" points to version control. "Environments differ" points to repeatability. "Surprised by a deletion" points to reviewing the execution plan.
• Distractors are often true statements that answer a different problem. Pick the option that fixes this problem.
• Be suspicious of absolutes. IaC does not "eliminate all errors" or "remove the need for review".
• Know what a second terraform apply reports when nothing changed: no changes, 0 added, 0 changed, 0 destroyed.

Key takeaways

• Configuration is text, so it can be versioned, reviewed, shared and rolled back like any code.
• Terraform shows an execution plan and asks for approval before modifying infrastructure.
• The same configuration gives the same result: repeatable environments, with no forgotten manual steps.
• Idempotence: re-applying an unchanged configuration against unchanged infrastructure reports no changes.
• Modules let you reuse and standardise infrastructure patterns across teams.
• In scenario questions, match the benefit to the specific operational problem described.