SaveMyCert
Log in
5 of 5 free questions left today·for 10 a day
Terraform Pro 002 · Domain 3

Infrastructure lifecycle and operations practice questions

Infrastructure lifecycle and operations is worth 22% of the Terraform Pro 002 exam — the heaviest of the 7 domains. Structuring and scaling projects, planning and applying changes, importing existing infrastructure, lifecycle management, multiple environments, troubleshooting, passing data and managing versions. Weight approximates the sub-objective share. 6 fully worked examples are further down this page, answers included.

Exam weight
22%
the heaviest of the 7 domains
Questions
175
across 5 topics
Free, no account
5/day
a free account allows 10 a day
Explanations
Every option
right and wrong

Build a practice session

5 free questions left today.

Domains

How many?

Mode

Ready when you are

10 fresh questions drawn across 1 of 7 domains, in Learn mode.

Review what you missed

Every question you answer incorrectly, and every question you flag while practising, is saved here automatically. Finish a session and you can come back to re-drill just those.

6 sample Infrastructure lifecycle and operations questions, fully explained

Questions from the Terraform Pro 002 bank mapped to domain 3, with the answer key and the reasoning behind every option. None of them repeat the examples on the main Terraform Pro 002 practice page.

Question 1Infrastructure lifecycle and operations

A developer wants to stand up a temporary, parallel copy of the team's staging infrastructure to test a feature branch, using the same configuration, backend and credentials, and to tear it down afterwards. Which approach does HashiCorp describe for this?

Choose one.

  • a
    Copy the staging root module into a new directory with its own backend block

    This works but adds a new backend and a second copy of the code for a short-lived test, which the requirement to reuse the same backend rules out.

  • b
    Pull the staging state into a local file and apply the branch against that copy

    The copied state still points at the real staging objects, so the branch apply would change staging instead of creating a copy.

  • c
    Run the branch's plan and apply with -target on the changed staging resources

    -target still operates on staging's own state and objects; it creates no parallel copy and is meant for exceptional use only.

  • d
    Create a CLI workspace for the branch; destroy and delete it after testing Correct

    Creating a parallel, distinct copy of a set of infrastructure to test changes is the documented use case for CLI workspaces.

The concept

A CLI workspace is a separate state for the same configuration and backend, which makes it a cheap way to create a parallel copy of infrastructure.

Why that’s the answer

HashiCorp's stated use case for multiple workspaces is creating a parallel, distinct copy of a set of infrastructure to test changes before touching the main deployment. A new workspace starts with empty state, so apply creates a second set of objects; destroy and workspace delete remove it. Copying state would bind the branch to the real staging objects, and -target still acts on staging itself.

How to reason it out
  1. Note the need: a temporary copy, same configuration, backend and credentials.
  2. Recall that a new workspace has empty state, so apply creates new objects.
  3. Clean up with destroy, then delete the workspace.

Exam tip: Short-lived parallel copy of the same infrastructure: a CLI workspace.

Terraform Professional: Scaling Projects and Multiple Environments — the lesson that teaches this.

Question 2Infrastructure lifecycle and operations

A CI job for each pull request runs terraform workspace select pr-142 and then terraform plan. The job fails on the first run of every new pull request because the workspace does not exist yet, but later runs must reuse the same workspace. Which command should replace the select step?

Choose one.

  • a
    terraform workspace select -or-create pr-142 Correct

    -or-create selects the workspace when it exists and creates it when it does not, so the same step works on first and later runs.

  • b
    terraform workspace new pr-142

    new creates the workspace on the first run but errors on later runs because pr-142 already exists.

  • c
    terraform workspace new -lock-timeout=60s pr-142

    -lock-timeout only retries a state lock; new still errors when the workspace already exists.

  • d
    terraform init, then terraform workspace select pr-142

    Running init first does not create the named workspace, so select still fails on the first run.

The concept

terraform workspace select requires an existing workspace unless -or-create is given.

Why that’s the answer

workspace select fails when the named workspace is missing; its -or-create flag (default false) creates it in that case. workspace new has the opposite problem: it fails whenever the workspace already exists, and -lock-timeout does not change that. Running init first does not create workspaces.

