Courseiva

CCNA Terraform Advanced Workflow Questions

16 of 91 questions · Page 2/2 · Terraform Advanced Workflow topic · Answers revealed

Practice these questionsExam hubAll questions
76
Multi-Selectmedium

Which TWO are benefits of using Terraform Cloud's remote operations with a CLI-driven run workflow?

Select 2 answers
A.Integration with version control systems for automatic plan and apply
B.Centralized state management with automatic locking
C.Support for multiple cloud providers in a single workspace
D.Reduced dependency on local environment variables for provider authentication
E.Ability to execute `terraform plan -refresh-only` without a run
AnswersA, B

Terraform Cloud can trigger runs based on VCS changes.

Why this answer

Option A is correct because Terraform Cloud's CLI-driven run workflow allows users to trigger remote operations from the CLI, which can be integrated with version control systems (VCS) via webhooks. When a VCS repository is connected, any push to a configured branch automatically triggers a remote plan and apply, enabling continuous delivery pipelines without manual intervention.

Exam trap

HashiCorp often tests the distinction between general Terraform Cloud features and those specifically tied to the CLI-driven run workflow; the trap here is that candidates may confuse broad benefits of Terraform Cloud (like multi-provider support) with the unique advantages of the CLI-driven workflow, which focuses on VCS integration and centralized state management.

Practice this question →
77
MCQhard

A company uses Terraform Cloud with a remote state backend and runs infrastructure as code through a CI/CD pipeline (GitHub Actions). The pipeline executes 'terraform plan' and 'terraform apply' using a service account with appropriate permissions. Recently, the team introduced a Sentinel policy to enforce that all AWS resources have mandatory tags (Environment, Owner, Project). The policy passes when runs are triggered manually from the Terraform Cloud UI, but fails consistently when the CI/CD pipeline runs the plan. The infrastructure configuration files are identical in both cases. The team verifies that the service account used by CI/CD has the same workspace permissions as the UI user. What is the most likely cause of the failure?

A.The Sentinel policy is checking the wrong workspace.
B.The CI/CD pipeline is using a different set of variables that override the tags.
C.The Sentinel policy is configured to fail on all plans regardless of compliance.
D.The CI/CD pipeline is using an older version of Terraform that does not support Sentinel.
AnswerB

Pipeline variables can override Terraform variables; if tags differ, Sentinel will fail.

Why this answer

The CI/CD pipeline often uses environment variables or variable files that can override Terraform variables. If the pipeline sets different values for the tag variables (e.g., missing or incorrect tags), the Sentinel policy would fail. Option C is correct because variable overrides in the pipeline are a common cause of such discrepancies.

Practice this question →
78
MCQhard

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?

A.Amend the previous commit and force push
B.Create a new commit with the fix
C.Use the 'Queue Plan' button in the Terraform Cloud UI
D.Run terraform plan locally and apply
AnswerC

Re-runs plan with the same commit.

Why this answer

Option C is correct because the 'Queue Plan' button in Terraform Cloud allows you to trigger a new speculative plan for the same commit without modifying the VCS history or creating a new commit. This is the intended workflow for re-running a plan after fixing configuration errors in a VCS-backed workspace, as it uses the existing commit but re-evaluates the configuration.

Exam trap

The trap here is that candidates may confuse the 'Queue Plan' button with simply re-running a failed plan, but HashiCorp often tests whether you understand that Terraform Cloud's VCS workflow requires a new commit for configuration changes, while 'Queue Plan' is only for re-running the same configuration without changes.

How to eliminate wrong answers

Option A is wrong because amending the previous commit and force pushing rewrites Git history, which can disrupt team collaboration and is not a recommended practice for fixing a failed run in Terraform Cloud; it also does not leverage Terraform Cloud's built-in run management. Option B is wrong because creating a new commit with the fix would trigger a new run automatically, but the question specifically asks to re-run the plan without committing again, making this an unnecessary and incorrect approach. Option D is wrong because running terraform plan locally and applying bypasses Terraform Cloud's VCS-backed workflow, state management, and collaboration features, and the apply would not be tracked or approved through Terraform Cloud's run pipeline.

Practice this question →
79
MCQhard

A team uses Terraform with multiple workspaces and wants to automatically trigger a plan when a pull request is opened in their Git repository. They use Terraform Cloud. Which feature enables this?

A.VCS-driven workflow
B.API-driven workflow
C.CLI-driven workflow
D.Registry-driven workflow
AnswerA

Automatically runs plans on PRs.

Why this answer

Option B is correct because the VCS-driven workflow in Terraform Cloud automatically runs speculative plans on pull requests. Options A, C, and D are incorrect because they require manual triggering or are not workflows.

