HashiCorp Certified: Terraform Authoring and Operations Advanced Study Guide¶

Independent AI-assisted resource — SOURCES + OBJECTIVES CHECKED; HUMAN REVIEW PENDING. Objective coverage, citations, volatility labels, links, and exam-integrity compliance were reviewed on October 28, 2026 across all 27 detailed objectives; this is not a guarantee that the guide is error-free or current after that date. See the sources-and-objectives record. The official HashiCorp Advanced exam content list is authoritative.

Study guide at a glance

Start here

Report an issue with TERRAFORM-AUTHORING-OPERATIONS-PROFESSIONAL

Blueprint checked2026-10-28

Review stateSources + objectives checked — human review pending

Guide-only active reading45 min–1 hr

Prerequisites: Terraform Associate-level knowledge, Linux terminal fluency, HCL and structured-data experience, cloud credentials and networking knowledge, and extensive production Terraform authoring and operations experience.

Exam essentialsRead the objective map, key distinctions, and readiness checklist.

Deep understandingWork through every domain, including decisions, failure modes, and related items.

Hands-on labsBegin with Lab 1: Import and normalize an existing object, then use the remaining labs to produce evidence you can inspect and explain.

Official objective domains

1. Manage resource lifecycleNot published
2. Develop and troubleshoot dynamic configurationNot published
3. Develop collaborative Terraform workflowsNot published
4. Create, maintain, and use Terraform modulesNot published
5. Configure and use Terraform providersNot published
6. Collaborate on infrastructure as code using HCP TerraformNot published

The active-reading range uses 90–130 words per minute for technical material. Labs, troubleshooting, note-taking, spaced review, and prerequisite gaps add time; it is not a total preparation promise.

Current baseline: Terraform Authoring and Operations Advanced, Terraform 1.6 and AWS-provider exam version; verified September 28, 2026
Upcoming blueprint change: None announced. Both AWS and Azure provider exam versions are now available for the same Terraform Advanced credential.
Official source: Terraform Authoring and Operations Advanced content list

HashiCorp renamed the credential from Professional to Advanced in fall 2026. Existing Professional holders become Advanced holders automatically, and HashiCorp says the exam content and lab-based format did not change. HashiCorp does not display a short exam code for this credential, so this library retains TERRAFORM-AUTHORING-OPERATIONS-PROFESSIONAL as a stable legacy internal identifier; it is not the current public title.

Living-guide watch — October 28, 2026¶

Credential and exam status: HashiCorp's Professional-to-Advanced rename is complete. The current Terraform Authoring and Operations Advanced page offers both AWS and Azure provider exam versions for the same credential, tests Terraform 1.6, and retains the six-domain objective list and lab-plus-multiple-choice contract. The previous “Azure version expected late 2026” note is no longer upcoming. HCP Terraform also supports organization-scoped Azure DevOps PATs; migrate integrations before global PAT retirement on December 1, 2026. These are credential and product updates, not evidence of changed lab objectives. See the current credential page, current content list, and HCP Terraform changelog.

How to use this guide¶

This is a performance-oriented advanced credential, not an associate exam with harder vocabulary. HashiCorp expects extensive production experience, Linux terminal fluency, cloud-provider and credential knowledge, and deep Terraform authoring and operations skill. The official orientation describes lab scenarios whose grading inspects configuration, state, and provisioned infrastructure, plus a multiple-choice HCP Terraform portion.

Choose a route:

Gap analysis: Read the objective map and high-value distinctions, then use the official content list to identify weak operations.
Authoring practice: Concentrate on dynamic expressions, types, validation, modules, provider configuration, and refactoring without address churn.
Operations practice: Repeatedly initialize, plan, import, move, apply, diagnose, and recover disposable environments under time pressure.
Exam-environment practice: Work from a Linux terminal with unfamiliar editor defaults, limited documentation, and no general web search. Accuracy and verification matter more than typing speed.
HCP Terraform review: Study runs, workspaces, access, credentials, and policy as architecture decisions. HashiCorp labels this domain multiple-choice only.

The Terraform Associate (004) guide is a prerequisite refresher, not a substitute for production experience.

