Terraform Pro 002 sample questions — 25 answered and explained

Ephemeral input variables (Terraform 1.10 and later) are available during the run but omitted from plan and state files.

A saved plan records the values of input variables so apply can reproduce them. Marking the variable ephemeral tells Terraform to keep the value out of plan and state files; it must then be supplied again at apply time. Provider configuration is an allowed place to reference an ephemeral variable. Sensitive only hides display, and the method of supplying a value does not change what the plan stores.

1. Identify the artefact to protect: the saved plan file.
2. Recall that saved plans store variable values unless they are ephemeral.
3. Confirm the token is used in an allowed ephemeral context: a provider block.
4. Reject display-only or delivery-only changes.

Exam tip: Use ephemeral = true when a variable's value must stay out of plan and state files.

Ephemeral outputs exist to pass ephemeral values from a child module to its caller; root module outputs cannot be ephemeral.

Root outputs are persisted in state so they can be read later by terraform output or remote state consumers, which contradicts ephemerality. Terraform therefore rejects ephemeral = true on root module outputs and allows it only in child modules. A value that a later pipeline step needs must come from a secrets manager or similar, not a root output.

1. Note that the output is in the root module.
2. Recall that root outputs are persisted in state.
3. Recall that ephemeral outputs are allowed only in child modules.
4. Conclude the configuration is rejected.

Exam tip: Ephemeral outputs belong in child modules only; a root module output cannot be ephemeral.

The dependency lock file makes provider selection reproducible across machines and runs.

Version constraints describe acceptable ranges; the dependency lock file records the exact provider versions and package checksums chosen within them. When the file is committed, terraform init on any machine installs those same selections until someone deliberately runs init -upgrade. The .terraform directory is local cache, and required_version governs only the CLI.

1. Separate constraints (ranges) from selections (exact versions).
2. Recall that the lock file stores selections and checksums.
3. Commit it so every init reuses it.
4. Upgrade deliberately with terraform init -upgrade.

Exam tip: Commit .terraform.lock.hcl so every init installs the same provider builds.

required_version in any module, including a child module, constrains which Terraform CLI releases can use it.

The requirement is a lower bound only: allow anything that understands the feature and reject older releases with a clear message. required_version is checked for the root module and every child module, so declaring ">= 1.9.0" in the shared module does exactly that. The pessimistic ~> form adds an unwanted upper bound, a 1.15 floor excludes capable releases, and the lock file has no CLI version entry.

1. Find the oldest release that supports the features used: 1.9.
2. Express a lower bound only, since newer releases must keep working.
3. Put it in the shared module, where Terraform also checks it.
4. Reject operators that add an upper bound and files that do not track the CLI.

Exam tip: Shared modules declare a minimum Terraform version with >=, not an exact or pessimistic pin.

Instance identity follows the key: for_each keyed by a stable business identifier keeps unrelated instances untouched when the collection changes.

The deciding requirement is that removing one unit leaves the rest alone. With count or with for_each keyed by position, each instance's address depends on where its name sits in the list, so deleting an entry shifts later instances and Terraform plans to change or replace them. Converting the list to a set and using for_each keys each instance by the unit name itself, which does not change when other names come and go.

1. Ask what each instance's address will be keyed by.
2. Positions shift when list items are removed; names do not.
3. Choose for_each with keys that are stable business identifiers.
4. Reject for_each maps that are still keyed by index.

Exam tip: Key instances by a stable business identifier, never by list position.

The S3 backend can lock state natively with a lock file in the bucket.

Setting use_lockfile = true makes the S3 backend write a lock object (the state key plus .tflock) beside the state, so no DynamoDB table is needed. use_lockfile defaults to false, so locking must be opted into. DynamoDB-based locking still works but is deprecated and needs an extra resource.

1. Note the constraint: no additional AWS resource.
2. Recall that S3 can lock with a .tflock object.
3. Pick use_lockfile = true.

Exam tip: S3 backend locking today: use_lockfile = true (off by default); DynamoDB locking is deprecated.

The S3 lock file is its own object and needs its own read, write and delete permissions.

