004 — HashiCorp Certified: Terraform Associate Scenario Practice Guide

How to read Terraform Associate scenarios

Scenario questions for the HashiCorp Certified: Terraform Associate (004) exam usually ask you to apply Terraform concepts in a practical situation: a team is provisioning infrastructure, a state file is shared, a provider has changed, a resource already exists, a module needs to be reused, or a workflow step is missing.

Your job is not to memorize a sentence and match it to an answer. Your job is to identify the decision point:

• What is the current Terraform environment?
• What is the user trying to accomplish?
• What part of Terraform is involved: configuration, provider, module, state, backend, workspace, CLI workflow, or HCP Terraform?
• What constraint makes one answer better than another?
• Which option preserves Terraform’s model of desired state, tracked state, and real infrastructure?

Use the scenario facts to choose the most defensible Terraform-native action.

Start with the Terraform mental model

Before reading answer choices, anchor the scenario to Terraform’s basic flow:

1. Configuration describes desired infrastructure.
2. Providers translate Terraform configuration into API operations.
3. terraform init prepares the working directory, providers, modules, and backend.
4. terraform plan compares configuration, state, and real infrastructure to propose changes.
5. terraform apply makes approved changes.
6. State tracks the mapping between Terraform resource addresses and real infrastructure objects.

Many scenario questions become easier when you ask: “Which part of this model is out of sync or needs to be changed?”

Configuration, state, and real infrastructure are different things

Keep these three layers separate:

• Configuration is what Terraform should manage.
• State is Terraform’s record of what it manages.
• Real infrastructure is what exists in the target platform.

A strong answer usually keeps these layers consistent. For example, if an object already exists and Terraform must manage it, the reasoning is not “create it again.” The reasoning is: represent it in configuration, associate it with state through import, then use plan to confirm the result.

Read the last sentence first

The final sentence often reveals what the question is actually asking. Before studying every detail, identify the requested answer type:

• A CLI command, such as terraform init, terraform plan, terraform apply, terraform import, or a state command
• A configuration construct, such as a variable, output, data source, module, provider alias, or lifecycle rule
• A workflow decision, such as when to run plan, how to collaborate on state, or how to safely review changes
• A state or backend decision, such as remote state, locking, migration, or import
• A security decision, such as protecting credentials, restricting state access, or marking sensitive values

This prevents you from solving the wrong problem. A scenario may mention modules, variables, providers, and workspaces, but the actual question may only ask which command initializes a new module dependency.

Identify the environment

Terraform scenarios often include environment clues that determine the correct answer.

Look for:

• Local CLI or remote workflow: Is the user running Terraform locally, or is the team using HCP Terraform / Terraform Cloud style remote runs?
• Single user or team: Collaboration usually raises state sharing, locking, permissions, and consistent runs.
• Existing or new infrastructure: Existing unmanaged resources suggest import. New infrastructure suggests normal configuration, plan, and apply.
• One environment or multiple environments: Separate environments may require separate state, workspaces, separate root modules, or different variable values.
• One provider configuration or several: Multiple regions, accounts, or subscriptions may require provider aliases.
• Root module or child module: A reusable module behaves differently from the root configuration that calls it.
• Local state or remote backend: Shared work usually favors remote state with appropriate access control and locking.

Do not assume the environment. Use only the facts given.

Find the symptom or goal

After identifying the environment, name the scenario’s main goal in plain language.

Common Terraform goals include:

• “Initialize this configuration.”
• “Preview what Terraform will change.”
• “Apply approved infrastructure changes.”
• “Bring an existing resource under Terraform management.”
• “Avoid recreating a resource during a refactor.”
• “Reuse configuration across projects.”
• “Pass values into a module.”
• “Expose a value from a module.”
• “Use separate provider configurations.”
• “Share state safely across a team.”
• “Prevent secrets from appearing in command output.”
• “Understand why a plan shows replacement or drift.”

Once you can state the goal in one sentence, the answer choices become easier to compare.

Match the goal to the Terraform layer

Terraform questions become harder when the answer choices operate at different layers. Choose the layer that actually solves the problem.

Use this kind of mapping before choosing an answer.

Interpret Terraform CLI scenarios

Many exam scenarios are about choosing the correct command at the correct stage.

