Terraform Associate Implement and Maintain State: 77 practice questions

12 of the 77 Implement and Maintain State questions in the Certsqill Terraform Associate bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for Terraform Associate? Take the free 5-min readiness check →

1. Amazon DynamoDB table with a partition key named LockID: To enable state locking and prevent concurrent applie

1. Amazon DynamoDB table with a partition key named LockID ✓

   Correct. The S3 backend uses DynamoDB for state locking. A DynamoDB table with a partition key named `LockID` (string type) must be created and referenced in the backend configuration.
2. An Amazon SQS FIFO queue serializing apply operations

   Incorrect. SQS is not used by the S3 backend for locking. Terraform state locking with the S3 backend uses a DynamoDB table.
3. S3 bucket versioning, which supplies state locking on its own

   Incorrect. S3 versioning only retains previous state versions for recovery; it does not provide locking. DynamoDB is required to prevent concurrent access.
4. Amazon ElastiCache providing a distributed advisory lock

   Incorrect. ElastiCache is not integrated with Terraform state locking. The S3 backend relies on DynamoDB for that purpose.

S3 backend requires DynamoDB for state locking — a table with partition key `LockID` (string) prevents concurrent apply operations.

2. terraform force-unlock <LOCK_ID>: Which command releases the stuck lock?

1. terraform init --clear-lock

   Incorrect. terraform init has no --clear-lock flag. force-unlock is the specific command for releasing stuck locks.
2. terraform force-unlock <LOCK_ID> ✓

   Correct. terraform force-unlock releases a stuck lock using the lock ID shown in the error message. Use with caution — only when certain no apply is actively running.
3. Delete the LockID item from DynamoDB manually via AWS Console

   Incorrect. While manually deleting the DynamoDB item would work, it's the unsafe approach. terraform force-unlock is the proper command that also handles cleanup.
4. terraform state unlock

   Incorrect. There is no `terraform state unlock` command. The correct command is `terraform force-unlock <LOCK_ID>`.

terraform force-unlock <LOCK_ID> releases a stuck state lock — the lock ID appears in the error message. Use only when certain no apply is in progress.

3. cloud block: Which backend type should be used in the Terraform configuration block?

1. local backend pointing at path = "app.terraform.io/state"

   Incorrect. The local backend stores state on the local filesystem and has no concept of a cloud URL. Terraform Cloud is configured with the cloud block.
2. http backend configured against the Terraform Cloud REST API endpoint

   Incorrect. Although technically an HTTP endpoint exists, the HTTP backend is not the intended integration. The cloud block or remote backend are the correct approaches.
3. cloud block (or remote backend with hostname = "app.terraform.io") ✓

   Correct. The `cloud` block (introduced in Terraform 1.1) is the preferred way to configure Terraform Cloud. The older `remote` backend also works, but the cloud block is recommended for new configurations.
4. s3 backend whose bucket is hosted inside Terraform Cloud storage

   Incorrect. Terraform Cloud uses its own managed state storage, not an S3 bucket. You configure it with the cloud block or remote backend, not the s3 backend.

The `cloud` block is the modern way to integrate Terraform with HCP Terraform/Terraform Cloud — it provides remote state, remote execution, and Sentinel policy integration.

4. JSON: What format is the Terraform state file (terraform.tfstate) stored in?

1. Binary/encrypted format

   Incorrect. The default state file is plain JSON — not binary or encrypted. Encryption must be added at the storage layer (S3 SSE, Terraform Cloud).
2. HCL (HashiCorp Configuration Language)

   Incorrect. HCL is the language for Terraform configuration files (.tf). The state file is JSON — a different format.
3. YAML

   Incorrect. Terraform state is JSON, not YAML. HCL (.tf files) is the configuration language; JSON is the state format.
4. JSON ✓

   Correct. terraform.tfstate is a JSON file that records the mapping between Terraform configuration resources and their real-world provider IDs and attributes.

Terraform state is stored as a JSON file — human-readable but should be treated as sensitive because it may contain plaintext secrets.

5. terraform init: After updating the backend configuration in the .tf files, what command migrates the local sta