With use_lockfile set, the S3 backend requires s3:GetObject, s3:PutObject and s3:DeleteObject on the lock file, whose key is the state path with .tflock appended. A policy scoped tightly to the state object therefore fails as soon as locking is enabled. Granting only PutObject would let Terraform take a lock it could never release.

1. Identify the lock object's key: the state key plus .tflock.
2. Recall the three actions locking needs: get, put, delete.
3. Reject DynamoDB permissions, which belong to the old mechanism.

Exam tip: use_lockfile needs Get, Put and Delete on <key>.tflock, not just on the state key.

During a lock migration, configure both DynamoDB and lock-file locking until no run relies on DynamoDB alone.

Locking only protects runs that check the same lock. The S3 backend documents that its S3 and DynamoDB locking arguments can be configured simultaneously to support migration: new runs then acquire both locks, so they still conflict with old runs that check only DynamoDB. Once every job uses the new configuration, dynamodb_table (deprecated) can be removed and the table deleted.

1. Note that old and new commits can run side by side for two weeks, including rollbacks.
2. Recall that a lock only excludes runs checking the same lock.
3. Recall that both locking arguments may be set together for migration.
4. Remove DynamoDB only after the overlap ends.

Exam tip: Migrate S3 locking by running both locks in parallel, then drop dynamodb_table.

When the backend settings change, init needs -reconfigure (start fresh against the new backend) or -migrate-state (copy existing state across).

Switching environments in one directory is not a migration: prod already has its own state. -reconfigure discards the saved dev backend settings and connects to prod without copying anything. -migrate-state and -force-copy copy the dev state into prod's key, overwriting or corrupting prod. -upgrade is about dependency versions.

1. Recognise that the backend settings in .terraform changed.
2. Decide whether state should move: it should not.
3. Pick the init flag that reattaches without migration.

Exam tip: Switching environments with partial backend files: init -reconfigure, never -migrate-state.

Backend settings chosen at init are saved in the working directory's data dir (.terraform by default); TF_DATA_DIR relocates it and must be consistent from init onward.

Both jobs write their backend choice into the same .terraform directory, so whichever init runs last decides which state the other job's plan reads. Giving each job its own TF_DATA_DIR keeps two independent copies of that data while the code stays shared. Lock timeouts do not help because the two jobs lock different states, -migrate-state would copy state between environments, and -parallelism controls concurrency within a single run.

1. Locate where init saves the selected backend: the data directory.
2. See that two jobs overwrite one shared data directory.
3. Recall that TF_DATA_DIR relocates it per process, set for every command from init on.
4. Reject fixes aimed at state locks or graph concurrency.

Exam tip: Two environments in one checkout at the same time: separate TF_DATA_DIR per job.

A directory per environment makes each environment a separate root configuration with its own backend, credentials and constraints, built from shared modules.

HashiCorp's alternative to workspaces is a separate configuration per deployment that instantiates common modules against its own backend. Every requirement here is a property of a root configuration: backend, credentials, required_version, and the code a reviewer reads. Workspaces and for_each keep the environments in one configuration, and directories that symlink the same files are still one configuration with one backend block and one version constraint.

1. List the requirements: backend, credentials, version constraint, visible prod config.
2. Note that each is set in the root configuration's own files.
3. Choose one root per environment, with its own backend and versions files, built from shared modules.

Exam tip: Per-environment backend, credentials or Terraform version: a root module per environment.

Separate roots trade isolation (backend, credentials, versions) for separate applies that must be promoted environment by environment.

The directory layout gives strong isolation because each root is independent, and the same independence means a change reaches an environment only when someone applies that directory. Shared modules keep the duplication small. Each directory still runs in the default CLI workspace, so terraform.workspace does not identify the environment.

1. Recall that each directory is a full root configuration.
2. Derive the benefit: independent backend and credentials.
3. Derive the cost: separate applies, possible divergence.

Exam tip: Directory per environment: isolation by default, promotion by deliberate apply.

Pinning a module version in each environment root lets a release be promoted one environment at a time; workspaces of one configuration share a single installed module version.

Promotion needs each environment to choose its own module version. In a directory-per-environment layout each root's exact pin is that choice, so the team bumps dev, then staging, then prod. A pessimistic constraint lets every root jump on its next init. Workspaces share one configuration and one set of modules installed by init, so they cannot run two releases side by side, and terraform.workspace is not a const value. -upgrade cannot leave an exact pin.

