Courseiva

CCNA Collaborative Workflows Questions

42 questions · Collaborative Workflows topic · All types, answers revealed

Practice these questionsExam hubAll questions
1
MCQmedium

A downstream workspace in HCP Terraform needs to automatically trigger a plan after a successful apply in an upstream workspace. How do you configure this?

A.Configuring Run Triggers in the downstream workspace
B.Enabling 'Auto-apply' in the upstream
C.Setting a 'TF_VAR' environment variable
D.Using a local variable
AnswerA

Run Triggers let a downstream workspace watch specified upstream workspaces and queue a plan automatically once their apply succeeds. This directly satisfies the stem's requirement for automatic triggering, since no manual run or webhook scripting is needed.

Why this answer

Run Triggers in HCP Terraform allow a downstream workspace to automatically queue a run when a specified upstream workspace completes a successful apply. This is the native mechanism for chaining workspaces, ensuring that dependent infrastructure is updated only after its dependencies are provisioned.

Exam trap

The trap is confusing Auto-apply with Run Triggers; Auto-apply automates the apply step within a single workspace, while Run Triggers automate cross-workspace run initiation.

How to eliminate wrong answers

Option B is wrong because enabling 'Auto-apply' in the upstream workspace only controls whether runs in that workspace are automatically applied after a plan; it does not trigger runs in other workspaces. Option C is wrong because setting a 'TF_VAR' environment variable provides input variables to Terraform configurations but does not trigger runs across workspaces. Option D is wrong because local variables are used within a Terraform module for internal calculations and have no effect on cross-workspace orchestration.

Practice this question →
2
MCQeasy

Your team uses HCP Terraform with a VCS-connected workspace. A developer pushes a commit to the tracked branch while a plan is already running. What does HCP Terraform do with the newly triggered run by default?

A.It discards the in-progress run and immediately starts the new run with the latest commit.
B.It merges the new commit into the running plan and re-plans automatically without user action.
C.It blocks the push from reaching the VCS provider until the running plan is approved.
D.It queues the new run, and the previous run continues until it finishes or is canceled.
AnswerD

A new commit creates a new run that enters the workspace queue while the current run finishes. This preserves an ordered history and prevents overlapping operations. Depending on workspace settings, an older queued run may later be discarded, but the in-flight run is not interrupted by default.

Why this answer

By default, a commit that triggers a run while another run is active creates a queued run rather than interrupting the active one. The workspace serializes runs to protect state, so the new commit waits its turn. Teams can enable run discarding to drop stale queued runs, but the in-progress run is left to finish.

Exam trap

The trap here is assuming a newer commit cancels the currently running plan by default.

Practice this question →
3
MCQeasy

Two engineers on your team both run `terraform apply` against the same HCP Terraform workspace that uses remote state, and their runs overlap in time. The second engineer's apply is rejected with a message that the workspace is locked. Which HCP Terraform behavior explains this outcome?

A.The second engineer lacks the Write permission, so HCP Terraform rejects the run with a lock-style error.
B.HCP Terraform serializes runs per workspace, so only one run can hold the state lock and modify state at a time.
C.The AWS provider imposes a DynamoDB-based lock on the S3 backend, which blocks the second run regardless of workspace settings.
D.Remote state is read-only during any apply, so the second engineer must first download state and apply locally.
AnswerB

HCP Terraform enforces per-workspace run concurrency: a run acquires the workspace lock while it plans and applies, and a second run waits or is canceled rather than proceeding concurrently. This prevents two applies from corrupting remote state. The rejection the second engineer sees is the expected result of that lock, not a misconfiguration.

Why this answer

HCP Terraform allows only one run at a time to hold a workspace's state lock, so concurrent applies are serialized. The second run is blocked until the first completes or is canceled, which matches the lock rejection. Read-only remote state, AWS-side DynamoDB locking, and permission errors do not produce this behavior in an HCP Terraform workspace.

Exam trap

The trap here is attributing the lock to an AWS S3/DynamoDB backend when state lives in HCP Terraform, which manages locking itself.

Practice this question →
4
MCQmedium

You have a Terraform configuration that uses a module from the public registry. How do you ensure your team uses a specific version?

A.By manually deleting other versions
B.By configuring a Sentinel policy
C.Using a provider block
D.Using the 'version' argument
AnswerD

The version argument inside a module block pins the registry module to an exact or constrained release, such as 5.1.0. This satisfies the requirement that the team uses a specific version, preventing automatic upgrades to newer releases that could introduce breaking changes.

Why this answer

Terraform modules sourced from the public registry support a 'version' argument inside the module block, which constrains the module to a specific published version (or version constraint). This is the supported mechanism for pinning module versions so all team members and CI pipelines resolve the same code. It uses the same version constraint syntax as providers (e.g., '1.2.0', '~> 1.2').

Exam trap

The trap here is confusing provider version pinning (provider block) with module version pinning (version argument in the module block) — candidates often pick the provider block because it also has a 'version' argument.

How to eliminate wrong answers

Option A is wrong because manually deleting other versions from the registry is not possible for public registry modules and is not a version-control mechanism — it also doesn't affect what Terraform resolves. Option B is wrong because a Sentinel policy is a policy-as-code guardrail (HashiCorp Sentinel) that can enforce rules at plan/apply time, but it does not select or pin a module version; it can only reject non-compliant versions after the fact. Option C is wrong because a provider block configures the cloud provider plugin (AWS, Azure, etc.) and its version — it has nothing to do with module versioning.

Practice this question →
5
Multi-Selecteasy

Which TWO of the following are benefits of using HCP Terraform for teams?

Select 2 answers
A.Centralized state management
B.Automated run triggers
C.Local execution only
D.No need for version control
E.Lower costs
AnswersA, B

HCP Terraform stores state remotely and centrally, so every team member reads and writes the same authoritative state rather than local copies. This satisfies the benefit of eliminating drift and conflicts arising from scattered local state files across a team.

Why this answer

Option A (Centralized state management) is correct because HCP Terraform stores Terraform state remotely in a shared, versioned workspace, enabling team members to collaborate on the same infrastructure without manually passing around terraform.tfstate files or configuring their own remote backends, and it provides state locking to prevent concurrent runs from corrupting state. Option B (Automated run triggers) is correct because HCP Terraform supports run triggers that automatically queue a dependent workspace's run when an upstream workspace completes successfully, as well as VCS-driven runs triggered by commits and API-driven runs, which streamlines multi-workspace and CI/CD workflows for teams. Option C (Local execution only) is incorrect because HCP Terraform's value comes from remote execution of runs in its managed environment, not from restricting execution to a single local machine.

Option D (No need for version control) is incorrect because HCP Terraform integrates with VCS providers like GitHub, GitLab, and Bitbucket and relies on version-controlled configurations to drive runs. Option E (Lower costs) is incorrect because HCP Terraform is a paid platform with tiered pricing based on resources and seats, so it is not inherently a cost-reduction benefit.

Exam trap