1. terraform init (Terraform prompts to copy existing state to the new backend) ✓

   Correct. When backend configuration changes, terraform init detects the existing local state and offers to migrate it to the new backend automatically, with no manual copy needed.
2. terraform state push (uploads the local state file directly to the S3 bucket)

   Incorrect. `terraform state push` can upload a state file but skips backend-migration handling. `terraform init` performs the guided migration when the backend changes.
3. Copy terraform.tfstate into the target S3 bucket by hand using the AWS CLI

   Incorrect. A manual copy bypasses Terraform's lineage and validation checks. terraform init is the safe, automated migration mechanism.
4. terraform apply -migrate-state (moves state during the next apply run)

   Incorrect. There is no `-migrate-state` flag on terraform apply. State migration is handled by terraform init when it detects a backend change.

terraform init detects backend configuration changes and prompts to migrate existing state to the new backend — no manual copy needed.

6. Run terraform import for each resource to rebuild: How can Terraform management be restored WITHOUT running te

1. Run terraform apply — Terraform will detect existing infrastructure and create a new state file

   Incorrect. Without state, terraform apply would try to create all resources from scratch — likely failing or creating duplicates for non-idempotent resources.
2. Run terraform import for each resource to rebuild the state file from existing infrastructure ✓

   Correct. terraform import maps existing cloud resources back to Terraform state without recreating them — though tedious, this restores management without destroying infrastructure.
3. Run terraform plan -generate-state to create a new state file automatically

   Incorrect. There is no `-generate-state` flag on terraform plan. State reconstruction requires terraform import for each resource.
4. Run terraform refresh to reconstruct the state file from AWS APIs

   Incorrect. terraform refresh updates state from real infrastructure — but it requires an existing state file to know which resources to refresh. It cannot reconstruct state from scratch.

Without state, use terraform import to reconstruct state by mapping each existing cloud resource to its Terraform address — tedious but non-destructive.

7. Store state in a remote backend with encryption at rest: Which of the following are recommended practices for

Select two. More than one option is correct — every correct one is ticked below.

1. Store state in a remote backend with encryption at rest (e.g., S3 with SSE or Terraform Cloud) ✓

   Correct. Remote backends with encryption protect state from unauthorized access — state contains sensitive values that must be encrypted at rest.
2. Enable S3 versioning to allow recovery from accidental state corruption or deletion ✓

   Correct. S3 versioning retains previous state versions, enabling recovery if state is accidentally corrupted or deleted — critical for production environments.
3. Commit terraform.tfstate to a public GitHub repository for easy team access

   Incorrect. State files contain sensitive values in plaintext — public repository storage is a severe security violation.
4. Use the sensitive = true flag on all variables to automatically encrypt them in state

   Incorrect. sensitive = true only redacts values from CLI output — it does not encrypt values in the state file. Backend-level encryption is required.

Secure state: use encrypted remote backend (S3+SSE or Terraform Cloud) + enable S3 versioning for recovery. Never commit state to VCS.

8. State is stored on the local workstation: Which of the following is a limitation of the local Terraform backen

1. The local backend cannot encrypt state files at rest, so any secrets stored in state are always written in plaintext

   Incorrect. Filesystem-level encryption can still protect local state. The defining limitations of the local backend are the lack of collaboration and the lack of state locking.
2. Local state files are capped at a maximum size of 1 MB, which causes failures once the managed infrastructure grows large

   Incorrect. There is no 1 MB limit on local state files; they can grow as large as needed. The real limitations are collaboration and locking, not file size.
3. The local backend only works with AWS resources and cannot manage other providers such as Azure, GCP, or Kubernetes

   Incorrect. The local backend works with any provider; it is only a choice of where state is stored, not a restriction on which providers can be used.
4. State is stored on the local workstation, making it inaccessible to other team members and not supporting state locking ✓

   Correct. The local backend stores state in terraform.tfstate in the working directory, which is inaccessible to teammates and has no built-in locking against concurrent access.

Local backend stores state on the local filesystem — fine for individual use but unsuitable for teams due to no sharing capability and no state locking.

9. terraform state pull: Which command downloads the current remote state?

