IBM Terraform Infrastructure Engineer

Hard-coded resources do not scale past a few teams. You drive configuration from maps and objects, learn why for_each keys decide what gets replaced, and trace a value through expressions to predict exactly what a change will do.

• for_each against count and the keys that stay stable
• Maps of objects as the source of truth
• flatten, merge, lookup, try and coalesce
• Dynamic blocks and nested for expressions
• Tracing a value through locals and modules
• Predicting an expression’s result in terraform console
• Finding the line that causes a plan error

You build A configuration that creates many resources from one data file, with the plan predicted first.

Provider setup grows complicated across accounts, regions and teams. You manage aliases, pass provider configurations into modules, constrain versions with intent, and learn where the Terraform MCP server helps an assistant and where it needs limits.

• Multiple provider configurations across accounts and regions
• Passing providers into modules
• Version constraints and the lock file in teams
• Setting up the Terraform MCP server for an assistant
• What an assistant should and should not be allowed to do
• Reviewing AI-suggested configuration critically

You build A multi-account provider setup with pinned versions and a documented MCP server configuration.

State is the most dangerous file in a Terraform estate. You configure and migrate backends, split and merge state, use refactoring blocks in place of manual surgery, and recover from locks and damaged state without making things worse.

• Backend configuration and partial configuration
• Migrating state between backends
• State commands: list, show, mv and rm
• moved and removed blocks for refactoring
• Splitting one state into several
• Recovering from stuck locks and damaged state
• Tracing dependency chains between resources

You build A runbook for migrating and splitting a live state file without downtime.

Real environments change behind Terraform’s back. You detect drift, decide whether to accept or revert it, read a plan for destructive replacements before they happen, and use lifecycle rules to protect what must never be recreated.

• Refresh-only plans and drift detection
• Accepting drift against reverting it
• Reading plans for replace and destroy actions
• Targeted and forced replacement, and their risks
• prevent_destroy, ignore_changes and create_before_destroy
• Recovering from a partial apply
• Troubleshooting a failed apply

You build A drift response procedure tested against an environment changed by hand.

Estates grow by adoption and by version bumps. You import infrastructure at scale, upgrade Terraform and providers one environment at a time, and promote a change from development to production with the same code and different inputs.

• Import blocks and generated configuration
• Importing many resources at once
• Upgrading Terraform across environments in order
• Provider and module upgrade strategy
• Handling deprecated arguments and breaking changes
• Workspaces against directories for environments
• Layering tfvars files per environment

You build An upgrade and promotion plan that moves one change through three environments.

Automation changes who runs Terraform, so it changes what can go wrong. You build pipelines that plan on every change and apply only what was reviewed, handle concurrency and approvals, and match deployment strategies to infrastructure.

• Plan on pull request, apply on merge
• Saved plans and the review gate
• Approvals and environment protection
• Preventing concurrent runs and state contention
• Blue-green and canary approaches for infrastructure
• Scheduled drift detection jobs
• Sharing tfvars and secrets across teams

You build A pipeline definition that plans on review and applies the approved plan.

A pipeline that can change production is a target. You replace long-lived keys with dynamic credentials, give each pipeline the least access it needs, rotate secrets and keep sensitive values out of state wherever the tooling allows.

• Dynamic provider credentials with workload identity
• Least-privilege identities for each pipeline
• Secret storage and rotation
• Keeping secrets out of state and logs
• Separating plan permissions from apply permissions
• Auditing who changed what

You build A pipeline that authenticates with short-lived credentials and no stored keys.

Review does not scale by eye alone. You write policy rules that run against every plan, inspect plan output to catch dangerous changes, and pair policy with in-code checks so mistakes are caught close to where they are made.

• What policy as code can and cannot enforce
• Writing rules against plan output
• Advisory, soft and hard enforcement
• Reading plan JSON for destroy and replace of stateful resources
• Preconditions, postconditions and check blocks
• Exceptions, ownership and rule maintenance

You build A policy set that blocks unencrypted storage and unreviewed destroys.

A module is a promise to other teams. You decide when abstraction is worth its cost, define inputs and outputs that can stay stable, version modules, publish them to a registry, and test them before anyone depends on them.

• When a module earns its existence
• Designing inputs and outputs as a contract
• Semantic versioning and breaking changes
• Refactoring into modules without recreating resources
• Public and private registry practice
• Unit tests with terraform test
• Documenting a module for its consumers

You build A versioned module with a tested interface, published to a registry.

Once many teams share a platform, the platform itself needs running. You organize workspaces and projects, track usage and cost, attach policy sets, manage teams and variable sets, and run several environments from one place.

• Organizations, projects and workspaces at scale
• Variable sets and shared configuration
• Teams, permissions and workspace access
• Policy sets and enforcement levels
• Usage tracking and cost visibility
• Run tasks and third-party checks
• Agents for private networks

You build A multi-environment HCP Terraform setup with teams, variable sets and policy.

Combine design, state, pipelines, identity, policy and modules into one platform that several teams could use tomorrow. You defend each choice as you would to a platform review board, including how it fails and how it recovers.

• Assembling the platform design
• Wiring modules, pipelines and policy together
• Testing a change end to end
• Walking through failure and recovery
• Writing the operating guide for teams

You build A working multi-environment Terraform platform with an operating guide.