Initialization decisions

Choose terraform init when the scenario says or implies:

• A working directory has not been initialized.
• A backend has been configured or changed.
• Provider plugins need to be installed.
• Module sources need to be downloaded.
• The dependency lock file or provider selections need to be established.
• A provider version constraint has changed and Terraform must install an allowed version.

If a scenario says providers or modules were added and Terraform fails before planning, initialization is a strong candidate.

Formatting, validation, planning, and applying

Separate these commands by purpose:

• terraform fmt formats configuration files.
• terraform validate checks whether the configuration is syntactically valid and internally consistent.
• terraform plan previews proposed infrastructure changes.
• terraform apply executes approved changes.
• terraform destroy removes managed infrastructure when destruction is intended.

If the requirement is “see what will happen,” choose plan. If the requirement is “make the changes,” choose apply. If the requirement is “check configuration before running,” validate may be the better fit.

State inspection and state changes

State commands are for Terraform’s record of managed objects. They are not normal infrastructure provisioning commands.

Use state-related reasoning when the scenario mentions:

• Inspecting resources tracked in state
• Moving a resource address without changing the real object
• Removing an object from Terraform state without destroying the object
• Reconciling Terraform’s state with an existing object
• Avoiding recreation after a refactor

Examples:

• Use state inspection commands when the question asks what Terraform currently tracks.
• Use import when an existing real resource needs to become Terraform-managed.
• Use a moved block or state move operation when the Terraform address changes but the underlying object should remain associated.

Be careful not to choose state manipulation when the real solution is to update configuration and run plan.

Separate constraints from preferences

Scenario wording often includes constraints that decide the answer.

Strong constraints include:

• “Must not recreate the resource”
• “Must avoid downtime”
• “Must be reusable by multiple teams”
• “Must not expose secrets”
• “Must support collaboration”
• “Must use least privilege”
• “Must preserve the existing infrastructure”
• “Must review changes before making them”
• “Must manage resources in two regions/accounts”

A preference is weaker, such as “the team would like a simpler workflow.” A hard constraint can make a technically valid option wrong. For example, if the scenario says a database must not be destroyed, an answer that causes replacement is less defensible than an answer that preserves the resource or adds a lifecycle guard when appropriate.

Choose the least disruptive Terraform-native action

Terraform Associate scenarios often reward the option that changes the minimum necessary thing while keeping Terraform’s model intact.

Use this order of thought:

1. Can the goal be achieved by changing configuration?
2. Does Terraform need to be initialized before it can evaluate the configuration?
3. Is the next safe step to run a plan?
4. Is state out of sync with configuration or real infrastructure?
5. Does the scenario require import, state movement, or a moved block?
6. Is there a collaboration, backend, or security requirement?
7. Does the answer preserve the resource and avoid unnecessary manual changes?

The best answer is usually not the most dramatic action. For example, if the task is to preview a change, applying directly is too aggressive. If the task is to manage an existing resource, recreating it is too disruptive.

Reason through state and backend scenarios

State is central to Terraform reasoning. Scenario questions may test whether you understand what state is for and how teams should handle it.

State tracks managed infrastructure

Terraform state maps resource addresses, such as aws_instance.web, to real infrastructure objects. If Terraform does not know about an object in state, it does not manage that object, even if a matching resource block exists in configuration.

When a scenario says an object already exists outside Terraform, look for an import-based answer.

Remote state supports collaboration

For team scenarios, ask:

• Where is the state stored?
• Can multiple users safely access it?
• Is locking available to prevent simultaneous changes?
• Is access to state restricted?
• Are sensitive values protected?

Committing local state files to a shared repository is generally not the collaboration model Terraform is designed for. A remote backend or HCP Terraform-style workflow is usually more defensible when the scenario emphasizes shared operations.

State may contain sensitive data

Marking a variable or output as sensitive can reduce exposure in CLI output, but it does not mean the value cannot appear in state. If the scenario asks how to protect secrets, include state protection in your reasoning:

• Avoid hard-coding secrets in configuration.
• Use appropriate secret injection methods, such as environment variables or secure variable storage where applicable.
• Restrict access to state.
• Use a backend with suitable security controls.
• Mark sensitive variables and outputs when the display of values should be suppressed.