About related items: A Related item: callout adds prerequisite, operational, architectural, or adjacent context that makes the current topic easier to understand. It is useful supporting knowledge, not a claim that the item appears verbatim in the published exam objectives.

Objective map¶

HashiCorp publishes six domains and detailed subobjectives without percentage weights. Do not infer scoring from this guide's length or the number of bullets.

Published domain	Weight	Guide coverage
1. Manage resource lifecycle	Not published	CLI workflow, plans, apply/destroy, import, state, drift, and safe refactoring
2. Develop and troubleshoot dynamic configuration	Not published	Validation, data sources, functions, expressions, meta-arguments, types, outputs, and sensitive data
3. Develop collaborative Terraform workflows	Not published	Version management, remote state, automation, locking, and cross-configuration data
4. Create, maintain, and use Terraform modules	Not published	Interface design, composition, sourcing, versioning, refactoring, and migration
5. Configure and use Terraform providers	Not published	Plugin architecture, aliases, sourcing, upgrades, authentication, and troubleshooting
6. Collaborate on infrastructure as code using HCP Terraform	Not published	Runs, workspaces, access, dynamic credentials, policy, and governance; multiple-choice only

The September 28 review maps all 27 subobjectives; accepted snapshots remain unchanged. The certification page specifies Terraform 1.6, even though Associate (004) tests 1.12. Use the correct documentation version for the selected exam environment. Ephemeral values (1.10+), write-only arguments (1.11+) and test-provider mocking (1.7+) are newer practical context, not usable 1.6 syntax.

Exam operating model¶

The current exam uses AWS resources. HashiCorp's content list names the provider resources and documentation available for that version. The practice-lab catalog already includes an Azure import exercise; that is preparation material, not proof that the Azure exam can be booked. The announced Azure version changes provider syntax and cloud-resource behavior, not the durable Terraform domains. VERIFY CURRENT: provider-version availability, the resources exposed in the environment, permitted documentation, keyboard constraints, and exam delivery details immediately before scheduling. The library will recheck the late-2026 Azure announcement on October 28; this is a review checkpoint, not a vendor launch date.

Treat each lab as a small production change:

requirements
    ↓
inspect configuration, state, provider, and environment
    ↓
predict the smallest safe change
    ↓
format + validate + plan
    ↓
read addresses, dependencies, and replacement reasons
    ↓
apply only when the plan matches intent
    ↓
verify configuration + state + remote result

Do not optimize for “a successful command.” A configuration can validate while targeting the wrong account, an apply can succeed while creating the wrong topology, and a manual cloud change can satisfy a visual check while leaving Terraform state inconsistent.

Related item: Performance exams reward a repeatable verification loop. Shell history, targeted state inspection, saved plan output, and provider/API observations are evidence; success-colored terminal output alone is not.

1. Manage resource lifecycle¶

Initialize with intent¶

terraform init installs providers and modules, prepares the backend, and creates or updates local initialization metadata. It is safe to rerun, but backend and dependency changes still require judgment. Know when to use normal initialization, -upgrade, backend migration, or reconfiguration. The initialization command reference is the precise source for current options.

Before initializing, identify:

the root module and working directory;
the required Terraform and provider versions;
the backend and target state location;
module sources and credentials;
whether a backend change should migrate existing state or deliberately start elsewhere.

A common professional failure is initializing successfully against the wrong backend or workspace. Check the backend configuration and current workspace before planning.

init -migrate-state attempts to copy existing state to the new backend; init -reconfigure discards the saved backend configuration and does not migrate state. Choosing reconfiguration when migration was intended can leave the old bindings behind. Inspect both state locations and the destination before any apply.

Plan as a diagnostic artifact¶

The plan command combines configuration, prior state, provider observations, input values, and dependency analysis. Read the full plan rather than only the summary.

For each action, ask:

Is the resource address the intended instance?
Is a change in-place, create, destroy, replace, import, move, or forget?
What forces replacement?
Which values remain unknown until apply, and why?
Did refresh expose drift?
Are provider aliases, regions, accounts, and credentials correct?
Does targeting hide related changes?

Resource targeting is a recovery and exceptional-scoping tool, not a normal decomposition strategy. A targeted plan can omit other changes required to reconcile the complete configuration. Follow it with an untargeted plan.

Apply and destroy safely¶

