TF-004 Use Terraform outside the core workflow Practice Test 2 — 15 Questions

Question 1

A team uses Terraform Cloud for remote state management. They want to ensure that state file changes are only made through the Terraform Cloud API and not through direct access to the storage backend. Which feature should they enable?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Remote state locking. Remote state locking ensures that only one operation can modify the Terraform state at a time. When using Terraform Cloud as the remote backend, locking is automatically managed and prevents any direct modifications to the state file outside of a Terraform run. Because Terraform Cloud handles locking through its API, any attempt to directly access the storage backend would fail to acquire a lock, thus preventing changes. This effectively enforces that all state modifications go through the Terraform Cloud API.

Answer

Sentinel policy enforcement

Answer

VCS integration

Answer

Team tokens

Question 2

A company uses Terraform with multiple cloud providers and wants to integrate with their existing CI/CD pipeline. They need to enforce that all infrastructure changes go through code review and automated testing before being applied to production. Which approach best meets these requirements?

Accepted Answer

Configure Terraform Cloud with run triggers and policy checks. Terraform Cloud's run triggers and policy checks (e.g., Sentinel) enforce that all infrastructure changes must pass code review and automated testing before being applied. This integrates directly with the CI/CD pipeline by requiring a pull request to trigger a plan, which is then reviewed and approved via Terraform Cloud's governance controls, ensuring no change reaches production without validation.

Answer

Store state in a remote backend and use terraform apply in the pipeline

Answer

Use the Terraform CLI in the CI/CD pipeline with remote state

Answer

Run terraform apply locally after manual approval

Question 3

An operator runs `terraform apply` and receives an error that the state file is locked. What is the most likely cause?

Accepted Answer

Another user is running a Terraform operation. Terraform uses a state locking mechanism (typically via a backend like S3 with DynamoDB, or Consul) to prevent concurrent operations from corrupting the state file. When another user or process is running a Terraform operation (e.g., `apply`, `plan`, `destroy`), the lock is held, and any subsequent `terraform apply` will fail with a 'state file is locked' error. This is a fundamental safety feature to ensure state consistency.

Answer

The state file is outdated and needs refresh

Answer

The configuration has a syntax error

Answer

The user lacks write permissions to the state file

Question 4

An organization wants to use Terraform to manage infrastructure in multiple environments (dev, staging, prod) with the same configuration but different variable values. Which approach should they use?

Accepted Answer

Use Terraform workspaces and separate variable files. Terraform workspaces allow you to manage multiple distinct sets of infrastructure resources within the same configuration by maintaining separate state files. By combining workspaces with separate variable definition files (e.g., `dev.tfvars`, `prod.tfvars`), you can reuse the same configuration code while applying environment-specific variable values, avoiding duplication and ensuring consistency across environments.

Answer

Create separate directories with duplicated configurations

Answer

Use a single state file with environment variables

Answer

Use different versions of Terraform for each environment

Question 5

A team uses Terraform Cloud with a VCS-backed workflow. They notice that a recent commit triggered a run that failed because of an invalid configuration. The team fixed the configuration and wants to re-run the plan without committing again. Which action should they take?

Accepted Answer

Create a new commit with the fix. In a VCS-backed Terraform Cloud workspace, runs are triggered by commits to the linked repository. When a configuration error is found in the code, fixing it requires a new commit that includes the corrected code. The 'Queue Plan' button re-runs a plan using the same commit, so it cannot incorporate local fixes. Creating a new commit (option B) triggers a new run with the fixed configuration.

Answer

Amend the previous commit and force push

Answer

Use the 'Queue Plan' button in the Terraform Cloud UI

Answer

Run terraform plan locally and apply

Question 6

A user wants to see the current state of resources in a human-readable format without making changes. Which command should they use?

Accepted Answer

terraform show. `terraform show`, is correct because it displays the current state of managed resources in a human-readable format (defaulting to plain text) without making any changes. This command reads the state file directly and presents its contents, making it ideal for inspection and debugging. Unlike `terraform plan`, it does not generate an execution plan or propose modifications.

Answer

terraform output

Answer

terraform state list

Answer

terraform plan

Question 7

A company wants to use Terraform to manage resources across AWS and Azure. They need a single workflow that can apply changes to both providers. What is the best practice?

Accepted Answer

Define both providers in a single configuration. Terraform allows multiple providers to be defined in a single configuration, enabling a unified workflow to manage resources across AWS and Azure. By declaring both providers in the same root module, a single `terraform apply` can create, update, or destroy resources from both clouds in the correct order, leveraging Terraform's dependency graph to handle cross-provider dependencies. This is the recommended best practice for multi-cloud management with a single workflow.

Answer

Use separate Terraform configurations for each provider

Answer

Use Terraform Cloud workspaces with different providers

Answer

Use Terraform workspaces to separate providers

Question 8

During a `terraform apply`, the operation fails mid-way due to a network outage, leaving some resources created. The operator wants to resume applying from where it left off without destroying the already-created resources. What should they do?

Accepted Answer

Run terraform apply again. Terraform uses a state file to track the resources it manages. When `terraform apply` fails mid-way, the state file is updated to reflect the resources that were successfully created. Running `terraform apply` again will cause Terraform to compare the current state with the configuration, detect that the already-created resources exist, and proceed to create only the remaining resources, effectively resuming from where it left off without destroying anything.

Answer

Run terraform destroy and then apply

Answer

Run terraform refresh

Answer

Run terraform apply -auto-approve

Question 9

Which THREE of the following are valid methods to manage Terraform state in a team environment? (Choose three.)

Accepted Answer

