AWS provider Collaborative Workflows Practice Test 4 — 15 Questions

Question 1

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?

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

Accepted Answer

VCS-driven speculative plans. 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.

Answer

CLI-driven runs with remote backend

Answer

Run Triggers

Answer

Policy as Code with Sentinel

Question 2

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?

Accepted Answer

It allows local execution while still leveraging HCP Terraform for state storage and collaboration.. 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.

Answer

It enforces policy checks before every apply.

Answer

It provides a fully managed remote execution environment for Terraform operations.

Answer

It automatically runs speculative plans on pull requests.

Question 3

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

Accepted Answer

Update the module's version constraint in each consuming workspace to reference the new major version.. 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.

Answer

Edit the `engine_version` variable in place and re-tag the existing module version so all consumers receive the update automatically.

Answer

Delete the previous major version from the registry so consumers are forced to upgrade on their next plan.

Answer

Change the module source address in the consuming workspaces to point at the platform team's VCS branch directly.

Question 4

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?

Accepted Answer

In the workspace settings, set the 'Apply method' to 'Manual apply' and assign a team with 'Write' permissions to review and approve plans.. 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.

Answer

Set the workspace's 'Apply method' to 'Manual apply' and enable 'Run triggers' from a separate approval workspace.

Answer

Enable the 'Remote operations' setting on the workspace and require a successful `terraform plan` before apply.

Answer

Configure the workspace to use 'Auto-apply' and rely on branch protection rules in GitHub to prevent unauthorized merges.

Question 5

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?

Accepted Answer

Enable 'Manual Apply' in the workspace settings.. 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.

Answer

Use a Sentinel policy with 'soft-mandatory' enforcement.

Answer

Configure a run trigger to delay the apply.

Answer

Set the workspace's Terraform version to a specific version.

Question 6

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?

Accepted Answer

The second run is queued and can only start after the first run reaches a terminal state, respecting the workspace's run queue.. 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.

Answer

The second run overwrites the first run's plan file and applies against the latest state snapshot automatically.

Answer

Both runs execute in parallel and Terraform resolves conflicts by last-writer-wins on each resource.

Answer

The second run fails immediately with a state lock error because DynamoDB locking is not configured.

Question 7

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?

Accepted Answer

Create a new workspace that tracks the feature branch and uses the same Terraform configuration.. 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.

Answer

Change the existing workspace's VCS branch to the feature branch, run apply, then switch back to main.

Answer

Use the `-target` flag in a local `terraform apply` to apply only the IAM policy changes.

Answer

Create a run trigger from the main workspace to the feature branch workspace.

Question 8

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?

Accepted Answer

soft-mandatory. 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.

Answer

mandatory

Answer

advisory

Answer

hard-mandatory

Question 9

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?

Accepted Answer

It queues the new run, and the previous run continues until it finishes or is canceled.. 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.

Answer

It discards the in-progress run and immediately starts the new run with the latest commit.

Answer

It merges the new commit into the running plan and re-plans automatically without user action.

Answer

It blocks the push from reaching the VCS provider until the running plan is approved.

Question 10

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?

Accepted Answer

Enable speculative plans on the workspaces and attach the VCS repository so pull requests queue a plan-only run for each workspace.. 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.

Answer

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.

Answer

Configure a CLI-driven workflow on each workspace and have a developer run terraform plan locally against every workspace before approving the PR.

Answer

Add a policy set with a soft-mandatory sentinel policy that blocks applies until the module change is approved in the registry.

Question 11

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?

Accepted Answer

Check the workspace's run history for an active run and wait for it to complete or cancel it.. 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.

Answer

Run terraform init -reconfigure to reset the backend.

Answer

Delete the .terraform directory and re-run terraform init.

Answer

Run terraform force-unlock with the lock ID.

Question 12

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?

Accepted Answer

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

Answer

Configure an AWS Config rule that flags instances with public IPs and rely on it to stop the Terraform apply.

Answer

Use a `terraform_data` resource with a local-exec provisioner to scan the plan JSON and fail the apply.

Answer

Add a `precondition` block to each EC2 resource that checks the public IP attribute during apply.

Question 13

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?

Accepted Answer

Configure the workspace with manual apply and assign a team the run approval permission for that workspace.. 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.

Answer

Add a Sentinel policy with the advisory enforcement level to the workspace.

Answer

Set the workspace's execution mode to Local so each engineer applies from their own machine after review.

Answer

Enable the organization setting that requires two-factor authentication for all members.

Question 14

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?

Accepted Answer

Automatic run triggering. 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.

Answer

Speculative plans

Answer

Run triggers

Answer

Auto-apply

Question 15

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?

Accepted Answer

Assign the officer the organization-level read permission and rely on project visibility to expose run and policy results.. 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.

Answer

Create a team with the plan permission on each workspace and add the officer to that team.

Answer

Add the officer to each project's team with the write permission set on every workspace.

Answer

Give the officer the organization owner role and instruct them not to make changes.