Applying a saved plan binds execution to the reviewed proposal; applying without a plan file creates a fresh plan. Both can become unsafe if credentials, remote objects, or external dependencies change. Terraform is not a transaction coordinator across independent provider APIs: a failure can leave partial changes. Inspect the resulting state and create a new plan before retrying.

Destroy is a planned lifecycle operation. Review dependencies, retention requirements, provider protections, lifecycle rules, and data backups. prevent_destroy can block a Terraform destroy or replacement, but it is not a backup, cloud deletion lock, or authorization boundary.

State, import, drift, and refactoring¶

Terraform state maps configuration addresses to remote identities and retains attributes needed for planning. Professional operations require distinguishing four things:

Operation	Configuration	State binding	Remote object
Normal apply	Desired declaration changes	Updated	Created/changed/deleted to converge
Import	Must describe the intended object	Existing identity becomes bound	Not created by import
`moved` block	New address declared	Binding moves to new address	Normally preserved
Remove from management	Declaration records or implies removal	Binding removed	May be destroyed or retained depending on method

Use configuration-driven import blocks when a reviewed, repeatable import belongs in the change. Import creates a binding; it does not prove that the configuration fully matches the remote object. Always plan afterward.

When drift appears, determine whether the remote change was authorized and whether configuration or the object should become authoritative. terraform plan -refresh-only previews proposed state reconciliation without persisting it or proposing configuration convergence. If the proposal is correct, terraform apply -refresh-only accepts and writes the state update. Use this mode only when accepting the remote change is the intended decision, and retain the same state-backup and review discipline used for other state-sensitive work.

Related item: State surgery can repair a binding, but it bypasses normal configuration review. Back up state, record the reason, use the narrowest command, and immediately verify with a full plan.

Failure patterns¶

wrong backend or workspace;
importing to the wrong address or provider alias;
renaming a resource without a moved block;
using -target until the plan looks quiet;
treating refresh-only as remediation rather than acceptance of observed reality;
retrying a partial apply without inspecting state and the remote system;
applying a plan generated with different input, credentials, or provider assumptions.

2. Develop and troubleshoot dynamic configuration¶

Model data before writing expressions¶

Strong HCL starts with stable identities and precise types. Choose structures based on meaning:

Need	Prefer	Reason
Named objects whose identity must survive reordering	`map(object(...))` with `for_each`	Stable keys become instance addresses
Ordered repeated values	`list(T)`	Position is meaningful
Unique unordered values	`set(T)`	Membership matters, not position
A fixed heterogeneous interface	`object({...})` or `tuple([...])`	Shape is explicit
Derived reusable expression	`locals`	Names a transformation without expanding the module interface

Use input validation to reject invalid caller data, preconditions to assert assumptions before an operation, postconditions to assert guarantees after evaluation, and check blocks for ongoing assertions that should report rather than necessarily block infrastructure changes. Review current semantics in custom conditions and validation.

Data sources and unknown values¶

A data source queries a provider without owning the remote object's lifecycle. A reference creates an implicit dependency when data flows between objects. Use depends_on only for a real behavioral dependency that expressions cannot represent.

Unknown values are not errors. Terraform preserves them when an input can be known only after an upstream apply. Trouble begins when an unknown value is needed to determine instance count, for_each keys, provider selection, or another graph-shaping decision during planning. Move stable identity into configuration-known keys and keep apply-time values in attributes.

Expressions, functions, and meta-arguments¶

Be fluent with conditionals, for expressions, splats, collection functions, string/path functions, try, can, coalesce, flatten, merge, setproduct, and type conversion. The goal is not memorizing every function; it is recognizing input types, output shape, unknown/null behavior, and stable keys.

Meta-arguments solve different problems:

Meta-argument	Decision
`count`	Create indexed instances when position is stable and meaningful
`for_each`	Create keyed instances when identity should follow a key
`depends_on`	Add a hidden dependency not represented by value flow
`provider`	Select a nondefault provider configuration
`lifecycle`	Change replacement, ignore, or safety behavior

Avoid ignore_changes as a blanket drift suppressor. It deliberately assigns ownership of selected attributes elsewhere; document that control plane and ensure ignored changes cannot undermine security or availability.