1. terraform state pull ✓

   Correct. terraform state pull fetches the current remote state and prints it as JSON to stdout, which is useful for inspection or backup without modifying state.
2. terraform state export

   Incorrect. There is no `terraform state export` subcommand. Use `terraform state pull` to output the raw remote state as JSON.
3. terraform state fetch

   Incorrect. There is no `terraform state fetch` command. The correct command for fetching remote state is `terraform state pull`.
4. terraform get state

   Incorrect. `terraform get` only installs modules referenced in the configuration. Fetching remote state is done with `terraform state pull`.

terraform state pull downloads the current remote state as JSON to stdout — safe for inspection; terraform state push uploads local state to the remote backend.

10. In `terraform.tfstate.d/staging/terraform.tfstate`: Where is the staging workspace's state file stored?

1. In a top-level directory named `staging/` that holds its own terraform.tfstate file

   Incorrect. Terraform does not create a directory named after the workspace at the top level. It uses the `terraform.tfstate.d/<workspace>/` structure instead.
2. In `terraform.tfstate.d/staging/terraform.tfstate` relative to the working directory ✓

   Correct. For the local backend, non-default workspace state is stored in the `terraform.tfstate.d/<workspace_name>/terraform.tfstate` directory structure.
3. In a file named `terraform.tfstate.staging` sitting next to the default state file

   Incorrect. Workspace states are stored inside the `terraform.tfstate.d/` directory, not as suffixed files placed alongside the default state.
4. Inside the default terraform.tfstate, which the staging workspace overwrites on switch

   Incorrect. Workspaces keep completely separate state files. The default workspace state stays at terraform.tfstate while other workspaces live under terraform.tfstate.d/.

Local backend workspace states are stored in `terraform.tfstate.d/<workspace_name>/terraform.tfstate` — the default workspace keeps `terraform.tfstate` in the working directory.

11. IAM role assumed via EC2 instance profile when running: Which of the following is a valid authentication metho

1. No authentication is needed because the S3 backend relies on public read access

   Incorrect. State buckets must be private and require proper authentication. Public access to state files is a critical security vulnerability.
2. Hardcoding access_key and secret_key directly inside the backend block

   Incorrect. Although it technically works, hardcoding credentials in configuration files is a security anti-pattern. IAM roles, environment variables, or AWS profiles are preferred.
3. IAM role assumed via EC2 instance profile when running on an EC2 instance ✓

   Correct. The S3 backend uses the same authentication chain as the AWS CLI/SDK, including IAM roles via instance profiles, environment variables like AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, and ~/.aws/credentials.
4. Storing the AWS credentials inside the terraform.tfstate state file itself

   Incorrect. The state file is not an authentication mechanism, and credentials should never be written into state files.

S3 backend uses the standard AWS credential chain: IAM roles (instance profiles), environment variables, AWS profiles, or web identity tokens — never hardcode credentials.

12. terraform state mv aws_vpc.old_name aws_vpc.new_name: After updating the config, which command updates the sta

1. terraform refresh, which realigns all state addresses

   Incorrect. terraform refresh updates attribute values such as IPs and IDs from real infrastructure; it does not rename resource addresses in state.
2. Delete the state file then re-import aws_vpc.new_name

   Incorrect. Deleting state and re-importing is dangerous and error-prone. terraform state mv performs the rename safely in a single step.
3. terraform state rm old_name then import new_name

   Incorrect. This two-step remove-and-import approach works but is unnecessarily complex. terraform state mv handles the rename atomically in one command.
4. terraform state mv aws_vpc.old_name aws_vpc.new_name ✓

   Correct. terraform state mv renames the resource address in state without any infrastructure changes. After the rename, terraform plan shows no changes.

terraform state mv renames a resource's state address atomically — the safest and simplest way to rename a resource in state without infrastructure changes.

Other Terraform Associate domains

• Understand Terraform Basics — 197 questions →
• Interact with Terraform Modules — 50 questions →
• Use and Apply the Terraform Workflow — 49 questions →
• Understand Infrastructure as Code (IaC) Concepts — 45 questions →
• Understand Terraform's Purpose (vs Other IaC) — 40 questions →
• All 495 Terraform Associate questions →