The trap is picking 'no need for version control' or 'lower costs' as benefits — candidates assume a managed platform replaces git or saves money, when HCP Terraform actually depends on VCS and is a paid service.

Practice this question →
6
Multi-Selecthard

Your organization is standardizing on HCP Terraform and needs to decide which workspaces should use remote execution with a self-hosted agent pool rather than HCP Terraform's hosted runners. Which TWO conditions justify using a self-hosted agent pool? (Choose two.)

Select 2 answers
A.The organization requires that Terraform provider credentials never leave its own network perimeter.
B.The team wants faster plan times by caching the provider plugin binary across runs.
C.The workspace must reach private AWS resources inside a VPC that is not exposed to the public internet.
D.The workspace needs to run terraform plan without writing state after a pull request is opened.
E.The workspace configuration exceeds the maximum size allowed in the private module registry.
AnswersA, C

When credentials must remain inside a controlled network boundary, running Terraform on a self-hosted agent keeps provider authentication traffic within that perimeter. Hosted runners would require the credentials to be usable from HashiCorp-operated infrastructure, which violates the stated policy, making an agent pool the appropriate choice.

Why this answer

Self-hosted agent pools exist to solve reachability and data-residency problems that hosted runners cannot. Private VPC resources that are not internet-exposed require an agent inside the network, and a policy that keeps provider credentials within the organization's perimeter likewise demands execution on organization-controlled infrastructure. Other requirements such as speculative plans or module storage limits are satisfied by the hosted platform.

Exam trap

The trap here is assuming self-hosted agents improve performance or are needed for plan-only runs, when they exist for network reachability and credential perimeter control.

Practice this question →
7
Multi-Selectmedium

Which TWO types of variables can be set in HCP Terraform?

Select 2 answers
A.Environment variables
B.Policy-level variables
C.State-level variables
D.Hardcoded module variables
E.Terraform variables
AnswersA, E

Environment variables are injected into the run's shell environment as key-value pairs, so they reach providers and tooling that read credentials or settings from the operating system rather than from Terraform's input variable mechanism. HCP Terraform supports them at workspace and variable-set scope.

Why this answer

In HCP Terraform (formerly Terraform Cloud), workspaces support two distinct categories of user-settable variables: environment variables (option A) and Terraform variables (option E). Environment variables (A) are injected into the Terraform run environment and are commonly used for provider credentials such as AWS_ACCESS_KEY_ID or TF_LOG, and they can optionally be marked sensitive. Terraform variables (E) correspond to input variables declared in the configuration (variable blocks) and are supplied as key/value pairs (e.g., via terraform.tfvars or the HCP Terraform UI/API) to parameterize a run, including HCL and sensitive variants.

The other options are not valid HCP Terraform variable types: policy-level variables (B) do not exist as a settable category (Sentinel policies are managed separately), state-level variables (C) are not a Terraform concept since state stores resource data, and hardcoded module variables (D) are simply literal values written in code rather than a configurable variable type.

Exam trap

The trap here is confusing HCP Terraform's variable types with generic Terraform concepts like state or policies, leading candidates to select plausible-sounding but non-existent options.

Practice this question →
8
MCQmedium

Two engineers on your team run `terraform apply` against the same HCP Terraform workspace within seconds of each other. The workspace uses remote execution and has no run triggers configured. What does HCP Terraform do to coordinate these concurrent runs?

A.The second run overwrites the first run's plan file and applies against the latest state snapshot automatically.
B.The second run is queued and can only start after the first run reaches a terminal state, respecting the workspace's run queue.
C.Both runs execute in parallel and Terraform resolves conflicts by last-writer-wins on each resource.
D.The second run fails immediately with a state lock error because DynamoDB locking is not configured.
AnswerB

HCP Terraform places runs in a per-workspace queue and permits only one run to hold the workspace lock at a time. The second run waits until the first finishes, is discarded, or is canceled. This serialization prevents concurrent state mutation and is the platform's built-in coordination mechanism for teams applying to a shared workspace.

Why this answer

HCP Terraform enforces a single active run per workspace by queueing subsequent runs. The queued run begins only after the active run completes, which prevents simultaneous state mutations and keeps the team's changes ordered. Engineers can cancel or discard queued runs if a newer change supersedes them.

Exam trap

The trap here is conflating self-managed S3/DynamoDB state locking with the HCP Terraform hosted run queue.

Practice this question →
9
MCQeasy

A team wants to prevent any terraform apply from running in a production workspace unless a specific individual has reviewed and approved the plan. Which HCP Terraform capability should they enable?

A.Add a Sentinel policy with the advisory enforcement level to the workspace.
B.Set the workspace's execution mode to Local so each engineer applies from their own machine after review.
C.Enable the organization setting that requires two-factor authentication for all members.
D.Configure the workspace with manual apply and assign a team the run approval permission for that workspace.
AnswerD

Manual apply causes HCP Terraform to pause after a successful plan until someone confirms the apply, and the run approval permission restricts who may confirm. Together they ensure a designated reviewer must approve before production changes proceed, which is precisely the gated workflow the team requires.

Why this answer

Manual apply introduces a pause between plan and apply, and the run approval permission controls who is allowed to confirm. Assigning that permission to the intended reviewers means an apply cannot proceed in the production workspace until one of them approves the plan, giving the enforced human gate the team wants.

Exam trap

The trap here is confusing policy enforcement with human approval, when only manual apply plus run approval permissions gates an apply on a person reviewing the plan.

Practice this question →
10
MCQeasy

In HCP Terraform, you have a workspace that uses the CLI-driven workflow. A team member runs terraform apply locally and then pushes the updated state to HCP Terraform. What is the primary benefit of this workflow?

A.It enforces policy checks before every apply.
B.It provides a fully managed remote execution environment for Terraform operations.
C.It automatically runs speculative plans on pull requests.
D.It allows local execution while still leveraging HCP Terraform for state storage and collaboration.
AnswerD

The CLI-driven workflow lets users run Terraform commands on their local machine, but state is stored remotely in HCP Terraform. This provides the benefits of remote state management, such as locking and versioning, while allowing developers to use their local tooling and environment.

Why this answer

The CLI-driven workflow in HCP Terraform is designed for users who prefer to run Terraform locally but want to use HCP Terraform for state storage and team collaboration. It combines local execution flexibility with remote state management, enabling state locking and version history without requiring remote runs.

Exam trap

The trap here is assuming that CLI-driven workflows include remote execution; they do not—Terraform runs locally, and only state is managed remotely.

Practice this question →
11
Multi-Selecthard

When troubleshooting a failed plan in HCP Terraform, which THREE sources should you check?

Select 3 answers
A.Policy check results
B.Terraform init output
C.The provider source code
D.Run logs
E.Organization billing page
AnswersA, B, D

Policy check results expose Sentinel or OPA enforcement failures that block a run before apply, satisfying the need to identify policy-driven plan failures. HCP Terraform surfaces these under the run's policy evaluations, distinct from configuration or provider errors, so checking them pinpoints whether governance rules, not code, caused the failure.