Sensitive data¶

Marking a value sensitive redacts normal display but does not remove it from state or plan artifacts. Prefer short-lived provider credentials, external secret stores, and supported ephemeral or write-only paths where appropriate. Protect state, saved plans, crash logs, debug output, CI artifacts, and shell history. HashiCorp's sensitive-data guidance distinguishes display protection from persistence protection.

Related item: Vault can issue dynamic secrets, but Terraform may still persist values it receives if the provider/resource schema stores them. Secret issuance and state persistence are separate boundaries.

Troubleshooting sequence¶

Run terraform fmt -check and terraform validate.
Inspect exact type errors rather than adding conversions at random.
Use terraform console with representative values to test expressions.
Inspect instance keys and addresses.
Separate configuration-known, state-known, data-source, and apply-time values.
Reduce the expression to a small local value or output in a disposable branch.
Enable targeted logging only when necessary; protect and delete the logs afterward.

3. Develop collaborative Terraform workflows¶

Pin, lock, and upgrade deliberately¶

Manage four version layers separately:

Terraform CLI constraint and installation;
provider source constraints and .terraform.lock.hcl selections;
module sources and versions;
cloud/API behavior outside Terraform's version system.

Constraints define acceptable versions; the lock file records selected provider versions and checksums. Test upgrades in a branch, review lock changes, read upgrade notes, plan representative environments, and roll forward in controlled stages.

Remote state and locking¶

Remote state centralizes the address-to-object record for collaboration. It requires access control, encryption, recovery/versioning, and locking appropriate to the backend. Locking reduces concurrent writers; it does not resolve competing design ownership or guarantee that every backend supports locking identically. Review remote state and the selected backend's current behavior.

Split state by lifecycle, ownership, blast radius, and access—not merely by directory aesthetics. Avoid a single state that forces unrelated teams to share credentials and change windows; also avoid fragments connected by fragile chains of remote outputs.

Related item — VERIFY CURRENT: Current S3 backend documentation offers opt-in use_lockfile locking and deprecates DynamoDB locking. The exam's Terraform 1.6 baseline predates native S3 lockfiles: do not paste a modern backend example into that environment. Follow its version-specific configuration. For production migration, inventory every writer and test compatible locking before changing coordination.

terraform_remote_state exposes root outputs from another state but requires access to the backing state system, which may be broader than the output implies. HCP Terraform's tfe_outputs can provide a narrower output-sharing path. Alternatives include publishing identifiers through a configuration registry, DNS, parameter store, or provider data source.

The remote-state data-source warning is stronger than output redaction: a principal able to fetch outputs through the state snapshot can also retrieve that snapshot, including its other data. Marking an output sensitive does not create an output-only authorization boundary. Choose based on ownership, freshness, access boundary, failure behavior, and whether the consumer needs a Terraform-specific coupling.

Automation workflow¶

A dependable pipeline separates:

format/validate → test/static checks → speculative plan → review/policy
                → approved apply → post-apply verification → evidence

Use noninteractive flags intentionally, inject credentials through the platform, serialize applies per state, preserve a reviewable plan where appropriate, and ensure the apply uses the reviewed revision and inputs. Do not expose state or plan files as broadly readable build artifacts.

Related item: A pipeline is part of the Terraform control plane. Protect workflow changes, runner identity, plugin/module provenance, variables, approval rules, and logs with the same care as infrastructure credentials.

4. Create, maintain, and use modules¶

Design an interface, not a folder¶

A useful module encapsulates one coherent capability with:

typed, validated inputs;
minimal outputs needed by callers;
stable resource identities;
documented provider and version requirements;
explicit security and lifecycle assumptions;
examples and automated tests;
an upgrade path for breaking changes.

Avoid mirroring every provider argument as a module variable. That creates an expensive wrapper without a meaningful abstraction. Encode a supported operating model while leaving deliberate extension points.

The module documentation explains calling, sourcing, composition, and scope. Child modules receive values through inputs and expose values through outputs; they do not inherit arbitrary caller variables. Provider configurations should normally be supplied by the root module, while reusable child modules declare provider requirements.

Version and refactor safely¶

Registry modules can use semantic version constraints. Git sources should reference deliberate tags or immutable commits rather than floating branches for production. Test a new module version against representative callers.