1. Identify the goal: different module versions per environment for a while.
2. Recall that modules are installed per working directory at init, so the version can only differ between configurations.
3. Recall that an exact pin stops -upgrade, while ~> lets every root move.
4. Bump the pin per root in promotion order.

Exam tip: Promote module releases by bumping each environment root's exact pin in turn.

CLI workspaces share one configuration, so environments cannot run different code from the same commit.

Every workspace evaluates whatever configuration is checked out. The refactor is on main, so any prod run from main includes it. Keeping prod behind requires a different commit for prod, or a layout where environments pin versions independently. Locks and state belong to each workspace and do not carry code between them.

1. Recall what a workspace separates: state only.
2. See that main contains both the refactor and the hotfix.
3. Conclude that the prod run includes both.

Exam tip: Workspaces split state, not code: what's on the commit goes to every environment you apply.

A VCS-driven workspace can trigger runs from Git tags that match a SemVer or custom regex format.

HCP Terraform's VCS settings let a workspace begin new runs only for changes that have a specific tag format, either semantic versioning or a custom regex, and runs are triggered for all matching tags regardless of the VCS branch setting. That gives a release-by-tag promotion model for prod. Trigger patterns are file globs, the branch setting names a branch, and speculative plans concern pull requests.

1. Identify the release signal: a version tag.
2. Recall that workspaces can trigger on tags matching SemVer or a regex.
3. Rule out settings that filter files or branches.

Exam tip: Release-by-tag for prod: Git tag triggers with a SemVer format.

Run-trigger settings decide which pushes queue runs: any file, specified paths (patterns or prefixes), or matching Git tags.

Trigger patterns are the recommended glob-based option; trigger prefixes list directories and need a working directory. Git tag triggers queue runs for all tags matching the SemVer or regex format regardless of the VCS branch setting. 'Always trigger' reacts to pushes to any file in the repository, and automatic speculative plans (on by default) only cover pull-request plans.

1. Check each claim against the three triggering modes.
2. Recall that prefixes need a working directory.
3. Recall that tag triggers ignore the branch setting.
4. Reject claims that swap pattern types or narrow 'Always trigger'.

Exam tip: Prefixes need a working directory; tag triggers ignore the VCS branch.

API-driven runs start from a configuration version, whose attributes control how its runs behave.

The configuration-versions API says that when speculative is true the version may only be used to create speculative runs, which cannot be confirmed or applied. auto-queue-runs (default true) only controls whether a run is queued automatically on upload, provisional (default false) delays the version becoming current until its run is applied, and manual apply still lets an authorised user confirm.

1. Requirement: a plan nobody can apply.
2. Find the attribute that limits the version to speculative runs.
3. Rule out attributes that only change queuing or currency.

Exam tip: Plan-only uploads in the API workflow: create the configuration version with speculative: true.

Write-only arguments plus an ephemeral source keep a generated secret out of state; the paired version argument is the rotation trigger.

Two facts decide it. A secret is absent from state only if every hop is non-persistent: an ephemeral generator (for example ephemeral aws_secretsmanager_random_password or ephemeral random_password) and a write-only argument (secret_string_wo). And because Terraform never stores or diffs write-only values, rotation happens only when secret_string_wo_version changes, which fits a reviewed pull request. A managed random_password leaks into state; an ephemeral value cannot go into secret_string; changing a generator input produces no diff.

1. List every place the secret passes through and ask which ones persist.
2. Replace the managed generator with an ephemeral one.
3. Use the write-only argument on the secret version.
4. Recall that the version argument, not the value, triggers the update.

Exam tip: Ephemeral source + write-only argument = nothing in state; bump *_wo_version to rotate.

Providers expose write-only variants of secret arguments, usually suffixed _wo and paired with a _wo_version argument.

Write-only arguments (Terraform 1.11 and later) are sent to the provider during the operation and then discarded, so they never appear in state or plan. aws_secretsmanager_secret_version offers secret_string_wo with secret_string_wo_version. The other options all persist the value; sensitivity and ignore_changes change display and diffing, not storage.