Why this answer

In HCP Terraform, a failed plan is diagnosed primarily through the run's own telemetry: Policy check results (A) are correct because Sentinel or OPA policy evaluations run as part of the plan phase and can hard-fail or soft-fail a run, so their pass/fail output and violation messages must be reviewed. Terraform init output (B) is correct because provider and module initialization happens before the plan, and errors such as failed provider installation, registry/module download failures, or version constraint conflicts surface there and will abort the plan. Run logs (D) is correct because they contain the full terraform plan execution output, including the exact error messages, resource-level diagnostics, and exit codes needed to identify the failure cause.

The provider source code (C) is not a troubleshooting source for a failed run—providers are consumed as compiled plugins, and you would inspect provider documentation or version changelogs instead. The organization billing page (E) is unrelated to plan execution failures, since billing issues affect account access or run availability, not the plan's diagnostic output.

Exam trap

The trap is selecting 'provider source code' as a troubleshooting source because it sounds technical, when the exam expects you to know the three practical sources: run logs, init output, and policy check results.

Practice this question →
12
MCQhard

When using 'terraform state mv', what is the impact on the collaboration workflow?

A.It changes the state file, which affects subsequent runs
B.It is only possible in local state
C.It requires all team members to re-run init
D.It automatically updates the git repository
AnswerA

terraform state mv rewrites resource addresses inside the shared state file, so every collaborator's subsequent plan and apply reads the altered mapping. Teammates must pull the updated state before running, otherwise their plans reference stale addresses and may propose destructive changes.

Why this answer

terraform state mv rewrites the state file, renaming or moving a resource from one address to another. Because state is the shared source of truth in a team workflow, this change affects every subsequent plan and apply run by any team member — they will see the resource under its new address. This is why state mv must be coordinated carefully in collaborative environments.

Exam trap

The trap is treating terraform state mv as a local-only operation — candidates forget that in a team with remote state, the change is immediately visible to everyone and can cause confusing plans if config is not updated in lockstep.

How to eliminate wrong answers

Option B is wrong because terraform state mv works with both local and remote backends — it operates on whatever state the backend is configured to use, including S3, HCP Terraform, and Consul. Option C is wrong because terraform init does not need to be re-run after a state mv; init handles provider and module installation, not state address changes. Option D is wrong because terraform state mv only modifies the state backend — it does not touch git, and it does not commit anything.

Version control of configuration is a separate concern from state manipulation.

Practice this question →
13
MCQmedium

You maintain a Terraform configuration in a GitHub repository that provisions AWS infrastructure. Your organization uses HCP Terraform with VCS-driven workspaces. A teammate pushes a commit that modifies `main.tf` in the `production` branch, but you need the change to be reviewed and approved before any infrastructure is modified. What should you configure to enforce this workflow?

A.Set the workspace's 'Apply method' to 'Manual apply' and enable 'Run triggers' from a separate approval workspace.
B.Enable the 'Remote operations' setting on the workspace and require a successful `terraform plan` before apply.
C.Configure the workspace to use 'Auto-apply' and rely on branch protection rules in GitHub to prevent unauthorized merges.
D.In the workspace settings, set the 'Apply method' to 'Manual apply' and assign a team with 'Write' permissions to review and approve plans.
AnswerD

Setting the apply method to manual ensures that a successful plan does not automatically apply; a user must explicitly approve it. Assigning a team with write permissions allows those users to review the plan output and approve or discard the run. This combination enforces the required review and approval before any infrastructure changes, aligning with collaborative workflows in HCP Terraform.

Why this answer

Manual apply introduces a gate where a run waits for human approval after a successful plan. Combined with team permissions that allow only designated members to approve, this ensures changes are reviewed before apply. Auto-apply or remote operations alone do not enforce review.

Run triggers and branch protection are unrelated to the approval step inside HCP Terraform.

Exam trap

The trap here is assuming that branch protection rules or remote operations provide an approval gate, when only the workspace's apply method and team permissions control who can approve runs.

Practice this question →
14
MCQmedium

Your team uses a GitHub repository as the VCS connection for an HCP Terraform workspace in the AWS provider organization. A developer pushes a commit that modifies a variable value in `terraform.tfvars` and also touches a file inside a subdirectory that is excluded by the workspace's trigger patterns. Only the subdirectory file is in the trigger pattern exclusion list. What will HCP Terraform do?

A.It will trigger a run because the commit includes changes outside the excluded paths.
B.It will trigger a run only if the excluded file is deleted in the same commit.
C.It will trigger a speculative plan but not an apply run.
D.It will not trigger a run because the commit includes a change to an excluded path.
AnswerA

HCP Terraform evaluates each changed file against the trigger patterns. If at least one changed file is not excluded, a run is queued. The change to `terraform.tfvars` is outside the excluded subdirectory, so the run is triggered even though another file in the commit is excluded.

Why this answer

When a VCS commit contains changes to both excluded and non-excluded paths, HCP Terraform checks whether any changed file falls outside the exclusion patterns. Since `terraform.tfvars` is not excluded, the commit triggers a run. Excluded paths only suppress runs when every changed file in the commit matches an exclusion pattern.

Exam trap

The trap here is assuming that any excluded file in a commit disables the entire run, when exclusion is evaluated per file and a single qualifying change is enough to queue a run.

Practice this question →
15
MCQeasy

What happens if two team members try to apply changes to the same workspace in HCP Terraform simultaneously?

A.The state file will be corrupted
B.The latest one wins
C.Both runs will fail
D.The second run is queued
AnswerD

HCP Terraform enforces per-workspace run concurrency: only one run may hold the lock at a time. The second apply therefore waits in a queue until the first completes, satisfying the simultaneous-apply constraint without corrupting state.

Why this answer

HCP Terraform (formerly Terraform Cloud) enforces a run queue per workspace. When two team members trigger runs simultaneously, the first run acquires the workspace lock and executes; the second run is placed in a queue and will start only after the first completes (or is canceled). This prevents concurrent state modifications and state corruption.

Exam trap

The trap here is assuming HCP Terraform behaves like local Terraform with no locking, leading candidates to pick 'state file will be corrupted' or 'latest one wins' instead of recognizing the queueing behavior.

How to eliminate wrong answers

Option A is wrong because HCP Terraform's state locking mechanism prevents corruption — the queue ensures only one run modifies state at a time. Option B is wrong because 'latest one wins' implies concurrent execution with the last writer overwriting, which is not how HCP Terraform works; runs are serialized, not raced. Option C is wrong because both runs do not fail — the first succeeds and the second waits, then runs.

Practice this question →
16
Multi-Selecthard

Which THREE factors influence the choice of using an HCP Terraform Agent?

Select 3 answers
A.Need for private network connectivity
B.To increase the speed of the provider download
C.Compliance requirements for data locality
D.The need to access internal APIs
E.To remove the need for a VCS
AnswersA, C, D