Practice this question →
80
Multi-Selectmedium

Which three of the following are valid ways to use Terraform outside the core provisioning workflow? (Choose three.)

Select 3 answers
.Using `terraform import` to bring existing infrastructure under Terraform management.
.Using `terraform state push` to manually upload a state file to a remote backend.
.Using `terraform plan -out=tfplan` to generate a plan file for later application.
.Using `terraform console` to interactively evaluate expressions in the Terraform language.
.Using `terraform validate` to check configuration syntax before any state operations.
.Using `terraform fmt` to automatically rewrite configuration files into a canonical format.

Why this answer

The three correct options are `terraform import`, `terraform state push`, and `terraform plan -out=tfplan`. `terraform import` is a non‑provisioning workflow that maps existing infrastructure into Terraform state without creating or destroying resources. `terraform state push` manually uploads a state file to a remote backend, bypassing the normal `apply` workflow. `terraform plan -out=tfplan` generates a plan file that can be applied later, decoupling the planning phase from the apply phase and thus operating outside the core provisioning loop.

Exam trap

HashiCorp often tests the distinction between commands that are part of the core provisioning workflow (validate, plan, apply, destroy) and those that are auxiliary or administrative (import, state manipulation, plan file generation), leading candidates to mistakenly include `validate` or `fmt` as 'outside the core workflow' when they are actually preparatory steps within it.

Practice this question →
81
MCQeasy

Refer to the exhibit. A Terraform plan fails with the error shown. What is the most likely cause?

A.The S3 bucket does not have versioning enabled.
B.The DynamoDB table is not configured correctly.
C.The state file is corrupted.
D.Another Terraform run is currently in progress.
AnswerD

State lock is held by another process.

Why this answer

Option C is correct because the error indicates that the state lock cannot be acquired, meaning another process holds the lock. Options A and B would cause different errors. Option D is unlikely.

Practice this question →
82
Drag & Dropmedium

Drag and drop the steps to use Terraform workspaces for environment separation in the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order

Why this order

Workspaces isolate state; create, select, set variables, then plan and apply.

Practice this question →
83
MCQeasy

A company wants to integrate Terraform with their CI/CD pipeline to automatically deploy infrastructure. Which Terraform feature should they use to ensure state files are stored securely and accessible by the pipeline?

A.Terraform import
B.Local state with .gitignore
C.Terraform Cloud remote state
D.terraform state push
AnswerC

Secure and accessible by pipeline runs.

Why this answer

Using a remote state backend (like Terraform Cloud) ensures state is stored securely and can be accessed by pipeline runs. Local state with .gitignore is not secure or accessible. Terraform import is for adding existing resources, not state storage. terraform state push is used to manually upload state.

Practice this question →
84
MCQhard

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?

A.TF_VAR_proxy=http://proxy:8080
B.AWS_ACCESS_KEY_ID
C.HTTP_PROXY=http://proxy:8080
D.TF_LOG=DEBUG
AnswerC

Configures proxy for HTTP requests.

Why this answer

