State — Terraform Associate 004 practice questions

Storing state in a shared object store rather than a laptop MOST directly addresses which risk?

1. Secrets appearing in plan output
2. Configuration syntax errors reaching production
3. Divergent state copies producing duplicate infrastructure
4. Provider version drift between different members of the team

Answer: C — Divergent state copies producing duplicate infrastructure

A) Redaction in output is governed by sensitivity, not by the backend. B) Syntax errors are caught by validate and fmt regardless of where state lives. C) Correct — a single shared state prevents each engineer from holding a different picture of reality and recreating objects that already exist. D) Provider versions are pinned by the dependency lock file, not the backend.

What is the Terraform state file?

1. A plain-text log of the commands run in the directory, kept only for troubleshooting
2. An optional cache that can be deleted safely because Terraform rebuilds it on demand
3. A scratch file of unstructured notes that Terraform writes between plan and apply
4. An HTML report of the managed infrastructure, regenerated at the end of every apply
5. A JSON record mapping configuration to real infrastructure; keep it in a remote backend

Answer: E — A JSON record mapping configuration to real infrastructure; keep it in a remote backend

E is right: terraform.tfstate is JSON that binds each configuration address to a real object, and teams should hold it in a locking, encrypted backend such as S3, Azure Storage, GCS or HCP Terraform. B is the dangerous one: state cannot simply be rebuilt, and losing it orphans resources. A, C and D misdescribe both the format and the purpose.

In a multi-developer setting using a local backend (terraform.tfstate on each laptop), what is the primary risk?

1. State files on a laptop are too small to record meaningful infrastructure.
2. Terraform refuses to run when state is stored on more than one machine.
3. Local state is inherently more secure than any remote backend alternative.
4. Divergent copies of state cause conflicting applies, lost updates and corruption.

Answer: D — Divergent copies of state cause conflicting applies, lost updates and corruption.

D is right: with per-laptop state there is no single authoritative record, so two engineers can plan against different truths and overwrite each other's resources. A is irrelevant — size is not the issue. B is false; Terraform has no idea other copies exist, which is exactly the danger. C ignores that local files are unencrypted and unversioned. The fix is a remote backend with state locking so writes are serialised.

Two CLI workspaces exist for one configuration using a remote backend. Which statement is accurate?

1. Each workspace has its own state, isolated within the same backend
2. Each workspace requires its own backend block in the configuration
3. Workspaces are the same feature as HCP Terraform projects
4. Workspaces share one state file and differ only by variable values

Answer: A — Each workspace has its own state, isolated within the same backend

A) Correct — CLI workspaces partition state into separate instances under one backend configuration, so each has an independent state. B) A single backend block serves all workspaces of that configuration. C) Projects group HCP Terraform workspaces for organisation and access control; they are a different concept. D) Sharing one state file would defeat the isolation workspaces provide.

Which sequence is correct for moving a project from local to a remote S3 backend?

1. Delete the local state file first, then run terraform init against the bucket.
2. Run terraform apply -refresh-only before declaring any backend configuration.
3. Copy terraform.tfstate into the S3 bucket by hand and edit the serial number.
4. Add the backend block, run terraform init, and accept the migration prompt.

Answer: D — Add the backend block, run terraform init, and accept the migration prompt.

D is right: init detects that the configured backend differs from the recorded one and offers to copy existing state into the new location. A throws away the only record of your infrastructure before the migration can read it. B refreshes state but does nothing about where it lives. C is the hand-editing trap — serial and lineage fields are Terraform's business. Configure encryption and locking on the bucket as part of the same change.

Where should production Terraform state be stored?

1. On the operator's laptop only, so that the file never leaves the machine that created it
2. Committed to the Git repository beside the configuration so history is preserved in reviews
3. A remote backend such as S3, Azure Storage or HCP Terraform, with locking and encryption
4. Distributed to teammates as an email attachment whenever an apply changes the resources
5. As plain text in a shared folder on a developer workstation for quick manual inspection

