Ship and run cloud software safely: containers, CI/CD pipelines, Terraform with cost guardrails, SLOs, alerting and incident response.

DevOps & Cloud Delivery

Install Terraform from developer.hashicorp.com (or OpenTofu from opentofu.org) and run `terraform version`.

Create a folder `tf-local`, run `git init`, and add a `.gitignore` with `.terraform/`, `*.tfstate`, `*.tfstate.*` and `*.tfvars`.

Create `main.tf` from the Read tab. On Windows, add `host = "npipe:////.//pipe//docker_engine"` inside the `provider "docker"` block.

Run `terraform init`, `terraform fmt` and `terraform validate`, and confirm a `.terraform.lock.hcl` file appeared.

Run `terraform plan` and find the line `Plan: 2 to add, 0 to change, 0 to destroy`. Then run `terraform apply`, type `yes`, and open the `url` output in your browser.

Run `terraform plan -var="external_port=8081"` and find the `-/+` (replace) marker on `docker_container.web`. Write down in one sentence why Terraform must replace it.

Run `docker ps` and confirm the `tf-web` container exists. Run `terraform state list` to see the two resource addresses Terraform tracks.

Run `terraform destroy`, type `yes`, confirm `docker ps` no longer shows `tf-web`, then commit `main.tf`, `.gitignore` and `.terraform.lock.hcl` (and check `git status` shows no state file).

## Why it matters

Clicking through a cloud console works once. It does not work when you need the same network, database and load balancer in staging and production, when a colleague asks "who changed this firewall rule?", or when a region fails and you must rebuild everything. **Infrastructure as code (IaC)** describes infrastructure in text files that live in Git, get reviewed in pull requests and are applied by a tool. Your infrastructure gains the same history, review and repeatability as your application code.

**Terraform** is the most widely used IaC tool for cloud engineers, with providers for AWS, Azure, Google Cloud, Kubernetes, GitHub, DNS services and hundreds more. Since 2023 Terraform has been released under the Business Source License; **OpenTofu** is a community fork under an open-source license that uses the same language and commands (`tofu` instead of `terraform`). Everything in this module works with either.

## The core idea: declare, plan, apply

Like Kubernetes, Terraform is declarative. You write what should exist; Terraform works out how to get there:

1. `terraform init` downloads the **providers** (plugins that talk to an API) your code needs.
2. `terraform plan` compares your code with what exists and prints the changes it would make: `+` create, `~` update in place, `-/+` replace, `-` destroy. Nothing changes yet.
3. `terraform apply` shows the plan again and makes the changes after you type `yes`.
4. `terraform destroy` removes everything the configuration manages.

Reading the plan carefully is the most important habit in IaC. A plan that says "1 to destroy" on a production database deserves a second look before anyone types `yes`.

## A first configuration with no cloud bill

To learn safely, this lesson uses the community **Docker provider**, which manages containers on your own machine. The workflow is identical to managing cloud resources, but it costs nothing and cannot leave a forgotten server running.

```hcl
# main.tf
terraform {
  required_version = ">= 1.6"
  required_providers {
    docker = {
      source  = "kreuzwerker/docker"
      version = "~> 3.0"
    }
  }
}

provider "docker" {}

variable "external_port" {
  type        = number
  default     = 8080
  description = "Port on your machine that forwards to the web server."
}

resource "docker_image" "nginx" {
  name         = "nginx:1.27-alpine"
  keep_locally = false
}

resource "docker_container" "web" {
  name  = "tf-web"
  image = docker_image.nginx.image_id

  ports {
    internal = 80
    external = var.external_port
  }
}

output "url" {
  value = "http://localhost:${var.external_port}"
}
```

The language is **HCL**. The pieces:

| Block | Purpose |
|---|---|
| `terraform` | Settings: required Terraform version and providers, pinned with `~> 3.0` (any 3.x) |
| `provider` | Configures a provider. Docker needs no settings on macOS or Linux; on Windows set `host = "npipe:////.//pipe//docker_engine"` |
| `variable` | An input, with a type, default and description |
| `resource` | Something Terraform creates and manages. Its address is `type.name`, for example `docker_container.web` |
| `output` | A value printed after apply and readable by other tools |

`image = docker_image.nginx.image_id` is a **reference**. It tells Terraform the container depends on the image, so the image is created first. Terraform builds a dependency graph from references and creates independent resources in parallel.

