Use this when the stem mixes configuration, state, providers, modules, or drift.
flowchart TD
S["Scenario"] --> C["Classify the Terraform object or command"]
C --> S2["Check state, backend, or provider fit"]
S2 --> P["Check plan, import, or dependency behavior"]
P --> V["Verify with safe apply or drift review"]
Workflow in one screen
flowchart TD
Config["Configuration"] --> Init["Init, Fmt, Validate"] --> Plan["Plan"]
State["State"] -. compared with .-> Plan
Providers["Providers"] -. refreshed during .-> Plan
Plan --> Apply["Apply"]
Apply --> Infra["Real Infrastructure + Updated State"]
Infra --> Review["Drift / Import / Review"]
Review --> Config
| Step |
What it really does |
Common exam cue |
init |
prepare working directory, backend, providers, and modules |
first step in a new or changed directory |
fmt |
normalize style |
formatting and review hygiene |
validate |
check configuration structure |
find config issues before planning |
plan |
compare configuration with state and remote reality to preview change |
safe review before execution |
apply |
perform approved changes |
make real infrastructure match intent |
destroy |
remove managed infrastructure |
teardown or cleanup lane |
| Term |
What it is really for |
Do not confuse it with |
| provider |
plugin that talks to a platform |
backend |
| backend |
state storage and access mechanism |
provider config or a resource |
| resource |
object Terraform manages |
data source |
| data source |
read-only lookup of existing information |
resource creation |
| module |
reusable configuration package |
workspace |
| workspace |
separate state instance for the same configuration |
packaging or code reuse |
| variable |
input to configuration |
state |
| output |
exported result from configuration |
dependency declaration |
Fast picker table
| If the question is really about… |
Strongest first lane |
| where Terraform remembers managed objects |
state |
| where state should live for collaboration |
backend or HCP Terraform workspace |
| reusable building block |
module |
| platform-specific API integration |
provider |
| reading an already existing object |
data source |
| separating one config across environments |
workspace |
| bringing an existing object under management |
import |
| reviewing impact before real change |
plan |
Configuration and dependency cues
| Cue |
Strong reading |
resource block |
manage and create/update/destroy something |
data block |
read something external or preexisting |
| reference from one object to another |
Terraform usually infers dependency order |
depends_on |
explicit dependency only when inference is not enough |
| expression or function |
make configuration dynamic without changing Terraform’s core model |
Common dependency traps
| Trap |
Better reading |
adding depends_on everywhere |
let references infer dependencies unless there is a real hidden dependency |
| using outputs as if they replace state awareness |
outputs expose values; state still tracks managed objects |
| treating data sources as creators |
data sources read, they do not own or create infrastructure |
State, drift, import, and backends
| Concept |
What it means |
Why the exam cares |
| state |
Terraform’s record of managed objects and mappings |
safe planning depends on it |
| drift |
real infrastructure changed outside Terraform’s expected model |
plan output and corrections depend on it |
| import |
bring an existing object under Terraform management |
management change without creating from scratch |
| remote backend |
move state off local disk into a shared controlled location |
collaboration, locking, and safety |
| state locking |
prevent unsafe concurrent changes |
protect team workflow |
State rules to remember
plan is not just syntax review. It uses configuration + state + provider knowledge to preview change.- drift means the real environment and Terraform’s expected model diverged.
- import changes Terraform’s awareness of an object; it does not mean Terraform created that object.
- remote backends are about collaboration and safety, not just convenience.
Provider versus backend
| Question |
Provider |
Backend |
| Main job |
talk to AWS, Azure, GCP, or another platform |
store and access state |
| Affects resource creation? |
yes |
no |
| Common trap |
assuming it controls where state lives |
assuming it talks to the cloud API |
Module versus workspace
| Question |
Module |
Workspace |
| Main job |
package reusable configuration |
separate state instances |
| Solves reuse? |
yes |
no |
| Solves environment separation? |
not by itself |
yes |
| Common trap |
treating it as state separation |
treating it as code reuse |
Change-safety table
| Need |
Strongest first answer |
| preview impact before execution |
plan |
| catch configuration problems before planning |
validate |
| normalize style before review |
fmt |
| collaborate without local-only state risk |
remote backend or HCP Terraform |
| control who can run and approve changes |
HCP Terraform workflow/governance features |
| correct Terraform ownership of an existing object |
import plus config alignment |
| If the question is really about… |
Strongest first lane |
| remote runs and shared workflow |
HCP Terraform workspace |
| centralized state and collaboration |
HCP Terraform platform features |
| governance or policy controls |
HCP Terraform platform layer |
| credentials and variables for shared runs |
workspace/platform configuration |
| Trap |
Better reading |
| CLI workflow and HCP Terraform are interchangeable |
HCP Terraform adds collaboration, remote execution, and governance around the workflow |
| workspace means the same thing everywhere |
Terraform CLI workspaces and HCP Terraform workspaces both separate run contexts, but the platform also adds workflow features |
High-confusion pairs
| Pair |
Keep this distinction clear |
| provider vs backend |
cloud API integration versus state storage |
| resource vs data source |
managed object versus read-only lookup |
| module vs workspace |
code reuse versus state separation |
| plan vs apply |
preview versus execution |
| drift vs import |
unexpected external change versus bringing an existing object under management |
Last 15-minute review
| Recheck this |
Because the miss usually hides here |
what init actually prepares |
it is more than just downloading one provider |
why plan matters |
it is the core safety and review surface |
| what state is recording |
many wrong answers treat state as optional metadata |
| backend, module, workspace, and provider boundaries |
Terraform nouns blur easily under time pressure |
| HCP Terraform role |
collaboration and governance sit above raw CLI flow |
- separate configuration authoring, state behavior, and platform workflow
- reason from plan and state before talking about execution
- keep provider, backend, module, workspace, resource, and data source boundaries clear
- choose the safer collaborative workflow when the stem points to team use