How to reason it out
  1. Note the two cases: workspace missing on the first run, present afterwards.
  2. Recall that select needs an existing workspace and new needs a missing one.
  3. Use select -or-create, which handles both.

Exam tip: In automation, terraform workspace select -or-create NAME is idempotent.

Terraform Professional: Scaling Projects and Multiple Environments — the lesson that teaches this.

Question 3Infrastructure lifecycle and operations

After a pull request merges, a cleanup job runs terraform workspace delete pr-142, and Terraform refuses to delete the workspace. Which two conditions cause this refusal? (Select TWO.)

Choose TWO.

  • a
    pr-142 was created by select -or-create rather than by workspace new

    How the workspace was created does not matter; both create an ordinary workspace.

  • b
    another configuration reads pr-142's outputs with terraform_remote_state

    Terraform does not track which configurations read a state's outputs, so this does not block deletion.

  • c
    the S3 backend for the workspace has use_lockfile enabled

    State locking guards concurrent operations; enabling it does not prevent deleting a workspace.

  • d
    pr-142 is the workspace currently selected in that working directory Correct

    A workspace cannot be deleted while it is the current workspace; the job has to select another one (for example default) first.

  • e
    pr-142's state still tracks resources and the -force flag was not used Correct

    delete refuses a workspace that is tracking resources unless -force is given, because those objects would no longer be managed.

The concept

terraform workspace delete requires the workspace to be non-current and, without -force, to track no resources.

Why that’s the answer

The delete command has two safety rules: the target must not be your current workspace, and it must not be tracking resources. -force overrides the second rule but leaves the real objects unmanaged, so the clean sequence is destroy in pr-142, select default, then delete pr-142. Creation method, remote-state readers and locking have no effect on deletion.

How to reason it out
  1. Recall the current-workspace rule for delete.
  2. Recall the tracked-resources rule and what -force does.
  3. Order the cleanup: destroy, select another workspace, delete.

Exam tip: Before workspace delete: destroy its resources and switch away from it.

Terraform Professional: Scaling Projects and Multiple Environments — the lesson that teaches this.

Question 4Infrastructure lifecycle and operations

An engineer clones a repository, runs terraform init and terraform apply, and never creates or selects a workspace. The configuration contains the block below. What bucket name does Terraform use?resource "aws_s3_bucket" "logs" { bucket = "acme-logs-${terraform.workspace}" }

Choose one.

  • a
    acme-logs-

    terraform.workspace is never empty; it returns the current workspace name, which is default here.

  • b
    acme-logs-default Correct

    Every working directory starts in the workspace named default, so terraform.workspace returns "default".

  • c
    acme-logs-main

    Workspace names are not taken from the Git branch; the starting workspace is called default.

  • d
    acme-logs-workspace

    The expression is replaced by the current workspace's name, not by the literal word workspace.

The concept

terraform.workspace returns the name of the current CLI workspace, and every working directory starts in the workspace named default.

Why that’s the answer

Terraform starts with a single workspace named default that cannot be deleted. Because no other workspace was created or selected, the interpolation produces acme-logs-default. The Git branch has no effect on the workspace name.

How to reason it out
  1. Recall the starting workspace name.
  2. Substitute it into the interpolation.

Exam tip: No workspace selected means terraform.workspace is "default".

Terraform Professional: Scaling Projects and Multiple Environments — the lesson that teaches this.

Question 5Infrastructure lifecycle and operations