1. Recognise the requirement: written but never stored.
2. Recall the _wo / _wo_version naming of write-only arguments.
3. Reject options that only hide or ignore a stored value.

Exam tip: To write a secret without storing it, use the resource's _wo argument and its version.

When the service can own a secret, let it: RDS-managed master passwords live in Secrets Manager and rotate without Terraform touching them.

Several options keep the password out of state, but the deciding constraint is that Terraform must never generate or handle the value and rotation must be automatic. With manage_master_user_password = true, RDS creates the password in Secrets Manager and rotates it automatically (every 7 days by default); consumers use the secret ARN exposed in master_user_secret. Write-only designs still have Terraform supply the value.

1. Note the constraint: Terraform must never handle the value.
2. Eliminate designs where Terraform supplies the password, write-only or not.
3. Choose the setting that hands generation and rotation to the service.

Exam tip: Best secret handling for a managed database: let the service own and rotate it.

HashiCorp prefers a flat tree of small modules composed in the root, with dependencies passed in, over modules full of conditional creation flags.

The composition guidance recommends keeping modules small, keeping the module tree flat, and having callers decide what exists and pass it in, instead of building complex conditional branches inside a module. Splitting the large module lets each team's root compose just the pieces it needs, so a change to one piece no longer reaches unrelated teams. Per-team wrappers also work mechanically but add nesting and keep the shared core; more flags or an untyped object variable make the contract weaker.

1. Recognise the anti-pattern: conditional creation flags serving many audiences.
2. Recall the composition guidance: small modules, flat tree, dependencies as inputs.
3. Compare wrappers with composition: wrappers keep the coupled core.
4. Choose the option that removes the shared conditional core.

Exam tip: Compose small modules in the root instead of toggling a large one with flags.

When resources are extracted into a module, a moved block in the calling module maps each old address to its new module address.

Without a refactoring record, Terraform sees the old address removed and a new one added, so it plans destroy-and-create. A moved block with from = aws_s3_bucket.logs and to = module.logs.aws_s3_bucket.this, placed in the root (which owns the old address and the child module call), renames the object in state during planning, and the move is visible in the plan. The child module cannot refer to its caller's addresses, and an import block leaves the old binding behind.

1. Identify the old and new addresses.
2. Decide which module owns both addresses: the root.
3. Check the direction: from is the old address, to is the new one.
4. Rule out import, which does not remove the old binding.

Exam tip: Extracting into a module: moved from the old root address to module.<name>.<address>, declared in the root.

When cost estimation does not run

HCP Terraform documents that cost estimation is disabled for runs that use resource targeting, which is why a -target plan has no estimate (and why a cost policy can fail unexpectedly on such runs). The CLI-driven workflow itself is not the cause, and resources that cannot be priced are reported separately rather than suppressing the estimate.

1. Spot the difference from normal runs: the -target option.
2. Recall that targeted runs are excluded from cost estimation.
3. Reject causes that would affect every CLI run or every run with unpriced resources.

Exam tip: -target runs get no cost estimate.

The cost_estimate data available to Sentinel policy checks

tfrun.cost_estimate exposes prior_monthly_cost (the estimate before the plan), proposed_monthly_cost (the estimate if applied) and delta_monthly_cost (their difference, which can be negative). All three are strings holding decimals, and the namespace only exists when an estimate is available, so a policy must handle its absence (for example on targeted runs).

1. List the three fields and what each compares.
2. Recall the type: decimal strings, not numbers.
3. Recall that the namespace is absent without an estimate.
4. Keep the two statements that match.

Exam tip: cost_estimate: prior, proposed, delta, all decimal strings, present only with an estimate.

Querying workspace health across an organization

The Explorer queries data across the organization's workspaces, modules, providers and Terraform versions. Its built-in use cases include Drifted workspaces and Workspaces with failed checks, which lists every workspace that failed at least one continuous validation check, sortable in one table.

1. Note the need: a current, organization-wide list of failing checks.
2. Recall the Explorer's pre-built use cases.
3. Pick the query that reports failed continuous validation checks.

Exam tip: Organization-wide health questions: ask the Explorer.