## Running it

```bash
terraform init
terraform fmt        # format the files consistently
terraform validate   # check syntax and references
terraform plan       # Plan: 2 to add, 0 to change, 0 to destroy.
terraform apply
curl http://localhost:8080    # nginx welcome page
terraform destroy
```

Change `default = 8080` to `8081` and run `terraform plan` again. The plan shows `-/+` for the container: a port mapping cannot be changed on a running container, so Terraform must replace it. The plan tells you this before anything happens, which is exactly why you read it.

You can also override variables without editing files: `terraform plan -var="external_port=9090"`, or a `terraform.tfvars` file.

## What goes in Git

Commit `*.tf` files and `.terraform.lock.hcl` (it records exact provider versions so everyone gets the same ones). Do **not** commit:

```gitignore
.terraform/
*.tfstate
*.tfstate.*
*.tfvars      # if they contain secrets; commit an example file instead
crash.log
```

The `terraform.tfstate` file records what Terraform manages and can contain secrets in plain text. The next lesson covers where state should live instead.

## Common mistakes

- **Applying without reading the plan.** Make "read the plan" part of every review; in CI, post the plan on the pull request.
- **Editing resources by hand in the console.** Terraform's view and reality drift apart, and the next apply may undo the manual change. Change the code instead.
- **Unpinned providers.** A new major version can change behaviour. Pin with `~>` and update on purpose.
- **Hard-coding credentials in `provider` blocks.** Cloud providers read credentials from the environment or your CLI login; never put keys in `.tf` files.
- **Forgetting `destroy` on practice resources.** On a real cloud, that is how free tiers turn into bills.

## Quick recap

- IaC puts infrastructure in Git, with review and history.
- `init`, `plan`, `apply`, `destroy`; always read the plan.
- Resources, variables, outputs and references form a dependency graph.
- Commit `.tf` and the lock file; never commit state or secrets.

## Try it

The Do tab has you run this configuration end to end with Docker on your own machine.

Write a small Terraform configuration, read its plan, apply it and destroy it, using the local Docker provider so nothing costs money.

Terraform basics

Terraform in 100 Seconds

Terraform explained in 15 mins | Terraform Tutorial for Beginners

## Why it matters

Terraform felt simple in the previous lesson because one person ran it on one laptop. On a team, two questions appear quickly. Where does Terraform's record of what it manages live, so that everyone sees the same thing? And how do you avoid copying the same 200 lines of network code into every environment? The answers are **remote state** and **modules**. Both come up in nearly every cloud engineering interview and in the Terraform Associate exam.

## What state is

Terraform keeps a **state** file that maps each resource address in your code (`docker_container.web`) to a real object (a container ID, an AWS instance ID) together with its last known attributes. Terraform uses state to:

- know which real objects it owns, so it updates them instead of creating duplicates;
- work out the plan quickly without asking the API about every attribute;
- track dependencies, so it destroys things in the right order.

By default state is a local file, `terraform.tfstate`. That is fine for practice and wrong for a team:

- If two people have different copies, they will make conflicting changes.
- If the laptop dies, Terraform forgets what it created, and the resources keep running (and billing) with nothing tracking them.
- State often contains **secrets in plain text**: database passwords, private keys, connection strings. It must not live in Git or on shared drives.

## Remote backends and locking

A **backend** tells Terraform where to store state. Teams use a remote backend:

```hcl
terraform {
  backend "s3" {
    bucket       = "acme-terraform-state"
    key          = "networking/prod.tfstate"
    region       = "us-east-1"
    encrypt      = true
    use_lockfile = true
  }
}
```

Common choices are an S3 bucket (AWS), an Azure Storage container (`azurerm`), a Google Cloud Storage bucket (`gcs`), or HCP Terraform. A good backend gives you:

- **One shared copy** that everyone and every CI job reads.
- **Locking**, so two `apply` runs cannot write at the same time and corrupt state. (The S3 backend supports a lock file in the bucket in recent Terraform versions; older setups used a DynamoDB table.)
- **Encryption and access control**, because of the secrets inside.
- **Versioning**, so a damaged state can be restored.

Split state by environment and by area (for example `networking/prod`, `app/staging`). One giant state file makes every plan slow and every mistake large; this split is often called limiting the **blast radius**.

## Working with state safely

Never edit the state file by hand. Use commands:

| Command | Use |
|---|---|
| `terraform state list` | List resource addresses in state |
| `terraform state show <addr>` | Show the recorded attributes of one resource |
| `moved { from = ... to = ... }` block | Rename or move a resource in code without destroying it |
| `import { to = ... id = ... }` block or `terraform import` | Bring an existing, hand-made resource under Terraform |
| `terraform plan -refresh-only` | See drift: differences between state and reality |

The `moved` block is worth remembering. If you rename `aws_instance.web` to `aws_instance.app` without it, Terraform plans to destroy the old one and create a new one.

## Modules

A **module** is a folder of `.tf` files. The folder you run Terraform in is the **root module**; folders it calls are **child modules**. A module is used like a function: it takes **variables** as inputs and returns **outputs**.

```hcl
# modules/web/variables.tf
variable "name"          { type = string }
variable "external_port" { type = number }

# modules/web/main.tf
resource "docker_container" "this" {
  name  = var.name
  image = "nginx:1.27-alpine"
  ports {
    internal = 80
    external = var.external_port
  }
}

# modules/web/outputs.tf
output "url" { value = "http://localhost:${var.external_port}" }
```

```hcl
# main.tf (root module)
module "web_staging" {
  source        = "./modules/web"
  name          = "web-staging"
  external_port = 8081
}

module "web_prod" {
  source        = "./modules/web"
  name          = "web-prod"
  external_port = 8082
}

output "staging_url" { value = module.web_staging.url }
```

The two environments now share one tested definition and differ only in their inputs. Resource addresses inside a module are prefixed, for example `module.web_prod.docker_container.this`.

Modules can come from a local path, a Git URL with a tag, or a registry such as the public Terraform Registry (`terraform-aws-modules/vpc/aws`). Pin a `version` (or a Git tag) for anything not local, and run `terraform init` again after adding or changing a module source.

Good modules are small and focused (a network, a service, a database), expose only the inputs callers need, and document their outputs. A module that wraps a single resource with no added value is usually not worth it.

## Common mistakes

- Keeping team state on a laptop or in Git.
- No locking, so two pipelines run `apply` at once.
- One state file for every environment.
- Renaming resources without `moved` blocks and accidentally destroying them.
- Pulling registry modules without pinning a version.

## Quick recap

- State maps code to real objects; it can hold secrets.
- Teams use an encrypted, versioned, locked remote backend, split by environment.
- Change state with commands and `moved`/`import` blocks, never by hand.
- Modules take variables, return outputs, and let environments share one definition.

## Try it

This lesson has no hands-on activity. Take the quiz in the Do tab.

Explain what Terraform state is, why teams keep it in a locked remote backend, and how modules package reusable infrastructure.

State and modules

Managing Terraform State Files

Terraform Basics: Modules

In `tf-local`, add the `env` and `tags` variables with the validation blocks from the Read tab, and a `locals` block that merges `env` and `managed-by = "terraform"` into the tags.

Add the `dynamic "labels"` block to `docker_container.web` and name the container `tf-web-${var.env}`.

Run `terraform plan -var='env=test' -var='tags={owner="you",project="hello-devops"}'` and confirm it fails with your `env` error message.

Run the plan again without `owner` in the tags and confirm the tags validation fails with a clear message.

Run a valid apply with `env=dev`, then `docker inspect tf-web-dev --format '{{json .Config.Labels}}'` and confirm all four labels are present.

Run `terraform destroy` and confirm the container is gone. Commit the change (never state files).

In your cloud account (AWS Budgets, Azure Cost Management or Google Cloud Billing budgets), create a monthly cost budget with a small amount and email alerts at 50%, 80% and 100% of actual spend and 100% of forecast.

Open your provider's billing or cost page, confirm nothing from earlier practice is still running, and delete anything you find (instances, disks, IP addresses, load balancers).

## Why it matters

The cloud makes it easy to create resources and just as easy to forget them. Real teams find untagged servers nobody owns, test databases left running for months, and a GPU instance someone started "for an hour". A large part of a cloud engineer's value is preventing that: every resource should have an owner, stay within agreed rules and show up in a budget that someone watches. This practice of managing cloud spending as a shared responsibility of engineering and finance is called **FinOps**.

Infrastructure as code is the best place for these guardrails, because rules written in code apply to every change automatically.

## Guardrail 1: tags on everything