An HCP Terraform Agent runs inside your own network, so it is chosen when private connectivity is required — reaching internal APIs, databases or services that the hosted run environment cannot route to, and avoiding exposure of those endpoints to the public internet.

Why this answer

Option A is correct because HCP Terraform Agents are self-hosted workers that run inside your own network, allowing Terraform runs to reach private endpoints, private VCS systems, and private module registries that the hosted HCP Terraform workers cannot access. Option C is correct because agents execute the plan and apply operations on infrastructure you control, so sensitive state, variables, and provider credentials never leave your environment, satisfying data residency and compliance mandates. Option D is correct because accessing internal APIs (for example, on-premises or non-internet-facing services) requires an agent that has network line-of-sight to those APIs, which hosted runners lack.

Option B is not a valid factor: provider download speed depends on registry/CDN performance and caching, not on whether an agent is used, and agents can even be slower if their egress is constrained. Option E is not a valid factor: agents do not eliminate the need for a VCS connection; HCP Terraform still requires a linked VCS repository (or CLI/API-driven uploads) to obtain configuration, and the agent only changes where runs execute.

Exam trap

The trap is assuming agents are for performance or VCS replacement; they are primarily for network access, compliance, and internal API connectivity.

Practice this question →
17
MCQmedium

Your team uses HCP Terraform with a VCS-driven workflow. A developer opens a pull request that modifies a Terraform configuration. You want the plan to run automatically and the results to be visible on the pull request before merging. What should you configure?

A.Enable automatic speculative plans on the workspace and connect the workspace to the VCS repository.
B.Set the workspace execution mode to 'Remote' and enable run triggers from the VCS repository.
C.Create a CLI-driven workspace and run terraform plan locally on the pull request branch.
D.Configure a webhook in the VCS provider to call the HCP Terraform API to start a run on every push.
AnswerA

Automatic speculative plans trigger a plan-only run when a pull request is opened or updated, and the results are posted as a commit status check on the pull request. This provides early feedback without applying changes, exactly matching the requirement to see plan results before merging.

Why this answer

Speculative plans are a core feature of HCP Terraform's VCS-driven workflow. They run automatically on pull requests without applying changes, and the plan output is displayed as a status check on the PR. This gives reviewers immediate insight into the proposed infrastructure changes, enabling informed decisions before merge.

Exam trap

The trap here is assuming that any VCS-connected workspace automatically runs speculative plans; they must be explicitly enabled in the workspace settings.

Practice this question →
18
MCQeasy

Which of the following is an advantage of using HCP Terraform over local state for team collaboration?

A.It provides state locking and run history
B.It converts HCL to JSON
C.It eliminates the need for AWS providers
D.It is always free
AnswerA

HCP Terraform's remote backend serialises runs through state locking and retains historical run records, preventing concurrent applies from corrupting shared state. This satisfies the stem's team-collaboration advantage, which local state files cannot provide without external tooling.

Why this answer

HCP Terraform (formerly Terraform Cloud) provides remote state management with built-in state locking and run history, which are critical for team collaboration. State locking prevents concurrent runs from corrupting the state file, while run history allows teams to audit changes and roll back if needed. These features are not available with local state, making HCP Terraform a superior choice for teams.

Exam trap

The trap here is confusing HCP Terraform's collaboration features with core Terraform capabilities; candidates might think HCL-to-JSON conversion or provider elimination is an advantage, but these are unrelated to state management.

How to eliminate wrong answers

Option B is wrong because HCL to JSON conversion is a function of Terraform core (e.g., `terraform show -json`), not a specific advantage of HCP Terraform; it happens locally as well. Option C is wrong because HCP Terraform does not eliminate the need for AWS providers; providers are still required to interact with AWS APIs, and HCP Terraform merely manages state and runs. Option D is wrong because HCP Terraform is not always free; while it offers a free tier for small teams, advanced features like SSO, policy enforcement, and larger run concurrency require paid plans.

Practice this question →
19
MCQmedium

You are using HCP Terraform agents. Why would you choose to use an agent instead of the public HCP Terraform execution environment?

A.To increase execution speed
B.To access resources in a private network
C.To bypass OPA policies
D.To avoid paying for HCP Terraform
AnswerB

HCP Terraform agents run inside your own infrastructure, so they can reach endpoints on private networks that the hosted execution environment cannot route to. This directly satisfies the stem's private-network access constraint, which the public runners cannot fulfil.

Why this answer

HCP Terraform agents run Terraform operations inside your own infrastructure, so they can reach private endpoints such as internal VPCs, on-prem databases, and private APIs that the hosted public execution environment cannot route to. The public runners only have internet-facing egress, so any resource behind a firewall or private DNS is unreachable. Choosing an agent is therefore about network reachability, not speed or cost.

Exam trap

The trap here is assuming agents exist for performance or cost reasons, when the exam is really testing that agents are the mechanism for reaching private-network resources.

How to eliminate wrong answers

Option A is wrong because agent-based execution is generally not faster than the public environment — it adds a network hop back to HCP Terraform and runs on your own hardware, so speed is not the driver. Option C is wrong because OPA/ Sentinel policy enforcement happens in HCP Terraform itself and applies to agent runs too; agents cannot bypass policy checks. Option D is wrong because HCP Terraform agents are a feature of paid plans and do not eliminate HCP Terraform billing — they exist for network access, not cost avoidance.

Practice this question →
20
MCQeasy

In HCP Terraform, you want to allow team members to see runs but prevent them from approving plans. Which team permission set should you assign?

A.Write
B.Admin
C.Read
D.Cost Estimation
AnswerC

Read permissions grant visibility into workspaces and runs without any write or approval capability, so members can inspect run status and logs while being blocked from approving plans. This satisfies both constraints in the stem: view runs, deny approvals. Approval rights require the Write permission set, which Read deliberately excludes.

Why this answer

The Read permission set in HCP Terraform grants team members the ability to view workspaces, runs, state, and variables, but it does not include the permission to apply runs or approve plans. Write permission is required to queue applies and approve plans, so Read is the correct choice to allow visibility without approval authority.

Exam trap

The trap is conflating 'see runs' with 'approve plans' — candidates may pick Write thinking it is needed to view runs, but Read already grants visibility while Write grants approval.

How to eliminate wrong answers

Option A is wrong because Write permission allows members to queue runs, apply plans, and approve plans — exactly what the question says to prevent. Option B is wrong because Admin grants full control including workspace deletion, variable management, and team access, which is far more than read-only visibility. Option D is wrong because Cost Estimation is not a team permission set in HCP Terraform; it is a feature that can be enabled on workspaces, not a permission level.

Practice this question →
21
MCQhard

A platform team wants to prevent any workspace in their HCP Terraform organization from provisioning EC2 instances with public IP addresses. They need the policy to block a run before apply whenever a non-compliant plan is detected, and they want the failure reason surfaced to the developer. Which approach meets these requirements?