Using a remote backend like S3 with DynamoDB locking. Options B, C, and E are all valid methods for managing Terraform state in a team environment. Option B uses a remote backend like S3 with DynamoDB locking to centralize state and prevent concurrent modifications. Option C leverages Terraform workspaces with a remote backend to isolate state for different environments while maintaining a single backend configuration. Option E uses Terraform Cloud, which provides a managed state backend with built-in locking and versioning, simplifying team collaboration. Option A is incorrect because version control systems lack state locking and can lead to corruption. Option D is incorrect because storing state locally on a network drive introduces consistency and locking issues, making it unsuitable for concurrent team access.

Answer

Storing state in a version control system

Answer

Storing state locally and sharing via network drive

Question 10

Based on the exhibit, what will happen to the existing Elastic IP (aws_eip.web_eip) when this plan is applied?

Accepted Answer

It will be destroyed. The Terraform configuration shows that the `aws_eip.web_eip` resource is no longer defined in the configuration after the plan is applied. Terraform will detect that the resource exists in the state but is absent from the configuration, and by default, it will destroy the Elastic IP to reconcile the state with the configuration. This is standard Terraform behavior for resources removed from `.tf` files.

Answer

It will remain unchanged

Answer

It will be updated in-place

Answer

It will be created

Question 11

A user receives the error shown in the exhibit when running `terraform init`. The user is behind a corporate proxy. Which environment variable should be set to resolve this issue?

Accepted Answer

HTTP_PROXY=http://proxy:8080. Terraform uses the standard `HTTP_PROXY` environment variable to route HTTP/HTTPS requests through a corporate proxy when downloading providers and modules. Setting `HTTP_PROXY=http://proxy:8080` instructs Terraform's underlying HTTP client to connect via the specified proxy, resolving the connectivity error during `terraform init`.

Answer

TF_VAR_proxy=http://proxy:8080

Answer

AWS_ACCESS_KEY_ID

Answer

TF_LOG=DEBUG

Question 12

You are a platform engineer at a large enterprise that uses Terraform Cloud with a VCS-backed workflow for all infrastructure. Your team manages a configuration that provisions AWS EC2 instances for a critical application. Recently, a junior team member accidentally committed a change that removed a required tag from the EC2 instance resource. The change passed the plan stage but was blocked by a Sentinel policy during the apply, preventing the infrastructure from being updated. The team needs to fix the configuration and apply the change. However, the repository is configured to automatically trigger runs on every push to the main branch. The team wants to avoid triggering an unwanted run while they work on the fix. What should the team do?

Accepted Answer

Create a feature branch, fix the configuration, and merge via pull request. Using a feature branch and pull request allows the team to fix the configuration without triggering a run on the main branch, since Terraform Cloud’s VCS integration only auto-triggers runs on pushes to the configured branch (typically main). Once the fix is merged via pull request, the change will be applied through the normal VCS-backed workflow, maintaining audit trails and policy enforcement. This approach avoids disrupting the VCS connection or bypassing Terraform Cloud’s governance.

Answer

Temporarily disable the VCS connection in Terraform Cloud to prevent runs

Answer

Run terraform apply locally with the fixed configuration to bypass Terraform Cloud

Answer

Amend the commit on main and force push to overwrite history

Question 13

You are managing a Terraform configuration that deploys resources across multiple AWS accounts using provider aliases. The configuration uses a single backend (S3) to store the state file. Recently, you discovered that the state file has become very large (over 100 MB) and is causing slow operations and timeouts. The team wants to improve performance without losing the ability to manage all resources with a single `terraform apply`. You need to propose a solution. Which approach should you take?

Accepted Answer

Switch the backend from S3 to Terraform Cloud to improve performance. Switching to Terraform Cloud can improve performance with large state files due to its optimized backend, remote state management, and built-in caching. It allows you to continue managing all resources with a single `terraform apply` command, as Terraform Cloud handles state operations efficiently. This approach does not require splitting the state file or using multiple workspaces, thus preserving the ability to apply all changes in one operation.

Answer

Use state encryption to compress the state file

Answer

Use Terraform workspaces to separate environments into different state files

Answer

Split the configuration into separate directories for each environment

Question 14

A DevOps team is using Terraform Cloud to manage infrastructure. They want to integrate Terraform into their CI/CD pipeline by triggering runs programmatically. Which approach should they use to invoke a Terraform run from an external system?

Accepted Answer

Use the Terraform Cloud API to trigger a run.. The Terraform Cloud API provides a programmatic endpoint to trigger runs, allowing external CI/CD systems to initiate Terraform operations without manual intervention. This is the correct approach because it directly invokes a run with full control over variables, configuration versions, and apply strategies, aligning with the requirement to integrate Terraform into a CI/CD pipeline programmatically.

Answer

Set up a webhook from the VCS provider to trigger runs.

Answer

Configure a remote backend to automatically run apply.

Answer

Execute 'terraform apply -auto-approve' in the CI pipeline.

Question 15

An organization uses Terraform Cloud for team collaboration. They have a workspace that manages production infrastructure. Due to a security policy, they must ensure that all changes go through a peer review process before they are applied. How can they enforce this requirement?

Accepted Answer

Enable 'apply on merge' and set the workspace to require approval before applying.. Enabling 'apply on merge' combined with requiring approval before applying enforces a peer review process: changes must be merged via a VCS pull request (triggering the plan), and then a separate approval step is needed before Terraform Cloud applies the changes. This ensures that no change is applied without explicit human approval after the plan is reviewed.

Answer

Require all changes to be submitted via a VCS pull request.

Answer

Use run triggers to automatically apply after a successful plan in another workspace.

Answer

Lock the workspace and only unlock it for approved changes.