A complete security answer considers both display and storage.

Match Terraform constructs to requirements

Many scenarios ask which Terraform construct best fits a requirement. Translate the requirement into the construct’s purpose.

Resources

Use a resource block when Terraform should create, update, or delete an infrastructure object.

Decision cue: “Terraform should manage the lifecycle of this object.”

Data sources

Use a data source when Terraform needs to read information about something that already exists but should not manage its lifecycle.

Decision cue: “Look up an existing value and use it in configuration.”

Input variables

Use input variables to parameterize a module or root configuration.

Decision cue: “The value should be supplied by the caller, environment, workspace, or variable file.”

Local values

Use locals for derived expressions used inside the module.

Decision cue: “This value is calculated once for readability or reuse, but callers should not set it directly.”

Outputs

Use outputs to expose values from a module or root configuration.

Decision cue: “Another module, user, automation step, or remote state consumer needs this result.”

Modules

Use modules to package reusable Terraform configuration.

Decision cue: “The same infrastructure pattern should be reused consistently.”

For public or private registry modules, versioning matters. If the scenario emphasizes stable reuse, look for answers that pin or constrain module versions rather than pulling unspecified changes.

Provider aliases

Use provider aliases when the same provider needs multiple configurations, such as multiple regions, accounts, or subscriptions.

Decision cue: “The same provider type must connect to different targets.”

Workspaces

Use workspaces when the same configuration needs separate state instances. Read the scenario carefully. Workspaces separate state, but they are not automatically a full environment strategy by themselves. If the scenario requires separate credentials, access boundaries, or independent configurations, the best answer may involve more than simply switching workspaces.

Read provider and dependency details carefully

Provider scenarios often include version, source, lock file, and initialization clues.

Use this reasoning:

• required_providers declares provider source and version constraints.
• terraform init installs providers that satisfy the constraints.
• .terraform.lock.hcl records selected dependency versions for repeatable installs.
• terraform init -upgrade is relevant when the goal is to select newer allowed provider versions.
• Provider aliases are for multiple provider configurations, not just for naming style.

If the scenario says a team wants predictable provider installation, the lock file and version constraints matter. If it says Terraform cannot find or install the provider after a configuration change, initialization may be the missing step.

Interpret module scenarios

Module scenarios usually test one of four decisions.

Calling a module

If the scenario says a team wants to reuse a set of Terraform resources, the answer likely involves a module block with an appropriate source.

Passing values into a module

If the child module needs input, use variables in the child module and pass arguments from the calling module.

Getting values out of a module

If the root module or another process needs a value created inside a module, expose it as an output.

Versioning a module

If the module comes from a registry and the scenario requires stable, repeatable use, look for version constraints or version pinning appropriate to the module source.

Do not solve a module reuse problem by copying and pasting resources unless the scenario specifically asks for a one-off configuration with no reuse requirement.

Interpret lifecycle and dependency scenarios

Terraform normally infers dependencies from references. If one resource refers to another, Terraform can usually determine the order.

Choose explicit dependency controls only when the facts justify them.

Implicit dependencies

If a resource uses an attribute from another resource, Terraform has an implicit dependency.

Decision cue: “The dependency is already expressed by a reference.”

depends_on

Use depends_on when Terraform cannot infer the dependency from expressions, but a real dependency still exists.

Decision cue: “There is an ordering requirement without a direct reference.”

Lifecycle rules

Lifecycle rules should match a specific constraint:

• create_before_destroy can help when replacement should minimize downtime and the platform supports overlapping objects.
• prevent_destroy helps guard against accidental destruction.
• ignore_changes can be appropriate when a specific attribute is intentionally managed outside Terraform.

Avoid choosing lifecycle rules as a generic fix. They are best when the scenario gives a clear reason.

Security and least privilege reasoning

Security scenarios for Terraform are usually about reducing exposure and controlling access, not just hiding a value in one screen.

Ask:

• Are provider credentials hard-coded or supplied securely?
• Does the provider need broad permissions, or only the permissions required for the managed resources?
• Could sensitive values appear in state?
• Is state access restricted?
• Are variables or outputs marked sensitive when they should not be displayed?
• Is the team using a remote workflow or backend that supports access controls?