A.Attach a Sentinel or OPA policy set to the organization with a hard-mandatory policy that inspects the plan and denies non-compliant EC2 resources.
B.Configure an AWS Config rule that flags instances with public IPs and rely on it to stop the Terraform apply.
C.Use a `terraform_data` resource with a local-exec provisioner to scan the plan JSON and fail the apply.
D.Add a `precondition` block to each EC2 resource that checks the public IP attribute during apply.
AnswerA

Policy sets are applied at the organization or workspace level, and a hard-mandatory policy evaluates the plan and blocks the run when it fails. Sentinel or OPA policies can inspect planned resource attributes such as `associate_public_ip_address` and return a descriptive failure message. This satisfies both pre-apply blocking and developer-visible failure reasons.

Why this answer

Organization-level policy sets with hard-mandatory enforcement evaluate the plan before apply and deny non-compliant changes. Because policies are attached centrally, every workspace is covered without per-module changes, and the policy can return a clear message explaining which attribute violated the rule, giving developers actionable feedback.

Exam trap

The trap here is choosing a post-deployment detector like AWS Config or a provisioner that runs too late to prevent the change.

Practice this question →
22
MCQmedium

Your organization uses HCP Terraform with several projects. A compliance officer must be able to read the results of every policy evaluation and run across all projects, but must not be able to modify workspaces or trigger runs. Which approach grants exactly these rights?

A.Assign the officer the organization-level read permission and rely on project visibility to expose run and policy results.
B.Create a team with the plan permission on each workspace and add the officer to that team.
C.Add the officer to each project's team with the write permission set on every workspace.
D.Give the officer the organization owner role and instruct them not to make changes.
AnswerA

Organization-level read grants visibility into workspaces, runs, and policy evaluations across all projects without conferring the ability to modify settings or trigger runs. It scales automatically to new projects and workspaces, giving the compliance officer exactly the read-only cross-project view required.

Why this answer

Organization-level read permission is designed for users who need to observe activity across all projects without changing anything. It reveals workspace runs, plans, and policy evaluation results while withholding the ability to modify configuration or queue runs. Because it applies at the organization scope, it automatically covers future projects and workspaces the compliance officer must review.

Exam trap

The trap here is assuming per-workspace permissions are required for cross-project visibility, when organization-level read already covers all projects.

Practice this question →
23
MCQeasy

Where can you view the historical state versions in HCP Terraform?

A.The Variables tab
B.The Runs tab
C.The States tab
D.The Settings tab
AnswerC

The States tab within a workspace lists every historical state version, showing serial numbers, timestamps and who created each one. This is the dedicated interface for reviewing past state, satisfying the requirement to view historical state versions rather than only the current state.

Why this answer

The States tab in an HCP Terraform workspace displays the historical list of state versions, including the serial number, the run that produced each version, timestamps, and options to download or roll back. This is the dedicated location for inspecting state history.

Exam trap

The trap is confusing the Runs tab with the States tab — runs show execution history, but state versions are specifically under the States tab, and candidates often pick Runs by association.

How to eliminate wrong answers

Option A is wrong because the Variables tab manages workspace and environment variables, not state versions. Option B is wrong because the Runs tab shows the history of plan and apply runs, but state versions are viewed under the States tab. Option D is wrong because the Settings tab contains workspace configuration such as VCS connection, execution mode, and destruction settings, not state history.

Practice this question →
24
Multi-Selectmedium

Which THREE pieces of information are displayed in the HCP Terraform Run UI?

Select 3 answers
A.The user who initiated the run
B.The raw state file in plain text
C.Policy check status
D.Plan output
E.Private cloud provider passwords
AnswersA, C, D

The Run UI records run metadata, and the initiating user is displayed so teams can trace who triggered the plan or apply. This satisfies the stem's requirement for information shown in the HCP Terraform Run UI, alongside status and timing details.

Why this answer

Option A is correct because the HCP Terraform Run UI shows run metadata including the identity of the user or team that triggered the run, which is essential for audit and collaboration. Option C is correct because Sentinel policy checks (and other policy evaluations) are surfaced in the run's UI with their pass/fail status, so users can see whether policies were enforced before apply. Option D is correct because the run's plan output, including the proposed resource changes and the diff, is displayed in the UI for review and approval.

Option B is not correct because the raw state file is not shown in plain text in the Run UI; state is stored securely and accessed via state versions or the API, not displayed as raw text. Option E is not correct because private cloud provider passwords are sensitive credentials and are never displayed in the Run UI; they are stored as sensitive variables and masked.

Exam trap

The trap here is confusing the Run UI with the States or Variables tabs — candidates assume raw state or credentials are visible in a run, but HCP Terraform deliberately hides both to preserve the security boundary.

Practice this question →
25
MCQmedium

You want to automate the approval process for non-production environments in HCP Terraform. Which setting enables this?

A.Configure Run Triggers
B.Set Sentinel policy to advisory
C.Enable Auto-apply
D.Use API-driven workflows
AnswerC

Auto-apply removes the manual confirmation gate, so a successful plan in a non-production workspace is applied without human approval. This directly satisfies the automation requirement, whereas manual apply would still require someone to approve each run.

Why this answer

Enabling Auto-apply in a workspace's settings allows HCP Terraform to automatically apply a successful plan without manual approval. For non-production environments, this streamlines the deployment process by removing the need for human intervention after the plan phase.

Exam trap

The trap is mixing up Run Triggers with Auto-apply; Run Triggers are for cross-workspace orchestration, while Auto-apply is for automating the apply step within a workspace.

How to eliminate wrong answers

Option A is wrong because Run Triggers are used to trigger runs in a workspace based on upstream workspace applies, not to automate approval within a workspace. Option B is wrong because Sentinel policies set to advisory only provide warnings and do not block or auto-approve runs; they do not automate the approval process. Option D is wrong because API-driven workflows involve triggering runs via the API, but they do not inherently automate the approval step; approval still requires a manual action unless Auto-apply is enabled.

Practice this question →
26
MCQhard

Your team uses HCP Terraform with a VCS-driven workflow. You have a workspace that deploys to AWS. A developer wants to test a change that modifies an IAM policy without affecting the main branch. They create a feature branch and push changes, but the workspace is configured to track the `main` branch. What is the most appropriate way to allow the developer to test their change in isolation?

A.Change the existing workspace's VCS branch to the feature branch, run apply, then switch back to main.
B.Use the `-target` flag in a local `terraform apply` to apply only the IAM policy changes.
C.Create a new workspace that tracks the feature branch and uses the same Terraform configuration.
D.Create a run trigger from the main workspace to the feature branch workspace.
AnswerC

Creating a separate workspace that tracks the feature branch allows the developer to run plan and apply in isolation, using the same configuration but with its own state and variables. This prevents interference with the main workspace's state and infrastructure. It aligns with HCP Terraform's recommended pattern for branch-based development and testing, enabling safe experimentation before merging to main.

Why this answer

Isolating feature branch testing requires a separate workspace that tracks the feature branch, providing independent state and variables. Changing the existing workspace's branch or using local targeted applies introduces risk of state corruption or bypasses governance. Run triggers are for chaining workspaces, not for branch isolation.

