Puppet and OpenTofu

Before you read. Ansible configured your fifty web servers beautifully. Then somebody asks two questions.

“What stops these drifting between our Ansible runs?” And: “who creates the servers in the first place, the load balancer, the DNS records, the firewall rules?”

Ansible is a poor answer to both, and the reasons are different.

Ansible is push-based, so nothing happens between runs; and it configures machines that exist rather than bringing them into being. Those are two separate gaps, and they have two separate tools.

Puppet runs continuously on each machine, dragging it back toward a description every thirty minutes. OpenTofu creates infrastructure through APIs and keeps a record of what it made, so it can change or destroy it later.

Neither replaces Ansible. All three are routinely used together, and the exam expects you to know which answers which.

Some words you will need

manifest

A Puppet file describing resources. Extension .pp.

catalog

The compiled, host-specific result of the manifests. What actually gets applied.

resource

One thing being managed. A file, a package, a user, a cloud instance.

provider

An OpenTofu plugin that knows how to talk to one API. AWS, Azure, or local.

plan

OpenTofu's preview of what it would create, change, or destroy.

state

OpenTofu's record mapping your configuration to real objects it created.

facter

Puppet's fact-gathering tool. The equivalent of Ansible's facts.

What breaks without this

Drift returns between runs. A push tool leaves a window, and somebody always uses it.

Nothing creates the infrastructure. Machines, networks, DNS records, and load balancers get made by hand in a console, which is a runbook problem with a nicer interface.

Nothing knows what it made. Without state, a tool cannot tell an instance it created from one somebody else did, so it cannot safely change or remove anything.

And the estate cannot be destroyed. A test environment nobody can tear down reliably is a test environment that runs permanently and costs money.

Puppet: convergence, continuously

A manifest describes resources. This one manages a directory, a file, and a user:

file { '/srv/site':
  ensure => directory,
  mode   => '0755',
}

file { '/srv/site/index.html':
  ensure  => file,
  content => "Managed by Puppet\n",
  mode    => '0644',
  require => File['/srv/site'],
}

user { 'deploy':
  ensure => present,
  shell  => '/usr/sbin/nologin',
}

The syntax is type { 'title': attribute => value }, and it is declarative in a stricter sense than Ansible: these are statements about what should be true, with no implied order.

puppet apply --noop is the check mode, and reports without changing:

# Debian 13 (trixie), x86_64
$ cd /root/pp; puppet --version; echo "--- noop: what would change ---"; puppet apply --color=false --noop site.pp 2>&1 | tail -6
8.10.0
--- noop: what would change ---
Notice: /Stage[main]/Main/File[/srv/site]/ensure: created (noop)
Notice: /Stage[main]/Main/File[/srv/site/index.html]/ensure: defined content as '{sha256}d8a6473563979588d4c4bb2e1be20b5f956c7f10b7b4497c8b2cfa72fd242b9c' (noop)
Notice: /Stage[main]/Main/User[deploy]/ensure: created (noop)
Notice: Class[Main]: Would have triggered 'refresh' from 3 events
Notice: Stage[main]: Would have triggered 'refresh' from 1 event
Notice: Applied catalog in 0.03 seconds

(noop) on each line means nothing happened. The resource path /Stage[main]/Main/File[/srv/site] is Puppet’s identifier for a resource, and it is what error messages will name, worth being able to read.

The content is reported as a SHA-256 rather than as text, which is how Puppet compares file contents: it hashes rather than diffs by default. --show_diff gives the actual difference.

# Debian 13 (trixie), x86_64
$ cd /root/pp; puppet apply --color=false site.pp >/dev/null 2>&1; echo "=== SECOND RUN ==="; puppet apply --color=false site.pp 2>&1 | tail -3
=== SECOND RUN ===
Notice: Compiled catalog for 3ef721a0f87e.home.arpa in environment production in 0.04 seconds
Notice: Applied catalog in 0.03 seconds