Refactoring can change code without changing remote infrastructure when address migrations are declared. Use moved blocks for resource or module address changes and preserve them long enough for all supported upgrade paths. When splitting a configuration into modules or separate states, plan the address and state migration before editing files.

Module review questions¶

Does each input represent a supported decision rather than provider passthrough?
Are types and defaults safe?
Can callers accidentally create unstable for_each keys?
Which resources force replacement when an input changes?
Are outputs sufficient but not secret-heavy?
Are providers injected correctly for aliases and multiple regions/accounts?
Can an older caller traverse the proposed migration without destroy/recreate?

5. Configure and use providers¶

Terraform Core loads provider plugins that define schemas, translate planned operations, call remote APIs, and return state. Provider source addresses and version constraints belong in required_providers; endpoint, region, alias, and authentication behavior belong in provider configurations. Review provider requirements.

Aliases and module boundaries¶

Use aliases for multiple configurations of one provider, such as regions or accounts. Pass aliased configurations explicitly to modules and declare configuration_aliases where a child module expects them. The module-provider reference distinguishes inherited default configurations from aliases, which must be passed explicitly. Keep a provider configuration available until Terraform has destroyed resources that depend on it. Provider requirements select plugins; passing an alias does not replace a child's requirement declaration.

A resource that silently uses the default provider can target the wrong environment even when every other value looks correct.

Authentication¶

Prefer the provider's supported ambient or workload-identity chain over static credentials in configuration. Understand precedence among environment variables, shared credential files, instance/workload identity, assumed roles, and explicit arguments. The exact chain is provider-specific and VERIFY CURRENT.

Troubleshooting providers¶

Classify the failure before changing configuration:

Failure phase	Likely boundary
`init` cannot install	Source address, network/registry access, constraint, lock checksum, platform build
Schema/configuration error	Provider version, renamed/deprecated argument, wrong alias, missing required block
Authentication error	Credential source, expiration, trust, tenant/account, environment precedence
Authorization error	Identity is known but lacks action/resource permission
API validation error	Provider request conflicts with remote service rules
Inconsistent result/state error	Provider bug, eventual consistency, concurrent change, schema mismatch

Do not delete the lock file or state as a first troubleshooting step. Preserve evidence, reproduce narrowly, and compare provider release notes and debug logs without leaking secrets.

6. Collaborate using HCP Terraform¶

This domain is multiple-choice only in the current official content list, but it still tests architectural reasoning.

Runs and workspaces¶

An HCP Terraform workspace owns state, variables, run history, execution settings, and access around one configuration boundary. A run moves through planning, policy and task checks, approval, apply, and completion states depending on configuration. Review current run behavior and workspace concepts.

Do not confuse an HCP Terraform workspace with a CLI workspace. A CLI workspace is an alternate state instance for one working directory; an HCP workspace is a managed collaboration and execution boundary.

Credentials and access¶

Workspace variables can hold configuration and sensitive values, but long-lived cloud keys create rotation and exposure burden. Dynamic provider credentials use workload identity to obtain short-lived credentials for runs. This reduces stored-secret risk while introducing an issuer, audience, claim, trust-policy, and role-permission boundary that must be governed.

Scope teams and permissions to projects/workspaces based on duties. Separate permission to queue a plan, approve an apply, administer variables, read state, and change workspace settings where the service supports it.

Policy and extensibility¶

Policy sets evaluate organization rules against runs. The run-task reference distinguishes advisory failures, which allow progress, from mandatory failures, which stop the run, including documented timeout/error cases. Match the stage to the control: a post-apply check cannot prevent infrastructure changes that already happened. Project scopes and exclusions require review when moving workspaces. Run tasks integrate external checks; run triggers connect workspace execution dependencies. A control should have a clear enforcement point, failure behavior, ownership, and exception process. See HCP Terraform policy enforcement.

VERIFY CURRENT: HCP Terraform editions, entitlements, run modes, agent behavior, project/workspace permissions, policy engines, run-task stages, health features, and Terraform Enterprise parity change independently.

Integrated professional playbook¶

For any scenario, write this compact decision record before changing files:

Question	Evidence
What must be true when finished?	Requirement and observable acceptance check
Which root module, backend, workspace, and provider identity apply?	Configuration plus CLI/provider inspection
Which addresses and remote objects are involved?	Plan and state inspection
Is this create/change, import, refactor, drift acceptance, or management removal?	Lifecycle classification
What can be replaced or destroyed?	Plan replacement paths and lifecycle rules
How will the change be verified?	Terraform output/state plus provider observation
How will partial failure be recovered?	State backup, new plan, remote repair, escalation boundary

This record prevents the most common category error: using a correct command for the wrong lifecycle intention.

Worked authoring and operations decisions¶

Preserve identity through a module migration¶

Suppose two built-in resources at terraform_data.service[0] and [1] represent api and worker. The new child module uses for_each keys with those names. Record both transitions explicitly:

moved {
  from = terraform_data.service[0]
  to   = module.services.terraform_data.service["api"]
}
moved {
  from = terraform_data.service[1]
  to   = module.services.terraform_data.service["worker"]
}

The local Terraform 1.6.6 adaptation of Lab 2 produced two no-op resource actions with previous addresses; apply preserved both IDs. Inspect every attribute too: a move records identity, not permission to ignore unrelated changes. The refactoring guide explains upgrade paths and why removing old move declarations can break callers who skip releases.

Test an input contract before applying¶

For a local adaptation of Lab 3, put this in a child module's main.tf. It records names; it does not open network ports:

variable "services" {
  type = map(object({ port = number }))
  validation {
    condition     = alltrue([for s in var.services : s.port >= 1 && s.port <= 65535 && floor(s.port) == s.port])
    error_message = "Ports must be whole numbers from 1 through 65535."
  }
}
resource "terraform_data" "service" {
  for_each = var.services
  input    = each.key
}
output "ports" {
  value = { for name, service in var.services : name => service.port }
}

Put these original checks in that module's tests/ports.tftest.hcl, then run terraform init and terraform test from the child module directory:

run "valid_port" {
  command = plan
  variables {
    services = { api = { port = 443 } }
  }
  assert {
    condition     = output.ports["api"] == 443
    error_message = "The port mapping must preserve the caller's value."
  }
}
run "invalid_port" {
  command = plan
  variables {
    services = { api = { port = 0 } }
  }
  expect_failures = [var.services]
}
run "upper_boundary" {
  command = plan
  variables {
    services = { api = { port = 65535 } }
  }
  assert {
    condition     = output.ports["api"] == 65535
    error_message = "The maximum valid port must be accepted."
  }
}

All three runs passed on Terraform 1.6.6. The test reference explains that tests default to apply; explicitly selecting plan avoids creating resources for these assertions. Plan-based tests can still contact providers/data sources in other configurations. expect_failures targets custom-condition failures, not arbitrary type/API errors. Always inspect cleanup output after tests that create real infrastructure.

Separate an access problem from a quiet plan¶

An application team needs one published endpoint but the shared state contains credentials. Giving it snapshot access for terraform_remote_state grants more exposure than that one output suggests. Choose an output-sharing or configuration-publication mechanism with the required access boundary, then test both permitted access and denied secret access. This is a design case, not a live HCP permission result.

Choose an enforcement stage¶

An external scanner is advisory at post-plan and reports a failure. A green apply does not establish policy compliance: advisory behavior deliberately allows continuation. A required preventive check needs an appropriate pre-apply stage and mandatory behavior, with explicit exception ownership. A post-apply failure supports detection/remediation rather than retroactive prevention. This scenario was reviewed against documentation, not executed in HCP.

Useful article with a version boundary¶

Dan Barr's October 4, 2023 Terraform 1.6 testing article explains the native test framework and saved cloud-plan workflow. Use it to design valid, invalid and boundary cases; compare its historical Terraform Cloud terminology with current HCP documentation. Allow about 20–35 minutes for reading and the local test exercise. The release article's cloud workflows were not executed here, and newer test syntax must be checked against the 1.6 baseline.

Hands-on labs¶

Execution evidence, September 28, 2026: Local adaptations of Labs 2–3 ran on checksum-verified Terraform 1.6.6 with the built-in provider: both moved IDs were preserved, all three native tests passed, and cleanup left empty managed state. These Windows CLI checks do not establish Linux exam-environment fluency or cloud/HCP correctness. Other labs remain proposed.

