CCNA Collaborative Workflows Questions

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

`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.

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.

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.

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.

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.

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.

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.

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.

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.