Answer: C — A remote backend such as S3, Azure Storage or HCP Terraform, with locking and encryption

C is right: a remote backend gives shared access, state locking and encryption at rest; HCP Terraform provides all three as a managed service. A blocks collaboration and risks loss. B leaks secrets into version history and still has no locking. D and E have no locking, no access control and no reliable single source of truth.

What is the Terraform state file, and what is its primary purpose?

1. An append-only log of commands that operators have run against this working directory
2. Human-readable documentation of the architecture, generated for reviewers after each apply
3. A backup copy of the configuration source, used to restore .tf files if they are deleted
4. Sample data used to exercise the configuration before it is pointed at a real environment
5. terraform.tfstate: the record mapping configured resources to real infrastructure IDs

Answer: E — terraform.tfstate: the record mapping configured resources to real infrastructure IDs

E is right: state maps each configuration address to the real object's ID and attributes, which is what lets plan compute a diff. It may contain sensitive values, so it belongs in an encrypted remote backend. A, B, C and D describe logs, docs, source backups and test fixtures - none of which Terraform reads to determine what exists.

After a 'plan' shows 0 changes but real infrastructure was modified out-of-band, what is the most appropriate next step?

1. Run terraform destroy and rebuild everything so that state matches the code.
2. Open terraform.tfstate in an editor and hand-edit the drifted attributes.
3. Run terraform plan -refresh-only to reconcile state with reality and show drift.
4. Ignore it, because Terraform reconciles out-of-band changes on its own schedule.

Answer: C — Run terraform plan -refresh-only to reconcile state with reality and show drift.

C is right: the refresh-only mode reads the real resources, reports the differences, and lets you accept them into state without proposing any infrastructure change. A destroys production to fix a bookkeeping problem. B risks corrupting state, and hand-edited files lose their audit trail. D is false — nothing reconciles on a schedule. Note that the standalone terraform refresh command is deprecated in favour of this mode.

Which step is REQUIRED for a safe shared-state S3 backend setup?

1. Enable versioning on the bucket; that alone protects against concurrent applies.
2. Versioning plus encryption is enough, since state locking is entirely optional.
3. Versioning and encryption on the bucket, plus a locking mechanism in the backend.
4. Configure locking purely client-side with a local lock file kept on each developer machine.

Answer: C — Versioning and encryption on the bucket, plus a locking mechanism in the backend.

C is right: versioning gives you recoverable history, encryption protects the secrets that state holds in plaintext, and a lock is what actually stops two applies from writing at once. A and B are the half-right trap — versioning records the collision, it does not prevent it. D cannot work, because a lock file on one laptop is invisible to everyone else. The lock must live where all clients can see it.

What is a Terraform 'workspace'?

1. A feature of the code editor that groups related .tf files into a single project view
2. An individual user account with permission to run plan and apply against a backend
3. A synonym for a module: a reusable, versioned bundle of resources, variables and outputs
4. A named alias for a separate state file, letting one configuration back several environments
5. A Git branch that Terraform checks out automatically before computing an execution plan

Answer: D — A named alias for a separate state file, letting one configuration back several environments

D is right: CLI workspaces keep multiple named states for one configuration, addressed through terraform.workspace. In HCP Terraform a workspace is a heavier object with its own variables, run history and permissions, and workspaces are grouped into projects. A, B, C and E describe tooling, identity, modules and version control instead.

Why does Terraform keep a state file at all, and name three things it is used for?

State maps the resources in your configuration to the real objects that exist in the provider. It is used to track resource identity and metadata so Terraform knows what it already manages, to record dependencies so it can order destroys correctly even after the configuration changes, and to cache attribute values so plans are fast and can be diffed against reality.

terraform.workspace value?

Built-in variable, current workspace name. Default workspace = 'default'.

Terraform state?

JSON file (terraform.tfstate). Maps resources in config to real-world IDs.