Two lines and no resources mentioned at all. Puppet reports only what it changed, so silence is success, the same idempotence as Ansible’s changed=0, expressed by absence rather than by a count.

“Compiled catalog” is the step worth understanding. Puppet does not apply the manifest directly. It compiles the manifests, the facts about this host, and any data into a catalog, a host-specific list of resources with dependencies resolved, and then applies that. In a client-server deployment the compilation happens on the server and the catalog is sent to the agent.

Puppet decides its own order

This is the genuine difference from Ansible and the thing that disorients people.

Ansible runs tasks top to bottom. Puppet does not. Resources in a manifest have no implied order at all, and Puppet builds a dependency graph and chooses.

You express order through relationships:

In the manifest above, require => File['/srv/site'] is why the directory is created before the file in it. Without that line, Puppet might do either first, and the manifest would work most of the time and fail unpredictably, which is a much worse failure than failing every time.

notify and subscribe are the same relationship from opposite ends, and they are Puppet’s handlers: a service subscribing to a config file restarts when it changes, once, at the right point in the graph.

Why anybody would want this: the graph means Puppet can apply independent resources in parallel, and it means a module can declare its own internal ordering without knowing where in a larger manifest it will be included. The cost is that ordering bugs are invisible until they bite.

OpenTofu: making things that do not exist

Puppet and Ansible configure machines. OpenTofu creates them (and networks, databases, DNS records, and load balancers) by calling APIs.

A provider is a plugin that knows one API. There are thousands: AWS, Azure, Google, Kubernetes, GitHub, Cloudflare. The local provider used here manages files on the machine, which makes the mechanics visible without a cloud account.

terraform {
  required_providers {
    local = {
      source  = "opentofu/local"
      version = "~> 2.5"
    }
  }
}

resource "local_file" "motd" {
  filename        = "/srv/motd"
  content         = "Managed by OpenTofu. Do not edit.\n"
  file_permission = "0644"
}

resource "type" "name" declares one thing. The name is yours and is how you refer to it elsewhere, local_file.motd.filename, which is how resources are wired together without hardcoding values.

tofu plan shows what would happen, and it is the command that matters:

# Debian 13 (trixie), aarch64
$ cd /root/infra; tofu version | head -2; echo "--- what it will do ---"; tofu init -no-color >/dev/null 2>&1; tofu plan -no-color 2>&1 | tail -14
OpenTofu v1.10.6
on linux_arm64
--- what it will do ---
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0644"
      + filename             = "/srv/motd"
      + id                   = (known after apply)
    }

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

─────────────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so OpenTofu can't
guarantee to take exactly these actions if you run "tofu apply" now.

Plan: 1 to add, 0 to change, 0 to destroy is the line to read, and on a real estate it is the line that stops an outage. A plan reporting 0 to destroy when you expected zero is a change you can approve; one reporting 14 to destroy when you changed a tag is a provider forcing replacement, and finding that out before apply is the entire point.

(known after apply) marks values that do not exist yet, an ID the API will assign. That is why a plan cannot always be complete, and why -out exists to save a plan so that apply executes exactly what was reviewed.

tofu init downloads the providers and must run first in a new directory. It is also what creates the lock file pinning provider versions, which belongs in Git.

State is what makes that possible

# Debian 13 (trixie), aarch64
$ cd /root/infra; tofu init -no-color >/dev/null 2>&1; tofu apply -no-color -auto-approve 2>&1 | tail -6; echo "=== PLAN AGAIN ==="; tofu plan -no-color 2>&1 | tail -3

Plan: 1 to add, 0 to change, 0 to destroy.
local_file.motd: Creating...
local_file.motd: Creation complete after 0s [id=e42fb7825ca4214eea1a62b832741f10b2904675]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
=== PLAN AGAIN ===

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