Use disposable personal sandboxes only. Review cost and destroy resources when complete. Never use employer, customer, shared, or production credentials without explicit authorization.

Lab 1: Import and normalize an existing object¶

Create a small resource manually in an approved sandbox. Write matching Terraform configuration and an import block. Predict the target address, run a plan, apply the import, then iterate configuration until the full plan is intentionally quiet. Record which remote defaults had to be represented and which arguments would force replacement.

Lab 2: Refactor indexed resources into modules¶

Start with two count-based resources in a root module. Refactor them to for_each with stable keys and move them into a child module. First capture the destructive plan without applying. Add precise moved blocks, plan again, and prove that remote objects are preserved. Test an upgrade from the original state rather than only a fresh deployment.

Lab 3: Build and test a dynamic module¶

Create a module accepting a map(object(...)). Use a filtered for expression, for_each, typed validation, a precondition, and a useful output. Add terraform test cases for valid input, invalid input, and a boundary condition. Use terraform console to explain each intermediate collection shape.

Lab 4: Operate remote state through automation¶

Configure a disposable remote backend that supports locking and recovery. Build a pipeline that formats, validates, plans, preserves review evidence, and applies only an approved revision. Attempt two concurrent operations safely to observe locking. Document credential injection, state access, artifact retention, and recovery.

Lab 5: Diagnose provider identity and aliases¶

Configure two provider aliases targeting distinct disposable regions or accounts. Pass them explicitly to a child module. Introduce one error at a time: missing alias mapping, wrong region, expired credential, insufficient permission, and incompatible provider constraint. For each, identify the failure phase and the smallest correction.

Lab 6: Design an HCP Terraform operating model¶

Design projects and workspaces for a shared network and three applications across test and production. Specify state boundaries, VCS/run workflow, team permissions, dynamic credentials, variable sets, policy sets, run tasks, output sharing, failure handling, and audit evidence. Explain why each boundary exists.

Lab 7: Timed unfamiliar-repository drill¶

Clone a disposable Terraform repository you did not author. Give yourself 45 minutes to inspect it, initialize it, identify backend/provider/module assumptions, correct one validation error, correct one lifecycle error, produce a safe plan, and write verification steps. Repeat with a different repository until the process—not the file layout—is familiar.

Knowledge checks¶

Why can terraform init succeed against the wrong operational target? Answer: Initialization checks configuration/backend setup, not whether the selected state and identity represent the intended business environment.
What evidence distinguishes an in-place update from replacement in a plan? Answer: Read the action list and replacement reason/path, exact address and before/after values; a summary count is insufficient.
Why should a targeted plan be followed by a complete plan? Answer: Targeting can omit dependencies or other changes required for full convergence.
What does import change, and what must configuration still prove afterward? Answer: It binds an existing remote ID to an address; configuration must still produce the intended full plan without unwanted change.
When is refresh-only mode an acceptance decision rather than a repair? Answer: When the remote change is accepted as observation; it writes state but does not repair configuration or necessarily change the object.
How does a moved block differ from directly changing state? Answer: A moved block records a repeatable migration in code; a state command changes the current mapping immediately.
Why must for_each keys normally be known during planning? Answer: Terraform must identify instances before scheduling their operations; unknown values can remain in attributes but not unknown instance keys.
When is depends_on justified, and what does overuse cost? Answer: Use it for a hidden behavioral dependency; broad explicit dependencies can defer reads and propagate unknown values.
Contrast sensitive, ephemeral, and write-only data handling. Answer: Sensitive controls display; ephemeral/write-only supported paths omit values from artifacts. The latter are newer than this exam's 1.6 baseline.
What should determine a remote-state boundary? Answer: Lifecycle, ownership, permissions, failure scope, recovery and collaboration needs.
What security concern exists when consuming another configuration's remote state? Answer: The reader of a backing snapshot may retrieve all its data, not just declared outputs.
Which revision, inputs, credentials, and plan should an automated apply bind together? Answer: The approved configuration revision, exact intended inputs, scoped identity, provider selections, state and applicable reviewed plan.
Why is a module that exposes every provider argument often a weak abstraction? Answer: It adds indirection without defining a coherent supported capability or useful safety defaults.
How can module refactoring preserve remote objects? Answer: Map every old instance address to its new destination and verify no unintended replacement and preserved IDs.
Contrast provider requirements, provider configurations, and provider aliases. Answer: Requirements declare source/version; configurations supply target/auth settings; aliases name additional configurations of a plugin.
How do authentication and authorization failures differ? Answer: Authentication establishes identity; authorization decides if that identity may perform the requested operation.
Why is deleting .terraform.lock.hcl a poor first response to provider trouble? Answer: It discards reviewed provider selections and obscures whether the failure was version, checksum, network or schema related.
How does an HCP Terraform workspace differ from a CLI workspace? Answer: HCP adds run history, settings and permissions around a managed state; CLI workspaces primarily select alternate states.
What trust relationship makes dynamic provider credentials work? Answer: A trusted workload token issuer/audience/subject maps a run to a constrained provider role, with appropriate plan/apply permissions.
Which HCP control should own a rule: Terraform condition, policy, run task, or approval—and why? Answer: Choose by scope and enforcement: local condition for an object/input contract, policy for organization rules, task for an external service, approval for authorized judgment.