Exam trap

The trap here is thinking that temporarily switching the workspace branch or using local CLI commands can safely test changes, when only a dedicated workspace provides proper isolation and state separation.

Practice this question →
27
MCQhard

In a workspace, you define a variable named 'region'. How can you override this value for a specific run without changing the workspace configuration?

A.By editing the state file
B.By modifying the provider block
C.Using -var flag in terraform apply
D.By adding a new workspace
AnswerC

The -var flag passes an input variable value at the command line for that single terraform apply invocation, taking precedence over the workspace's stored value. The workspace configuration file remains untouched, satisfying the requirement to override without permanent change.

Why this answer

The '-var' flag allows you to override a variable's value for a specific Terraform run without modifying the workspace configuration. For example, 'terraform apply -var='region=us-west-2'' sets the value for that run only. Other options do not provide a way to override variables per run.

Exam trap

The trap is confusing workspace-level variable changes with per-run overrides, or thinking that editing the state file is a valid method.

How to eliminate wrong answers

Option A is wrong because editing the state file is not a supported or safe way to override variables; state files store resource attributes, not input variables. Option B is wrong because modifying the provider block changes the configuration itself, not a per-run override. Option D is wrong because adding a new workspace creates a separate environment with its own variables, but it does not override a variable for a specific run in the existing workspace.

Practice this question →
28
MCQmedium

Your organization uses HCP Terraform with a VCS-driven workflow. A developer accidentally merges a change to the main branch that modifies a production workspace's Terraform code. The workspace is configured to auto-apply. Which mechanism can prevent the change from being applied immediately?

A.Use a Sentinel policy with 'soft-mandatory' enforcement.
B.Configure a run trigger to delay the apply.
C.Set the workspace's Terraform version to a specific version.
D.Enable 'Manual Apply' in the workspace settings.
AnswerD

Enabling 'Manual Apply' overrides the auto-apply setting and requires a user to manually confirm the apply after a successful plan. Even if auto-apply is enabled, manual apply forces an approval step. This directly prevents the change from being applied immediately without human intervention.

Why this answer

Manual Apply is the workspace setting that forces a user to explicitly confirm an apply after a successful plan, even if auto-apply is enabled. It acts as an approval gate. The other options do not prevent an immediate apply: run triggers are for cross-workspace runs, soft-mandatory policies allow overrides, and version pinning is unrelated.

Exam trap

The trap here is thinking that auto-apply cannot be overridden, or that a policy can block an apply without manual intervention.

Practice this question →
29
MCQhard

Your team uses HCP Terraform with a workspace connected to a GitHub repository. You need to ensure that no changes can be applied to production unless a specific compliance policy passes. The policy should block the apply if it fails, but authorized users should be able to override the failure with a justification. Which Sentinel enforcement level should you use?

A.mandatory
B.soft-mandatory
C.advisory
D.hard-mandatory
AnswerB

Soft-mandatory enforcement blocks the apply if the policy fails, but allows users with the appropriate permissions to override the failure and proceed, typically after providing a reason. This matches the requirement to block non-compliant changes while permitting authorized overrides with justification.

Why this answer

Soft-mandatory enforcement blocks an apply when a policy fails but permits authorized users to override the failure with a justification. This balances compliance with operational flexibility. Advisory does not block, hard-mandatory does not allow overrides, and 'mandatory' is not a valid enforcement level.

Exam trap

The trap here is confusing soft-mandatory and hard-mandatory, or assuming that advisory provides blocking.

Practice this question →
30
MCQmedium

You are managing state in a multi-region deployment. You need to ensure that simultaneous terraform apply operations do not corrupt the state file. Which backend configuration parameter primarily enables this functionality?

A.workspace_key_prefix
B.kms_key_id
C.acl
D.dynamodb_table
AnswerD

The `dynamodb_table` parameter enables state locking by writing a lock item to a DynamoDB table before any apply begins, so a second concurrent `terraform apply` fails rather than corrupting the shared state file. This directly satisfies the stem's requirement that simultaneous operations across regions cannot overwrite each other's state.

Why this answer

The dynamodb_table parameter in an S3 backend configuration enables state locking by having Terraform write a lock item to a DynamoDB table before any apply, preventing concurrent operations from corrupting the state file. Without it, two simultaneous applies could both read and write the same state object, causing lost updates or inconsistent resource tracking.

Exam trap

The trap here is confusing encryption or access-control parameters (kms_key_id, acl) with locking — candidates who skim often pick kms_key_id because 'security' sounds like it prevents corruption.

How to eliminate wrong answers

Option A is wrong because workspace_key_prefix only controls the S3 key path for non-default workspaces; it has no locking semantics. Option B is wrong because kms_key_id enables server-side encryption of the state object at rest, not concurrency control. Option C is wrong because acl sets the S3 object ACL (e.g., private, bucket-owner-full-control) and does not prevent simultaneous writes.

Practice this question →
31
MCQhard

You are writing an OPA (Open Policy Agent) policy to restrict resource creation. You want to deny any EC2 instance that does not include the 'CostCenter' tag. How do you access the resource attributes in the policy?

A.terraform.tags
B.input.resource_changes
C.state.output
D.var.tags
AnswerB

OPA evaluates Terraform plan JSON, where every proposed change appears under input.resource_changes. Each entry carries the resource type, address and planned values, so the policy can inspect the EC2 instance's tags block and deny the run when 'CostCenter' is absent.

Why this answer

OPA policies for Terraform evaluate a JSON document that Terraform sends to the policy engine, and the resource attributes live under input.resource_changes. Each entry in that array contains the address, type, and the planned change with after values, so a policy checks input.resource_changes[_].change.after.tags for the CostCenter tag. This is the correct path to access resource attributes.

Exam trap

The trap is assuming OPA sees Terraform variables or state outputs directly, when the policy input is the plan JSON and resource attributes are nested under input.resource_changes.

How to eliminate wrong answers

Option A is wrong because 'terraform.tags' is not a valid OPA input path — OPA does not expose a terraform namespace. Option C is wrong because 'state.output' is not part of the policy input document; outputs are not the mechanism for inspecting resource changes. Option D is wrong because 'var.tags' refers to Terraform variables, which are not exposed to OPA in the resource_changes structure.

Practice this question →
32
Multi-Selecteasy

Which THREE components are part of the 'Workspace' object in HCP Terraform?

Select 3 answers
A.State file
B.Billing invoice history
C.Global provider plugins
D.Run history
E.Variables
AnswersA, D, E

Each HCP Terraform workspace stores its own state file, holding the recorded resource attributes and serial for the infrastructure it manages. State is a core component of the workspace object, distinct from configuration, which lives in the linked VCS repository.

Why this answer