A configuration sizes instances per workspace as shown. A developer runs terraform workspace new feature-x and then terraform plan. What happens?locals { sizes = { dev = "t3.small", prod = "m6i.large" } } resource "aws_instance" "app" { instance_type = local.sizes[terraform.workspace] # other arguments omitted }

Choose one.

  • a
    The plan sets instance_type to null and the provider default applies

    A missing map key does not return null; the index expression itself fails.

  • b
    The plan uses the first map element, so instance_type is t3.small

    Terraform does not fall back to any element for a missing key; that would need lookup() with a default.

  • c
    The plan fails with an invalid index error for the key "feature-x" Correct

    Indexing a map with a key it does not contain is an error, and feature-x is not a key of local.sizes.

  • d
    The plan reuses the value from the default workspace's last apply

    Expressions are evaluated per run from configuration; workspaces do not inherit values from one another.

The concept

Indexing a map with a missing key is an error; per-workspace maps need a fallback such as lookup(map, key, default) for unexpected workspace names.

Why that’s the answer

terraform.workspace returns feature-x, which is not a key of local.sizes, so the index expression fails during plan. Terraform never substitutes null or another element. Writing lookup(local.sizes, terraform.workspace, "t3.small") gives ad-hoc workspaces a safe default.

How to reason it out
  1. Evaluate terraform.workspace: feature-x.
  2. Check whether the map has that key.
  3. Recall that a missing key in an index expression is an error, unlike lookup() with a default.

Exam tip: Per-workspace maps: use lookup() with a default, or ad-hoc workspaces fail to plan.

Terraform Professional: Scaling Projects and Multiple Environments — the lesson that teaches this.

Question 6Infrastructure lifecycle and operations

A pipeline deploys one configuration to the staging and prod CLI workspaces in separate jobs. Each job runs in a fresh container, and the team wants every terraform command in a job to target that job's workspace without relying on state left behind by an earlier select step. What does Terraform recommend for this non-interactive case?

Choose one.

  • a
    Write the workspace name into the .terraform/environment file

    That file is Terraform's internal record of the selected workspace; hand-editing internal data is fragile compared with the documented variable.

  • b
    Pass -var="workspace=staging" and use var.workspace in the backend

    Backend blocks cannot use input variables, and an input variable does not select a CLI workspace anyway.

  • c
    Set the TF_WORKSPACE environment variable to the job's workspace Correct

    TF_WORKSPACE selects the workspace for every command in that environment and is the documented approach for non-interactive use.

  • d
    Run terraform workspace select in an earlier pipeline stage

    The selection is stored in the working directory, so a fresh container in the next stage does not have it.

The concept

TF_WORKSPACE selects the CLI workspace for a process environment and is recommended only for non-interactive usage.

Why that’s the answer

Setting TF_WORKSPACE in the job's environment makes init, plan and apply all use that workspace with no separate select step. HashiCorp recommends it only for non-interactive use, because in an interactive shell it is easy to forget it is set. A select in another stage is lost when the container changes, and backends cannot read input variables.

How to reason it out
  1. Note that each job runs in a fresh container.
  2. Recall where a select is stored: the working directory.
  3. Choose the job-scoped environment variable that selects the workspace.

Exam tip: Pipelines select CLI workspaces with TF_WORKSPACE; interactive shells should use workspace select.

Terraform Professional: Scaling Projects and Multiple Environments — the lesson that teaches this.

What Terraform Pro 002 domain 3 tests, topic by topic

The official exam guide breaks Infrastructure lifecycle and operations into 5 topics. The question bank follows the same split, so a weak topic shows up as a cluster of misses you can go back and read.

Published Terraform Pro 002 practice questions per topic in Infrastructure lifecycle and operations
TopicWhat it coversQuestions
Scaling projects and multiple environmentsOfficial Terraform Infrastructure Engineer Professional (002) objectives, 3a Manage and scale infrastructure projects; 3f Manage multiple infrastructure environments.35
Planning and applying changesOfficial Terraform Infrastructure Engineer Professional (002) objectives, 3b Plan changes to infrastructure; 3c Apply changes to infrastructure.35
Importing infrastructure and managing its lifecycleOfficial Terraform Infrastructure Engineer Professional (002) objectives, 3d Import existing infrastructure to an infrastructure project; 3e Manage infrastructure lifecycle.35
Troubleshooting deployment issuesOfficial Terraform Infrastructure Engineer Professional (002) objectives, 3g Troubleshoot deployment issues.35
Data between projects and provider/module versionsOfficial Terraform Infrastructure Engineer Professional (002) objectives, 3h Input and output data from infrastructure projects; 3i Manage provider and module versions.35
Total175

Revise Infrastructure lifecycle and operations before you drill it

Terraform Professional: Scaling Projects and Multiple EnvironmentsExpect production scenarios that state an isolation, ownership or automation constraint and ask which environment layout or command meets it with the least restructuring: separate credentials or state storage versus a temporary test copy, a per-pull-request workspace that must be created once and reused, a cleanup job whose workspace delete is refused, a pipeline that must target a workspace without relying on an earlier select, a shared runner whose parallel jobs read the wrong state, or a module release that must reach dev before prod. Short HCL snippets in the stem test terraform.workspace interpolation and map indexing, Stacks deployment groups and auto-approve checks, and module wiring that fails on a first plan. Other items cover when to split a monolithic configuration, what routine -target hides, setting -parallelism through environment variables in a template you cannot edit or on HCP Terraform agents, retiring a Stack deployment, and HCP Terraform project scoping, priority variable sets, tag inheritance and project deletion. Several are Select TWO.Terraform Professional: Planning and Applying Infrastructure ChangesExpect production scenarios decided by a stated constraint: the apply must match the reviewed plan exactly, no concurrent state writes, a plan file must move between CI runners, secrets must not leak, or the workspace is VCS-driven. Many items show a plan excerpt, a JSON field or a short shell script and ask what Terraform will do, which flag fits, or which option is accepted with a saved plan. Wrong options are usually real flags and commands that solve a neighbouring problem, so know what each one does and does not do; some items ask you to select two correct statements.Terraform Professional: Importing Infrastructure and Managing Its LifecycleExpect production scenarios decided by a stated constraint: imports must appear in a reviewed plan before state changes, nothing may be destroyed or recreated, the team must not own another team's object, state commands are forbidden, callers may only bump a module version, or protection must apply in production only. Many items show a short block of HCL and ask for the exact import address, id expression, lifecycle content or moved block, so practise writing addresses for modules, count and for_each. Be clear on how neighbouring features differ: removed versus moved blocks, data sources versus imports, depends_on versus replace_triggered_by, and plan versus query configuration generation. Some items ask you to select two correct statements.Terraform Professional: Troubleshooting Deployment Issues with Logs, Validation, Locks and State RecoveryExpect production scenarios built around a quoted error message, a short log or lock file excerpt, or a pipeline description, with one stated constraint deciding the answer: the CI runner has no credentials, checksum verification must stay on, the lock file must stay authoritative, the existing object must keep running, or the recovery must take the fewest operations. The skills tested are classifying an error by layer, knowing exactly what each logging variable, init option and recovery command does and does not change, ordering removals and destroy-time changes correctly, and knowing what terraform validate can and cannot detect. Several items ask you to select two statements.Terraform Professional: Sharing Data Between Projects and Managing Provider and Module VersionsExpect production scenarios decided by one stated constraint: consumers may not read the producer's state, the solution must survive a project split or backend migration, a value must stay visible in plans while a secret stays redacted, every upgrade must be reviewed, or checksum verification must stay on across operating systems. Items often show a short terraform output or jq command, a version constraint with a list of available releases, or a module source string and ask what Terraform does or which variant works. Wrong options are real commands, flags and data sources that solve a neighbouring problem, and several items ask you to select two statements.

Other Terraform Pro 002 domains

Domain 1: Scalable Terraform configuration design20% of the exam · 160 questionsDomain 2: Terraform state and backend operations13% of the exam · 105 questionsDomain 4: CI/CD and automation workflows10% of the exam · 79 questionsDomain 5: Terraform security and governance13% of the exam · 98 questionsDomain 6: Advanced module usage and registry practices10% of the exam · 80 questionsDomain 7: HCP Terraform and Terraform Enterprise operations12% of the exam · 96 questionsAll Terraform Pro 002 practice questionsMixed sessions across all 7 domains — the way the real exam interleaves them.

Infrastructure lifecycle and operations: your questions

Infrastructure lifecycle and operations is domain 3 of the Terraform Pro 002 exam guide and carries 22% of the scored content — the heaviest of the 7 domains. HashiCorp has not yet published the exam's question count, so there is no per-domain number of questions to give.

Source

The domain weight and topic list on this page come from the official Terraform Pro 002 exam guide.