Option C is correct because 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`.

Exam trap

HashiCorp often tests the distinction between Terraform-specific environment variables (like `TF_VAR_`) and standard system proxy variables, leading candidates to mistakenly choose `TF_VAR_proxy` as a Terraform-native proxy setting.

How to eliminate wrong answers

Option A is wrong because `TF_VAR_proxy` is not a recognized environment variable in Terraform; the `TF_VAR_` prefix is used to set input variables, not proxy configuration. Option B is wrong because `AWS_ACCESS_KEY_ID` is an AWS credential variable unrelated to proxy settings; it would not fix a network connectivity issue caused by a proxy. Option D is wrong because `TF_LOG=DEBUG` enables verbose logging for debugging but does not configure proxy routing; it only increases log output without addressing the underlying proxy requirement.

Practice this question →
85
MCQhard

A team using a remote S3 backend with DynamoDB locking is experiencing frequent 'Error acquiring the state lock' messages in their CI/CD pipeline. The pipeline runs multiple concurrent jobs for different workspaces. What is the most likely cause and solution?

A.The DynamoDB table lacks sufficient read/write capacity; increase it.
B.The same workspace is being used for concurrent runs; use separate workspaces per environment.
C.The pipeline is running too many jobs; increase the lock wait time.
D.The S3 bucket is not versioned; enable versioning.
AnswerB

Different workspaces have independent state locks.

Why this answer

The error 'Error acquiring the state lock' occurs when Terraform cannot obtain a lock on the state file for a specific workspace. In this scenario, the pipeline runs multiple concurrent jobs for different workspaces, but if the same workspace is inadvertently used across concurrent runs, Terraform's DynamoDB-based locking mechanism will prevent simultaneous access to that workspace's state. The solution is to ensure each environment (e.g., dev, staging, prod) uses a separate workspace, avoiding lock contention.

Option B correctly identifies this as the most likely cause and solution.

Exam trap

HashiCorp often tests the misconception that DynamoDB capacity or S3 versioning are the root cause of lock errors, when the real issue is workspace-level contention in concurrent pipelines.

How to eliminate wrong answers

Option A is wrong because DynamoDB read/write capacity is not the issue; the lock error is about contention, not throughput limits, and increasing capacity would not resolve concurrent access to the same lock item. Option C is wrong because increasing the lock wait time (e.g., via the `-lock-timeout` flag) only delays the failure, it does not prevent the underlying conflict of multiple jobs trying to lock the same workspace state. Option D is wrong because S3 bucket versioning is unrelated to state locking; versioning protects against accidental deletion or corruption of state files, but does not affect DynamoDB lock acquisition.

Practice this question →
86
MCQhard

An organization uses Terraform Cloud to manage infrastructure across multiple teams. They need to enforce that all workspaces use a specific version of Terraform and that no workspace can be deleted accidentally. Which approach meets these requirements without using Sentinel or Terraform Enterprise?

A.Include `required_version` in each workspace's root module and configure workspace locks in the UI.
B.Set `required_providers` with version constraints in a global Terraform file.
C.Use the Terraform Cloud API to write an OPA policy that enforces Terraform version and prevents workspace deletion.
D.Configure version constraints in the Terraform Cloud workspace settings and enable deletion protection.
AnswerC

OPA policies can enforce version requirements and protect workspaces from deletion.

Why this answer

Option C is correct because the Terraform Cloud API allows you to write OPA (Open Policy Agent) policies that can enforce Terraform version constraints and prevent workspace deletion, even without Sentinel or Terraform Enterprise. OPA policies are evaluated during runs and API calls, providing a flexible, code-based approach to governance that meets both requirements.

Exam trap

HashiCorp often tests the distinction between built-in Terraform Cloud features (like workspace settings) and external policy engines (like OPA), leading candidates to assume that UI-based settings can enforce deletion protection when they cannot.

How to eliminate wrong answers

Option A is wrong because `required_version` in a root module only enforces the Terraform version at plan/apply time, not across all workspaces globally, and workspace locks in the UI prevent concurrent operations but do not prevent accidental deletion. Option B is wrong because `required_providers` with version constraints controls provider versions, not the Terraform CLI version, and does not address workspace deletion prevention. Option D is wrong because Terraform Cloud workspace settings allow you to set a Terraform version per workspace, but there is no built-in 'deletion protection' toggle; deletion protection requires Sentinel or OPA policies via the API.

Practice this question →
87
MCQhard

A large enterprise uses Terraform Cloud with remote execution mode to manage infrastructure across multiple AWS accounts. Each environment (dev, staging, prod) has a separate workspace. The security team requires that all changes to production must be approved by a senior engineer before applying. Additionally, developers should be able to plan changes in production to preview the impact, but not apply them. The current setup uses the same Terraform Cloud team membership for all workspaces. When a developer runs a plan in production, the plan succeeds but they are unable to apply. However, the security team notices that the developer can accidentally apply if they quickly approve their own plan via the UI because the workspace is configured with 'Auto Apply' enabled. The security team wants to enforce the approval process without removing the developer's ability to plan. Which combination of changes should be made? (Select only one option.)

A.Keep 'Auto Apply' enabled but restrict the production workspace to only the infrastructure lead's Terraform Cloud account.
B.Use run triggers to promote runs from dev to staging to production, and only the lead can promote to production.
C.Disable 'Auto Apply' on the production workspace and configure team permissions so that developers have 'plan' role and the infrastructure lead has 'write' role.
D.Use VCS branch restrictions to only allow applies from the 'main' branch, and have developers plan from feature branches.
AnswerC

This enforces manual approval and restricts apply permissions.

Why this answer

Option C is correct because disabling 'Auto Apply' on the production workspace ensures that no apply occurs without explicit approval. Configuring team permissions so that developers have the 'plan' role (which allows running plans but not applying) and the infrastructure lead has the 'write' role (which allows applying) enforces the required approval process while preserving the developer's ability to preview changes via plan.

Exam trap

HashiCorp often tests the distinction between run triggers (which automate promotion) and manual approval workflows, leading candidates to incorrectly choose run triggers as a solution for approval enforcement when they actually bypass manual approval.

How to eliminate wrong answers

Option A is wrong because keeping 'Auto Apply' enabled would still allow applies to happen automatically after a plan, bypassing the approval process; restricting to the lead's account does not prevent a developer from triggering a plan that auto-applies. Option B is wrong because run triggers are designed to chain runs between workspaces (e.g., promoting from dev to staging to prod) but do not enforce a manual approval step before applying in production; they automate the promotion, not the approval. Option D is wrong because VCS branch restrictions control which branches can trigger runs, but they do not prevent a developer from applying a plan if they have apply permissions; the developer could still apply from the 'main' branch if they have the appropriate role, and the scenario requires that developers cannot apply at all.

Practice this question →
88
MCQeasy

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?

A.Use the Terraform Cloud API to trigger a run.
B.Set up a webhook from the VCS provider to trigger runs.
C.Configure a remote backend to automatically run apply.
D.Execute 'terraform apply -auto-approve' in the CI pipeline.
AnswerA

The API allows programmatic triggering of runs, suitable for CI/CD integration.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between event-driven triggers (VCS webhooks) and programmatic API calls, where candidates mistakenly choose webhooks because they seem 'automated,' but the question explicitly requires programmatic invocation from an external system, not a VCS event.

How to eliminate wrong answers

Option B is wrong because setting up a webhook from the VCS provider triggers runs automatically on code changes, not programmatically from an external CI/CD system; it is event-driven, not API-driven. Option C is wrong because configuring a remote backend does not trigger runs—it only stores state remotely and enables remote execution, but the run must be initiated separately. Option D is wrong because executing 'terraform apply -auto-approve' in the CI pipeline is a local CLI command that bypasses Terraform Cloud's run management, state locking, and policy checks, and it does not integrate with Terraform Cloud's API or remote execution capabilities.

Practice this question →
89
MCQhard

An organization uses Terraform with remote state stored in S3 and DynamoDB for state locking. During a plan, they receive the error: 'Error acquiring the state lock: ConditionalCheckFailedException: The conditional request failed'. What is the most likely cause?

A.The state file in S3 is corrupted.
B.The DynamoDB table is not configured with a primary key named LockID.
C.The S3 bucket does not have versioning enabled.
D.Another Terraform process is currently running and holds the state lock.
AnswerD

Lock acquisition fails because another process holds the lock.

Why this answer

Option C is correct because the error indicates the state lock cannot be acquired because another process holds the lock. Options A and B are configuration issues that would cause different errors. Option D is unlikely; a corrupted state file would cause other errors.

Practice this question →
90
Multi-Selecteasy

Which TWO of the following are valid methods for importing existing infrastructure into Terraform management? (Choose two.)

Select 2 answers
A.Use terraform apply directly on existing resources
B.Use a third-party tool like Terraformer to generate configuration
C.Use terraform state push to manually add state entries
D.Write configuration for the resource and use terraform import
E.Use terraform import without any prior configuration
AnswersB, D

Generates HCL configuration from existing resources, then import.

Why this answer

The typical method is to write configuration and run terraform import. Third-party tools can generate configuration from existing resources. terraform import requires configuration beforehand. terraform state push is not for importing; it pushes a state file. terraform apply would try to create new resources.

Practice this question →
91
MCQeasy

A developer wants to use Terraform in a CI pipeline where the pipeline runs on pull requests. They need to preview infrastructure changes without applying them. Which command should be used?

A.terraform plan
B.terraform validate
C.terraform init
D.terraform apply
AnswerA

Plan shows what will be created/changed/destroyed.

Why this answer

Option A is correct because `terraform plan` creates an execution plan that shows what actions Terraform will take to change infrastructure to match the configuration, without actually applying any changes. This is the standard command for previewing infrastructure changes in a CI pipeline triggered by pull requests, enabling developers to review proposed modifications before merging.

Exam trap

HashiCorp often tests the distinction between validation and planning, so the trap here is that candidates confuse `terraform validate` (syntax check) with `terraform plan` (infrastructure preview), assuming validation alone is sufficient to preview changes.

How to eliminate wrong answers

Option B is wrong because `terraform validate` checks only the syntactic correctness and internal consistency of Terraform configuration files, not the actual state or planned changes against real infrastructure. Option C is wrong because `terraform init` initializes the working directory by downloading providers and modules, but does not generate any preview of infrastructure changes. Option D is wrong because `terraform apply` executes the planned changes and modifies real infrastructure, which is the opposite of a preview-only operation and should not be used in a pull request pipeline without prior approval.

Practice this question →
← PreviousPage 2 of 2 · 91 questions total

Ready to test yourself?

Try a timed practice session using only Terraform Advanced Workflow questions.

Start 20-question session