Key facts distilled from CertKata's TA-004 question bank. Free to read — no account needed.
terraform init prepares a working directory — downloading providers and configuring the backend. terraform plan computes and previews what would change, without touching real infrastructure. terraform apply actually executes those changes. This order matters: init is a genuine prerequisite for plan or apply, and reviewing a plan before applying is what catches an unintended change before it reaches real infrastructure, not after.
A resource block declares something Terraform should create and manage — its full lifecycle is Terraform's responsibility. A data block reads information about something that already exists, managed by this configuration or not, without creating or modifying it. Use a data source to look up an existing VPC's ID; use a resource to actually provision a new one.
State is Terraform's record mapping your configuration to real-world infrastructure objects. It's what lets plan compute a diff efficiently instead of querying everything live on every run, and it's why removing a resource block from configuration proposes destroying it — deleted from config means deleted from desired state. The default local backend stores state as a plain file, which is fine alone but risky for a team: no locking, no shared access, easy to lose.
Both create multiple instances of a resource or module. count indexes instances numerically (0, 1, 2...) — removing an item from the middle of a list can reshuffle and unexpectedly recreate other instances. for_each keys instances by a stable identifier from a map or set, so removing one item doesn't disturb the others. For anything beyond a fixed, unchanging count, for_each is generally the safer default.
Every configuration is technically a module — the one in your working directory is the root module. A child module is called from another configuration via a module block and can be sourced locally (a relative path), from the public or a private registry, or from a Git repository. A module's internal variables and resources aren't visible outside it automatically; it has to expose a value through its own output block for the calling configuration to reference it as module.<name>.<output>.
State locking prevents two concurrent operations from corrupting the same state at once — most remote backends support it, the local backend does not. Configuration drift happens when real infrastructure changes outside Terraform, such as a manual console edit; plan detects this by refreshing its view of real infrastructure before computing the diff, and apply -refresh-only updates state to match reality without proposing any other configuration-driven change.
This is a preview. Get the full TA-004 cheat sheet — every domain, bundled with the practice question bank.
Sign up for the full version