In HCP Terraform, a Workspace is the fundamental unit that groups a Terraform configuration with its associated data, and the state file (A) is a core component because it stores the mapping between resources and real infrastructure, enabling plan and apply operations. Run history (D) is also part of the Workspace object, as each workspace records the sequence of runs (plan, apply, destroy) along with their status, logs, and outcomes. Variables (E) are included because workspaces hold both Terraform variables and environment variables that parameterize runs, with values that can be set per workspace and marked sensitive.

Billing invoice history (B) is not a workspace component; it belongs to the organization or account billing level. Global provider plugins (C) are not part of a workspace either, since provider plugins are installed and cached at the run environment or organization level, not stored within the workspace object itself.

Exam trap

The trap is including organization-level or runner-level concerns like billing or provider plugins as workspace components — candidates conflate 'things a workspace uses' with 'things a workspace IS'.

Practice this question →
33
MCQeasy

You are configuring a new HCP Terraform workspace that uses a VCS connection to a GitHub repository. You want runs to be automatically triggered when changes are pushed to the main branch. Which setting should you enable?

A.Automatic run triggering
B.Speculative plans
C.Run triggers
D.Auto-apply
AnswerA

In HCP Terraform, the 'Automatic run triggering' setting, when enabled, causes a run to be queued whenever a change is pushed to the tracked branch in the VCS repository. This is exactly what is needed to trigger runs on pushes to the main branch. It is a standard feature for VCS-driven workflows.

Why this answer

HCP Terraform's VCS integration includes an 'Automatic run triggering' setting. When enabled, any commit to the tracked branch (e.g., main) queues a new run. This is the correct setting to achieve automatic runs on code pushes.

Other options like run triggers, auto-apply, and speculative plans serve different purposes and do not initiate runs on VCS changes.

Exam trap

The trap here is confusing 'run triggers' with automatic run triggering; run triggers are for workspace dependencies, not VCS events.

Practice this question →
34
MCQhard

When migrating from local state to HCP Terraform, which command is used to initialize the migration?

A.terraform login
B.terraform push
C.terraform init
D.terraform migrate
AnswerC

`terraform init` detects the existing local backend configuration and prompts to migrate state to HCP Terraform's remote backend, copying `terraform.tfstate` to the workspace. This satisfies the migration constraint directly, since no separate import or push command exists for backend transitions.

Why this answer

The 'terraform init' command is used to initialize a Terraform working directory, and when migrating from local state to HCP Terraform, it detects the backend configuration change and prompts to migrate the state. This is the standard command to set up the backend and perform the migration. Other commands are not used for this purpose.

Exam trap

The trap is thinking that a dedicated 'terraform migrate' command exists, or confusing 'terraform init' with 'terraform login' for authentication.

How to eliminate wrong answers

Option A is wrong because 'terraform login' is used to authenticate to HCP Terraform, not to initialize or migrate state. Option B is wrong because 'terraform push' is a deprecated command from older Terraform versions and is not used for migration. Option D is wrong because 'terraform migrate' is not a valid Terraform command.

Practice this question →
35
Multi-Selecthard

Your organization runs HCP Terraform with the AWS provider and wants to enforce a policy that blocks any `aws_s3_bucket` resource lacking a `lifecycle_rule` block. You are authoring a Sentinel policy that uses the `tfplan/v2` import. Which two statements correctly describe how the policy is evaluated and enforced? (Choose two.)

Select 2 answers
A.The Sentinel policy is evaluated against the plan JSON produced by a plan run, and a hard-mandatory failure prevents the apply from proceeding.
B.The `tfplan/v2` import exposes only the final resource attributes, so `lifecycle_rule` blocks cannot be detected in the plan.
C.Sentinel policies can only be attached at the workspace level and cannot be applied across an entire organization.
D.Sentinel policies are evaluated only after the apply completes, so violations are reported but infrastructure is already modified.
E.A soft-mandatory policy failure allows an authorized user to override the failure and continue the apply, whereas hard-mandatory blocks it entirely.
AnswersA, E

Sentinel policies using the tfplan/v2 import inspect the structured plan representation before any infrastructure changes occur. When a policy has hard-mandatory enforcement, a failing rule halts the run and the apply cannot proceed, which is precisely how you block a bucket without a lifecycle_rule. This is the intended mechanism for preventive governance in HCP Terraform.

Why this answer

Sentinel evaluates the plan before apply, so a hard-mandatory failure blocks a non-compliant S3 bucket from ever being created, while soft-mandatory allows an authorized override. Both facts reflect how policy sets are enforced in HCP Terraform. Post-apply-only evaluation, workspace-only scoping, and an inability to inspect nested blocks are all incorrect characterizations of the Sentinel workflow.

Exam trap

The trap here is conflating Sentinel's pre-apply plan evaluation with post-apply compliance scanning, and confusing soft-mandatory override behavior with hard-mandatory blocking.

Practice this question →
36
MCQmedium

If you need to share output values between workspaces, what is the best practice in HCP Terraform?

A.Emailing the values
B.Hardcoding the IDs
C.Exporting to a flat file
D.Using the 'terraform_remote_state' data source
AnswerD

The terraform_remote_state data source reads another workspace's stored state outputs at plan time, exposing them as data attributes. This is the documented best practise for cross-workspace output sharing, avoiding hardcoded values or manual copying between configurations.

Why this answer

The `terraform_remote_state` data source is the canonical way to share outputs between workspaces (or separate state files) in HCP Terraform and Terraform OSS. It reads the remote state of another workspace and exposes its root-level outputs as attributes, so consumers always get the latest values without manual copying. This keeps state as the single source of truth and avoids drift.

Exam trap

The trap here is assuming any file- or copy-based mechanism is acceptable for cross-workspace sharing; Terraform exams consistently reward the native `terraform_remote_state` data source over manual or ad-hoc methods.

How to eliminate wrong answers

Option A is wrong because emailing values is manual, insecure, and creates drift the moment the source workspace changes. Option B is wrong because hardcoding IDs breaks the link between workspaces — any change in the source workspace silently invalidates the consumer. Option C is wrong because exporting to a flat file is an out-of-band artifact that Terraform cannot track, version, or refresh, so it is not a supported sharing mechanism.

Practice this question →
37
MCQmedium

Your team maintains a shared Terraform configuration in a GitHub repository. A developer opens a pull request that changes the instance type of a production EC2 instance. You want the change to be automatically validated by running a speculative plan before any human reviews the code. Which HCP Terraform feature should you configure to achieve this?

A.CLI-driven runs with remote backend
B.VCS-driven speculative plans
C.Run Triggers
D.Policy as Code with Sentinel
AnswerB

When a workspace is connected to a VCS repository, HCP Terraform automatically queues a speculative plan for every pull request that modifies the working directory. This plan runs without applying changes, giving reviewers a preview of the infrastructure impact. Configuring the workspace with VCS integration is exactly what enables this automatic validation.

Why this answer

VCS-driven speculative plans are automatically queued by HCP Terraform when a pull request is opened against a connected repository, running a plan without applying. This provides early feedback and validation before merge. Run Triggers orchestrate runs between workspaces, CLI-driven runs are manual, and Sentinel policies only enforce rules during an existing run.