# Debian 13 (trixie), aarch64
$ cd /root/infra; tofu init -no-color >/dev/null 2>&1; tofu apply -no-color -auto-approve >/dev/null 2>&1; echo "--- somebody deletes it outside tofu ---"; rm -f /srv/motd; tofu plan -no-color 2>&1 | tail -6
--- somebody deletes it outside tofu ---
Plan: 1 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so OpenTofu can't
guarantee to take exactly these actions if you run "tofu apply" now.

Three different answers, and the third is drift detection. OpenTofu knew the file should exist because its state said it created one, checked, found it gone, and planned to recreate it.

Read the phrasing of the second plan carefully: “compared your real infrastructure against your configuration”. That comparison is only possible because state records which real object corresponds to which resource block: local_file.motd is the file with id e42fb78.... Without that mapping the tool would have no idea whether a file it can see is one it made.

terraform.tfstate is a JSON file, and everything lesson 57 said about it applies: it contains generated passwords and keys in plaintext, two concurrent runs corrupt it, and losing it does not destroy your infrastructure but destroys your ability to manage it.

tofu destroy is a real command that really works, which is a feature and a hazard. It is how a test environment costs nothing overnight, and it is why nobody should have credentials that can run it against production.

module "web_tier" {
  source        = "./modules/web-tier"
  instance_count = var.instance_count
  instance_type  = var.instance_type
  environment    = var.environment
}

tofu apply -var-file=environments/production.tfvars
tofu apply -var-file=environments/staging.tfvars

# hiera.yaml
hierarchy:
  - name: "Per-node"
    path: "nodes/%{trusted.certname}.yaml"
  - name: "Per-environment"
    path: "environments/%{server_facts.environment}.yaml"
  - name: "Common"
    path: "common.yaml"

Which one, for what

The distinction that matters, and the one interviews ask about:

They compose rather than compete, and the usual arrangement is all three:

OpenTofu creates the VM, the network, the security group, and the DNS record
        ↓
cloud-init sets the hostname and the SSH keys on first boot
        ↓
Ansible installs and configures the application
        ↓
Puppet keeps it that way, or a scheduled Ansible run does

The common mistake is using one for another’s job. OpenTofu with a long user_data shell script is configuration management done badly, imperative, not idempotent, and invisible to the plan. Ansible creating cloud resources through modules works and has no state, so it cannot tell you what it made or remove it later.

And the honest note about scale: on a handful of machines, Ansible on a cron timer gets you most of what Puppet offers, without an agent. The argument for Puppet strengthens with fleet size, with the number of people making changes, and with how much you need to prove that machines are compliant, which is the audit argument from lesson 50 arriving again.

Across distributions

The Puppet packaging split catches people. Debian ships an older puppet package with its own paths; Puppet’s own puppet-agent package uses /opt/puppetlabs and /etc/puppetlabs on every distribution. Documentation assumes the latter, so a Debian-packaged install has different paths from every guide you will read.

Neither OpenTofu nor Terraform is in the distribution repositories, which is deliberate on their part. The release cadence is faster than a distribution’s. That makes them the /opt case from lesson 08: a self-contained third-party binary, version-pinned by you, invisible to the package manager.

Prove it

# Puppet: what would change, without changing it
puppet apply --noop --show_diff site.pp
puppet agent --test --noop

# What does Puppet think this machine is
facter os
puppet resource user deploy

# OpenTofu: the four commands in order
tofu init
tofu validate
tofu plan -out=tfplan
tofu apply tfplan

# What does state actually contain
tofu state list
tofu state show local_file.motd

puppet resource user deploy is worth knowing, because it works in reverse: it inspects the machine and prints the manifest that would produce what is there. That is the fastest way to learn the syntax and a genuine tool for capturing an existing configuration.

tofu plan -out=tfplan then tofu apply tfplan is the production pattern. Saving the plan means apply performs exactly what was reviewed, rather than re-planning against an estate that may have moved in between.

What trips people up

1. Expecting Puppet to run resources in order

It builds a dependency graph. Without require, before, notify, or subscribe, the order is unspecified, so a manifest can work for months and then fail.

2. tofu apply without reading the plan

