LEARNING PATH · INTERMEDIATE
Terraform and Infrastructure as Code
For operators who need to preview and review infrastructure changes safely.
Prerequisites
Command-line and Git familiarity; start in an isolated local sandbox.
Learning objectives
- Format and validate configuration.
- Review replacements and deletions.
- Protect state and secrets.
Follow these lessons
Lesson 1: Run Terraform init, validate, plan, and apply safely
Format and validate configuration, inspect a saved plan, and apply only the reviewed changes in the intended workspace. Read the before-you-begin notes, follow the diagnosis in order, and pause before any state-changing step. Record the observation that supports your next decision. If the guide does not match your system, stop and compare its official reference with your installed version.
Practice task: use an isolated lab or read-only access to identify the target, run one diagnostic check, and write down what result would send you to the next step. Do not invent output or paste sensitive values. The lesson is complete when you can explain what the command measures and what it cannot prove.
Lesson 2: Protect Terraform state, variables, modules, and secrets
Understand state contents, review module inputs and outputs, and detect configuration drift without exposing secret values. Read the before-you-begin notes, follow the diagnosis in order, and pause before any state-changing step. Record the observation that supports your next decision. If the guide does not match your system, stop and compare its official reference with your installed version.
Practice task: use an isolated lab or read-only access to identify the target, run one diagnostic check, and write down what result would send you to the next step. Do not invent output or paste sensitive values. The lesson is complete when you can explain what the command measures and what it cannot prove.
Lesson 3: Investigate an unexpected Terraform resource replacement
Read the plan’s replacement markers and compare configuration, state, provider version, workspace, and immutable attributes. Read the before-you-begin notes, follow the diagnosis in order, and pause before any state-changing step. Record the observation that supports your next decision. If the guide does not match your system, stop and compare its official reference with your installed version.
Practice task: use an isolated lab or read-only access to identify the target, run one diagnostic check, and write down what result would send you to the next step. Do not invent output or paste sensitive values. The lesson is complete when you can explain what the command measures and what it cannot prove.
How to work through this path
Use the lessons in order, but return to an earlier topic when its prerequisite appears in a later incident. For each lesson, identify the system and account, note whether the command is read-only, and decide what evidence would change your next action. A command that returns successfully is evidence about one layer only; pair it with a second check when the guide calls for one.
- Read the problem statement and safety note before opening a shell.
- Run the initial inspection only on a system you are authorized to access. Capture the time and scope without collecting secrets.
- Explain the result in your own words. If it is ambiguous, consult the linked upstream manual and inspect a second signal.
- Practice changes in a disposable environment. State the rollback before applying the change.
- Repeat the original check and verify the user-facing behavior before recording the lesson complete.
This is a self-paced reading sequence, not a claim of certification or supervised lab completion. The linked provider exercises have separate access, account, and cost conditions. Review them before launching any hosted environment.
Command-line warm-up
These examples come from the first lessons in this path. They are illustrative starting points; replace sample targets with values from an authorized environment. Follow each lesson’s full context rather than copying a command without reading its safety notes.
# First lesson inspection command
terraform version# Second lesson inspection command
terraform workspace showKeep a learning record
For each topic, write down the question, the exact target, the command used, the observed result, and the next safe decision. Remove hostnames, usernames, addresses, tokens, and customer data before sharing notes. Revisit the official reference when a tool changes or a distribution uses a different service name. This record helps distinguish what you confirmed from what you inferred.
Stop when evidence conflicts, the action could affect a user, or you cannot state a safe rollback. Ask the environment owner to review the plan. When the path is complete, choose one lab, check its current prerequisites and pricing, and clean up only resources that you created.
Evidence checkpoints for this path
At the midpoint, revisit the objectives and choose one earlier lesson that another topic depends on. Explain how its observation narrows the next decision. For a systems path, compare the local state with a user-facing check; for a delivery path, compare the reviewed source with the artifact or resource that was actually produced. For a security path, use synthetic credentials and show where they are allowed to flow without printing their value. These checks turn a sequence of links into a practical learning plan.
At the end, write a short runbook of your own in a disposable environment: symptom, scope, two diagnostic signals, a reversible practice change, and verification. Do not copy real host information into a public repository. Ask a peer or system owner to challenge the assumptions and identify any command that could affect shared state. Keep uncertain platform-specific behavior as an open research question until the upstream documentation or environment confirms it.
Official documentation
Practice and next steps
Use the local Docker tutorial before cloud provisioning. Cloud resources can incur costs.
Explore the hands-on lab directory and official training recommendations. Certification exams require separate registration and passing the applicable exam.
Use this sequence as a map, not a substitute for your organization’s procedures. Tool defaults, permissions, and platform versions vary. Check current upstream documentation before a change and record what you verified.
Checkpoint: connect the lessons
Choose two related lessons and draw the dependency between them. Write what you would inspect first, what result would change your hypothesis, and which owner controls the next action. Keep the diagram focused on names and relationships rather than secrets or production identifiers. This exercise exposes gaps in the sequence: if a later lesson assumes knowledge that an earlier one never introduces, revisit the source material and submit a correction.
Next, repeat the diagnostic exercise using an isolated lab that matches your intended environment. Record the installed tool release, the system or cluster context, and the command documentation you followed. These notes let you separate a general concept from a platform-specific behavior. Never treat a result from a local lab as evidence about a separate production system.