Exam trap

The trap here is confusing policy enforcement with automatic validation, assuming that Sentinel or Run Triggers can trigger plans on pull requests.

Practice this question →
38
MCQeasy

Your team is using HCP Terraform. You need to isolate development, staging, and production environments using the same set of configuration files. Which feature should you implement?

A.Modules
B.Sentinel Policies
C.Workspaces
D.Run Triggers
AnswerC

Workspaces let one configuration directory drive multiple, isolated deployments, each holding its own state, variables and run history. Separate workspaces for development, staging and production therefore reuse the same configuration files while keeping environments fully isolated, satisfying the stated constraint.

Why this answer

HCP Terraform workspaces provide isolated environments for infrastructure management, each with its own state, variables, and run history. By using the same configuration files across multiple workspaces, you can deploy to development, staging, and production with environment-specific variables and separate state, achieving the required isolation. This is the standard pattern for multi-environment deployments in HCP Terraform.

Exam trap

The trap is confusing workspaces with modules or policies; candidates may think modules provide environment isolation, but modules are about code reuse, while workspaces are about state and variable isolation.

How to eliminate wrong answers

Option A is wrong because modules are reusable units of Terraform configuration, not an isolation mechanism for environments; they help organize code but do not separate state or variables per environment. Option B is wrong because Sentinel Policies are policy-as-code guardrails that enforce rules on runs, not a way to isolate environments. Option D is wrong because Run Triggers are used to chain runs across workspaces, not to isolate environments; they actually create dependencies between workspaces.

Practice this question →
39
MCQmedium

Your team is using HCP Terraform with a workspace that has a remote backend. A developer runs terraform apply from their local CLI, but the apply fails because the state is locked. Which action should the developer take to resolve the lock and proceed with the apply?

A.Check the workspace's run history for an active run and wait for it to complete or cancel it.
B.Run terraform init -reconfigure to reset the backend.
C.Delete the .terraform directory and re-run terraform init.
D.Run terraform force-unlock with the lock ID.
AnswerA

In HCP Terraform, state locks are typically held by active runs. The developer should inspect the workspace's run history to see if a run is currently executing. If so, waiting for it to finish or canceling it will release the lock. This is the safe and recommended way to resolve the lock without risking state corruption.

Why this answer

State locks in HCP Terraform are held by active runs. The correct approach is to check the workspace's run history for an in-progress run and either wait for it to complete or cancel it. Force-unlock, reinit, or deleting local files do not safely resolve the lock and can cause issues.

Exam trap

The trap here is assuming that local CLI commands like force-unlock or reinit can resolve a lock managed by HCP Terraform's remote backend.

Practice this question →
40
MCQmedium

Your team uses HCP Terraform with a VCS-driven workflow. A pull request modifies a module that three separate workspaces consume from a shared private registry. You want reviewers to see the effect of the module change in each consuming workspace before the PR merges, without any state being written. What should you configure?

A.Create a run trigger on each consuming workspace so a plan is queued whenever the module repository receives a new commit to the default branch.
B.Configure a CLI-driven workflow on each workspace and have a developer run terraform plan locally against every workspace before approving the PR.
C.Add a policy set with a soft-mandatory sentinel policy that blocks applies until the module change is approved in the registry.
D.Enable speculative plans on the workspaces and attach the VCS repository so pull requests queue a plan-only run for each workspace.
AnswerD

Speculative plans run on pull requests without applying or writing state, so reviewers see the planned effect in each consuming workspace before merge. Attaching the repository to each workspace is what triggers those plan-only runs, giving the pre-merge visibility the scenario requires while keeping state untouched.

Why this answer

Speculative plans are the HCP Terraform mechanism that runs terraform plan on pull requests without applying or persisting state. Attaching the shared repository to each consuming workspace causes a plan-only run per workspace when the PR opens or updates, letting reviewers inspect the module's impact everywhere before merge. This satisfies the no-write requirement while keeping the VCS-driven workflow intact.

Exam trap

The trap here is assuming run triggers or policy checks provide pre-merge plan visibility, when only speculative plans on VCS-connected workspaces do.

Practice this question →
41
Multi-Selecthard

Which TWO of the following are true regarding OPA/Sentinel policies?

Select 2 answers
A.They run after the apply phase
B.They can only be used with AWS
C.They can be set to advisory mode
D.They can be scoped to specific workspaces
E.They replace the need for IAM
AnswersC, D

Advisory mode lets a policy report violations without failing the run, so teams can trial governance rules before enforcing them. This satisfies the requirement that policies need not block, distinguishing advisory from soft-mandatory and hard-mandatory enforcement levels.

Why this answer

Option C is correct because both OPA and Sentinel policies support an advisory (soft-mandatory) enforcement mode, which reports policy violations without blocking the run, unlike hard-mandatory mode that fails the run. Option D is correct because policies can be scoped to specific workspaces, allowing different policy sets to apply only to designated workspaces rather than globally. Option A is incorrect because OPA/Sentinel policies are evaluated during the plan phase (pre-apply), not after apply.

Option B is incorrect because these policies are cloud-agnostic and work with any provider, not just AWS. Option E is incorrect because policies govern Terraform configuration compliance and do not replace IAM, which controls authentication and authorization to cloud resources.

Exam trap

The trap is assuming policies run post-apply or are cloud-specific — candidates conflate policy-as-code with cloud IAM or with runtime enforcement, when in fact Sentinel/OPA gate the plan-to-apply transition and are provider-neutral.

Practice this question →
42
Multi-Selecthard

Your organization uses HCP Terraform with a private module registry. A platform team publishes a module that provisions an Amazon RDS instance, and several application teams consume it across different workspaces. The platform team must release a backwards-incompatible change to the module's `engine_version` variable, but they do not want existing consumers to break on their next run. Which two actions should the platform team take to safely version and publish this change? (Choose two.)

Select 2 answers
A.Update the module's version constraint in each consuming workspace to reference the new major version.
B.Edit the `engine_version` variable in place and re-tag the existing module version so all consumers receive the update automatically.
C.Delete the previous major version from the registry so consumers are forced to upgrade on their next plan.
D.Publish the change as a new major version of the module in the private registry, following semantic versioning.
E.Change the module source address in the consuming workspaces to point at the platform team's VCS branch directly.
AnswersA, D

After the new major version is published, each consumer must opt in by updating its `version` constraint in the `module` block. This is the deliberate adoption step that prevents accidental breakage. Without changing the constraint, consumers remain on the old major line, so this action is required to move them forward on their own schedule.

Why this answer

A breaking change to a shared module must be released as a new major version so existing consumers are unaffected, and each consumer must explicitly raise its version constraint to adopt it. Together these steps isolate the incompatible change, preserve reproducibility for teams not yet ready to migrate, and keep adoption a deliberate per-workspace decision.

Exam trap

The trap here is assuming that editing a module in place and re-tagging it will propagate updates safely to all consumers.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Collaborative Workflows questions.

Start 20-question session