When answer choices include both a display-only protection and a storage/access protection, prefer the answer that addresses the actual risk described.

Working through short Terraform scenario examples

Example 1: Existing resource must be managed

A team created a storage bucket manually. They now want Terraform to manage it without deleting and recreating it.

Reasoning:

• The bucket exists outside Terraform.
• Terraform needs configuration for the desired resource.
• Terraform state must be associated with the existing object.
• The answer should avoid recreation.

Most defensible direction: add appropriate configuration, import the existing object into Terraform state, then run plan to verify.

Example 2: Provider was added and planning fails

A developer adds a new provider requirement and resource block. Running plan fails because the provider is not installed.

Reasoning:

• The configuration changed.
• The working directory needs provider installation.
• This happens before planning.

Most defensible direction: run terraform init, then plan again.

Example 3: Team needs shared state and locking

Several engineers run Terraform for the same infrastructure. They need to avoid simultaneous applies and keep a shared record of managed objects.

Reasoning:

• This is a collaboration scenario.
• Local state on one laptop is not enough.
• Locking and controlled access matter.

Most defensible direction: use a suitable remote backend or HCP Terraform-style workflow that supports shared state, locking, and access control.

Example 4: Same provider, two regions

A configuration must create resources in two regions using the same cloud provider.

Reasoning:

• The provider type is the same.
• The provider configuration differs.
• Resources must be associated with the correct provider configuration.

Most defensible direction: use provider aliases and pass the correct provider configuration to resources or modules.

Example 5: Secret value should not be displayed

A variable contains a password, and the team does not want it printed in CLI output.

Reasoning:

• Marking the variable sensitive can suppress display.
• State may still contain sensitive data.
• Storage and access controls are still required.

Most defensible direction: mark the value sensitive where appropriate and protect how the value is supplied and how state is stored.

Example 6: Resource address changed during refactor

A resource block is moved into a module, but the real infrastructure should remain unchanged.

Reasoning:

• The resource should not be destroyed and recreated.
• The Terraform address changes.
• State mapping must be preserved.

Most defensible direction: use a moved block or appropriate state movement approach so Terraform understands the address change.

Example 7: Need many similar resources with stable identity

A team needs to create resources for a set of named environments, and each resource should stay associated with its name even if another name is added later.

Reasoning:

• The resources are similar.
• Each instance has a meaningful key.
• Stable addressing matters.

Most defensible direction: use for_each with stable keys when the collection is naturally keyed.

How to evaluate answer choices

After reading the scenario, test each option with these questions:

• Does this answer operate at the right layer: configuration, state, backend, provider, or workflow?
• Does it preserve consistency between configuration, state, and real infrastructure?
• Does it satisfy the stated constraint?
• Is it the least disruptive safe action?
• Does it use Terraform’s normal workflow instead of manual changes?
• Does it protect state and secrets if security is part of the scenario?
• Does it support collaboration if multiple users or teams are involved?
• Does it answer the actual question asked, not merely a related issue?

If two answers seem plausible, prefer the one that directly resolves the decision point with fewer side effects.

Compact scenario checklist for final review

Use this checklist during Terraform scenario practice:

• Read the final sentence first.
• Identify whether the answer should be a command, construct, workflow, or platform feature.
• Name the current state: uninitialized, planned, applied, drifted, imported, remote, local, shared, or unmanaged.
• Separate configuration, state, and real infrastructure.
• Look for hard constraints: no downtime, no recreation, secure secrets, team collaboration, least privilege.
• Match the command to the workflow stage.
• Use import for existing unmanaged resources.
• Use modules for reusable configuration.
• Use data sources for lookup-only needs.
• Use outputs to expose values.
• Use provider aliases for multiple provider configurations.
• Protect state when sensitive values are involved.
• Prefer plan before apply when the scenario asks for review or safety.
• Choose the answer that changes the least while keeping Terraform accurate.

Practice next step

For final review, practice scenario questions in small sets by topic: CLI workflow, state and backends, providers, modules, variables and outputs, security, and HCP Terraform collaboration. After each set, write one sentence explaining the decision point before checking the answer. Then use a full mock exam to practice applying the same reasoning under time pressure.