**Tags** (called labels on Google Cloud and Docker) are key-value pairs attached to resources. Billing tools group costs by tag, so tags answer "which team, project and environment is this money for?" A typical required set:

| Tag | Example | Why |
|---|---|---|
| `owner` | `team-payments` | Who to ask before deleting it |
| `project` | `hello-devops` | Cost reports per product |
| `env` | `staging` | Separate production cost from test cost |
| `managed-by` | `terraform` | Warns people not to edit it by hand |

In Terraform, define tags once and apply them everywhere. The AWS provider has `default_tags`, which adds them to every resource it creates:

```hcl
provider "aws" {
  region = "us-east-1"
  default_tags {
    tags = {
      owner      = "team-payments"
      project    = "hello-devops"
      env        = var.env
      managed-by = "terraform"
    }
  }
}
```

With the local Docker provider you can practise the same idea using container labels and a `dynamic` block:

```hcl
locals {
  tags = merge(var.tags, { env = var.env, managed-by = "terraform" })
}

resource "docker_container" "web" {
  name  = "tf-web-${var.env}"
  image = docker_image.nginx.image_id

  dynamic "labels" {
    for_each = local.tags
    content {
      label = labels.key
      value = labels.value
    }
  }
}
```

## Guardrail 2: validation and policy

Terraform **variable validation** rejects bad input during `plan`, before anything is created:

```hcl
variable "env" {
  type = string
  validation {
    condition     = contains(["dev", "staging", "prod"], var.env)
    error_message = "env must be dev, staging or prod."
  }
}

variable "tags" {
  type = map(string)
  validation {
    condition     = alltrue([for k in ["owner", "project"] : contains(keys(var.tags), k)])
    error_message = "tags must include owner and project."
  }
}

variable "instance_size" {
  type    = string
  default = "small"
  validation {
    condition     = contains(["small", "medium"], var.instance_size)
    error_message = "Only small or medium sizes are allowed without an approved exception."
  }
}
```

The same idea scales up through **policy as code**: tools such as Open Policy Agent (with Conftest), Checkov, tfsec/Trivy, or HashiCorp Sentinel check a plan in CI against rules like "no public storage buckets", "every resource has an owner tag" or "no instance types larger than X". Cloud providers add their own account-level controls (AWS Service Control Policies, Azure Policy, Google Cloud Organization Policy). A rule in CI catches mistakes during review; an account-level rule catches what slips past CI.

## Guardrail 3: budgets and alerts

A **budget alert** emails you when actual or forecast spending crosses a threshold. Every major cloud has one: AWS Budgets, Azure Cost Management budgets and Google Cloud Billing budgets. Create one in every account you use, including practice accounts, before you create anything else. A sensible practice setup is a small monthly budget (for example 5 or 10 in your currency) with alerts at 50%, 80% and 100% of actual spend and 100% of forecast.

Two honest warnings:

- A budget alert **does not stop spending**. It tells you; you still have to act. Some providers let you attach automated actions, but they need careful setup.
- Billing data can lag by hours. Do not wait for an alert to clean up: delete practice resources as soon as you finish.

## Finding and cutting waste

The usual big wins are boring: delete unused resources (idle VMs, unattached disks, old snapshots, unused public IP addresses and load balancers), right-size instances that run at 5% CPU, stop non-production environments at night, set lifecycle rules on storage, and use reserved or committed-use pricing only for steady workloads. Tags make all of this possible, because you can see what each resource is for.

## Common mistakes

- Tagging by hand, so tags are missing or spelled five ways (`Env`, `env`, `environment`).
- Treating a budget alert as a spending cap.
- Validation messages that do not say how to fix the problem.
- Policies so strict that people work around them; start with warnings, then enforce.

## Quick recap

- Required tags (owner, project, env) make cost and ownership visible.
- Variable validation and policy-as-code reject bad infrastructure at plan time.
- Set a budget alert in every account first; it warns but does not stop spending.
- Delete unused resources promptly; tags tell you which ones they are.

## Try it

The Do tab has you add tag and validation guardrails to your local Terraform project and set a budget alert on your cloud practice account.

Add required tags, input validation and a budget alert so infrastructure stays labelled, within policy and within budget.

Cost and policy guardrails

AWS Budgets Tutorial - Setup Alerts for AWS Billing | Amazon Web Services

FinOps and Cloud Cost Optimization

Manage infrastructure with Terraform, keep state and modules under control, and add tag, policy and budget guardrails.