The number that matters is to destroy. A provider that decides an attribute change requires replacement will happily destroy and recreate a database.

3. State in Git

Plaintext secrets, and no locking. Remote backend, encrypted, locked.

4. Two people applying at once

Without a locking backend, the second write overwrites the first and leaves resources that exist and are recorded nowhere.

5. user_data as configuration management

An imperative shell script inside a declarative tool. It is invisible to the plan, not idempotent, and runs once.

6. Debian’s puppet package against Puppet’s puppet-agent

Different paths. Every guide assumes /etc/puppetlabs; the Debian package uses /etc/puppet.

Work it through

A team runs Ansible from a laptop to configure twelve servers. It works. They are asked two things: prove to an auditor that the servers are compliant at any given moment, and stand up an identical environment in a second region.

Reason it out before reading on. These are two different problems.

The audit question is about continuous enforcement and evidence. Ansible from a laptop can prove what happened when somebody ran it, which is not the same as proving the state now. Two proportionate answers:

Run Ansible on a schedule from a server, in check mode, and record the output. --check --diff on a timer produces exactly the drift report the auditor wants, and changes nothing. This is the small answer and it is often enough for twelve servers.

Or adopt Puppet if the estate is growing and enforcement matters more than reporting. The agent converges every thirty minutes and the server holds a report per node, which is the compliance dashboard as a side effect. That is real work (an agent everywhere, a CA to maintain) and twelve servers probably do not justify it yet.

The second region is the OpenTofu question, and Ansible is the wrong tool for it. Standing up an environment means creating VMs, networks, security groups, and DNS, things that do not exist, through APIs. Ansible has cloud modules and no state, so it can create them and cannot tell you afterwards what it made or remove it.

The arrangement they end up with:

OpenTofu   defines the environment, once, applied per region with different variables
Ansible    configures the machines it created
A timer    runs Ansible in check mode nightly and reports drift

And the thing to warn them about: the second region will expose every assumption their Ansible has about the first. Hardcoded IP addresses, hostnames, and region names all surface at once. That is not a failure of the tooling. It is the value of the exercise, because those assumptions were always there and nobody could see them.

The point worth extracting: “which tool” is nearly always the wrong first question. The right one is which of the three gaps you have (something does not exist, something is not configured, or something does not stay configured) and each has an obvious answer once it is named.

Try it

Optional. Both parts run locally with no cloud account.

1. apt install puppet or dnf install puppet-agent.
2. Write the three-resource manifest from this lesson.
3. puppet apply --noop site.pp, then for real, then again. Watch the third run go quiet.
4. Delete the require line and read the manifest again. Convince yourself the order is now unspecified.
5. puppet resource user root and compare the output to the manifest syntax.
6. Download OpenTofu and write the local_file example.
7. tofu init, tofu plan, tofu apply, tofu plan again.
8. cat terraform.tfstate and find the id.
9. rm the managed file and run tofu plan. Then tofu destroy.

Verification step. You have it when you can say, for any given task, which of the three gaps it falls into, and therefore which tool.

Check yourself

file { '/srv/site/index.html':
  ensure  => file,
  require => File['/srv/site'],
}

tofu plan -out=tfplan
tofu apply tfplan

References

• Puppet documentation - Puppet. Accessed 2026-08-08.
• Puppet resource types - Puppet. Accessed 2026-08-08.
• OpenTofu documentation - OpenTofu. Accessed 2026-08-08.
• OpenTofu: State - OpenTofu. Accessed 2026-08-08.
• OpenTofu: Providers - OpenTofu. Accessed 2026-08-08.
• puppet-apply(8) - Puppet. Accessed 2026-08-08.

Every block above with a distribution and architecture header was captured by running the command on a Debian 13 (trixie) container. The OpenTofu blocks say aarch64 because its release binary crashes under emulation on this host with a Go runtime error, so those captures were run natively on arm64. The behaviour shown does not vary by architecture. Blocks without a header are illustrative.