High-value distinctions¶

Contrast	Remember
Valid configuration vs correct change	Syntax/type consistency vs right target and lifecycle intent
Speculative plan vs saved plan	Proposed review output vs executable reviewed artifact
Import vs create	Bind existing identity vs ask provider to create
Refresh-only vs normal plan	Accept observations into state vs converge remote system to configuration
`moved` block vs state command	Declarative repeatable migration vs immediate administrative surgery
`count` vs `for_each`	Positional identity vs keyed identity
Sensitive vs nonpersisted	Display redaction vs exclusion from state/plan through supported paths
Locking vs ownership	Serialize writers vs decide which configuration/team controls an object
Module interface vs provider wrapper	Supported capability abstraction vs argument passthrough
Provider requirement vs configuration	Plugin source/version contract vs one target/auth instance
Authentication vs authorization	Prove identity vs permit requested action
HCP workspace vs CLI workspace	Managed run/state/access boundary vs alternate local state instance
Policy vs run task	IaC governance evaluation vs external integration/check

Readiness checklist¶

Primary references¶

Places to learn¶

This is a curated starting point, not a complete list, and it is not meant to be consumed in full. Pick the official material, labs, instructor, and review format that fit your gaps. Times are approximate consumption time at normal speed; hands-on repetition, troubleshooting, notes, and prerequisite repair add substantial time.

Resource	Access	Estimated time	Best use and caveat
HashiCorp Advanced learning path	Free; cloud exercises require an authorized sandbox	About 20–35 hours for linked reading and implementation (library estimate; the landing page's four-minute read time excludes linked work)	Authoritative ordered review of all six domains; production repetition remains necessary
Advanced exam content list	Free	About 3–6 hours for an active documentation pass; longer when practicing gaps	Best objective-to-documentation checklist and current provider-version notice
Advanced exam orientation	Free	About 20–40 minutes including notes and environment planning	First-party explanation of prerequisites, lab grading, environment, provider version, and permitted references
HashiCorp Advanced practice labs	Free; interactive labs and cloud-provider access vary	About 4–10 hours across repeated labs (library estimate because HashiCorp publishes only landing-page read time)	Public catalog currently lists AWS EC2 and Azure VM import activities; useful for import practice, not a complete seven-lab course or proof Azure exam booking is open. Repeat and verify state plus remote results
Terraform Associate (004) guide	Free	About 8–14 hours for targeted prerequisite review and selected labs	Repair core workflow, state, module, provider, and HCP gaps before advanced practice; not advanced-level preparation by itself
HashiCorp Terraform tutorials	Free; some exercises require HCP or cloud accounts	About 2–6 hours per selected operational gap	Use narrowly for import, refactoring, testing, automation, state, providers, modules, and HCP Terraform rather than consuming the entire catalog

No current third-party course was included as an exact end-to-end Terraform Authoring and Operations Advanced resource during this review. That is a catalog gap, not a claim that none exists. Evaluate any course against the current AWS/Azure exam-version notice and the official content list before investing substantial time.