We close the chapter with a practical review of the commands you’ll use daily with Terraform. We’ve already seen some separately; here we bring them together in order, add two new ones (fmt and validate), and arrange them as a real workflow. Consider this your command cheat sheet.

This is the typical order of commands in a Terraform project:

Let’s go through them one by one.

What it does: initializes the working directory. Downloads the providers (subchapter 11.1) and configures the state backend (subchapter 11.3).

When to run it:

• The first time you work on a project.
• When you add or change a provider.
• When you change the backend configuration.

It’s the first command you run in any new project. Without it, the other commands won’t work because the providers haven’t been downloaded.

What it does: automatically formats your .tf files to have a consistent style (indentation, alignment, spaces). It doesn’t change the logic, just the appearance.

Why use it: well-formatted code is easier to read and avoids style debates within the team. It’s like an automatic style checker. It’s usually run before saving or pushing changes. In teams, it’s checked automatically in CI (Chapter 22).

Analogy: fmt is like the “tidy/align” button in a document: it makes everything neat and uniform without changing the content.

What it does: checks that your code is valid syntactically and logically, without connecting to AWS or creating anything. It detects errors like misspelled arguments or non-existent references.

Why use it: it warns you of errors before you try to apply anything. It’s a quick and cheap check. If validate fails, there’s no point in continuing.

Difference with plan: validate only checks that the code is well written (doesn’t need credentials). plan goes further: it queries AWS and tells you what changes it would make. First validate (is it well written?), then plan (what will it do?).

What it does: shows what changes it would make without applying them. It compares your code, the state, and reality (subchapters 9.4 and 11.2).

Remember the symbols: + create, ~ modify, - destroy. It’s your safety net: you review before touching anything.

What it does: executes the changes for real, after showing you the plan and asking for confirmation (yes).

After applying, your real infrastructure matches your code, and the state is updated.

Tip: terraform apply already does a plan internally and shows it to you before asking for confirmation, so you can review one last time before typing yes.

What it does: destroys all managed resources, after confirmation. Ideal for cleaning up tests and stopping payments (subchapter 9.4).

⚠️ Irreversible. Great for testing, dangerous in production. Use with care.

Besides the essentials, there are others you’ll use:

This is what your day-to-day would look like creating new infrastructure:

Tip: Get used to always running plan before apply and reading the plan carefully. It’s the habit that will save you from costly mistakes. Many cloud scares are avoided simply by carefully reading what Terraform was about to do.

• The typical flow is init → fmt → validate → plan → apply → destroy.
• init: prepares the project (downloads providers, configures backend). First command, essential.
• fmt: formats the code (clean and uniform style).
• validate: checks that the code is valid, without touching AWS.
• plan: previews the changes (doesn’t apply anything). Your safety net.
• apply: applies the changes (asks for yes). destroy: deletes everything (asks for yes, irreversible).
• Golden habit: always plan before apply, and read the plan carefully.

With this, you finish Chapter 11. You now have all the theoretical pieces of Terraform: language, providers, state, and commands. In Chapter 12 we’ll put it all together by building your first real infrastructure: a VPC with an EC2 server, step by step.