AWS provider Collaborative Workflows Practice Test 3 — 15 Questions

Question 1

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

Accepted Answer

Using -var flag in terraform apply. 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.

Answer

By editing the state file

Answer

By modifying the provider block

Answer

By adding a new workspace

Question 2

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

Accepted Answer

Using the 'version' argument. 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').

Answer

By manually deleting other versions

Answer

By configuring a Sentinel policy

Answer

Using a provider block

Question 3

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

Accepted Answer

It changes the state file, which affects subsequent runs. 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.

Answer

It is only possible in local state

Answer

It requires all team members to re-run init

Answer

It automatically updates the git repository

Question 4

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

Accepted Answer

Using the 'terraform_remote_state' data source. 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.

Answer

Emailing the values

Answer

Hardcoding the IDs

Answer

Exporting to a flat file

Question 5

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

Accepted Answer

The second run is queued. 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.

Answer

The state file will be corrupted

Answer

The latest one wins

Answer

Both runs will fail

Question 6

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

Accepted Answer

The States tab. 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.

Answer

The Variables tab

Answer

The Runs tab

Answer

The Settings tab

Question 7

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

Accepted Answer

Enable Auto-apply. 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.

Answer

Configure Run Triggers

Answer

Set Sentinel policy to advisory

Answer

Use API-driven workflows

Question 8

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

Accepted Answer

Centralized state management. 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.

Answer

Local execution only

Answer

No need for version control

Answer

Lower costs

Question 9

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

Accepted Answer

They can be set to advisory mode. 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.

Answer

They run after the apply phase

Answer

They can only be used with AWS

Answer

They replace the need for IAM

Question 10

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

Accepted Answer

The user who initiated the run. 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.

Answer

The raw state file in plain text

Answer

Private cloud provider passwords

Question 11

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

Accepted Answer

Environment variables. 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.

Answer

Policy-level variables

Answer

State-level variables

Answer

Hardcoded module variables

Question 12

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

Accepted Answer

Policy check results. 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.

Answer

The provider source code

Answer

Organization billing page

Question 13

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

Accepted Answer

State file. 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.

Answer

Billing invoice history

Answer

Global provider plugins

Question 14

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

Accepted Answer

Need for private network connectivity. 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.

Answer

To increase the speed of the provider download

Answer

To remove the need for a VCS

Question 15

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?

Accepted Answer

Enable automatic speculative plans on the workspace and connect the workspace to the VCS repository.. 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.

Answer

Set the workspace execution mode to 'Remote' and enable run triggers from the VCS repository.

Answer

Create a CLI-driven workspace and run terraform plan locally on the pull request branch.

Answer

Configure a webhook in the VCS provider to call the HCP Terraform API to start a run on every push.