I85PREP
⌘ K
Terraform Associate study materials
Terraform Associate study resources

Moving Four Workspaces to Remote Runs

Terraform Associate · Put your knowledge to work in context.

All case studies

Moving Four Workspaces to Remote Runs

Acme runs four HCP Terraform workspaces in one organization: network, dev, staging, prod. All four use CLI-driven runs with local execution today, so engineers run terraform apply on laptops while state and variables live in HCP Terraform. AWS credentials are long-lived access keys in each engineer's ~/.aws/credentials, and the same keys are pasted into two workspaces as sensitive environment variables. Prod is supposed to require a second pair of eyes. Modules are copied between repos by hand. There are six engineers, a security review in three weeks, and one constraint that cannot bend: prod applies must be reviewable and attributable, and no long-lived AWS keys may sit on laptops or in workspace variables.

1. Choose an execution mode for each workspace and explain what it changes about where credentials live.

Read the worked answer

Remote execution for all four. Runs then execute on HCP Terraform workers using the workspace's pinned Terraform version and its committed dependency lock file, and the credentials the run needs must exist in that environment, not on a laptop. That is the whole point: today's local-execution setup stores state centrally while every apply uses one engineer's laptop binary, laptop provider cache and laptop credentials - irreproducible and unattributable.

Agent execution only where it is forced. If a workspace manages resources inside a private network (VPC endpoints, on-prem, private DNS), remote workers cannot reach them, and a self-hosted agent is the answer. Agents bring their own operational burden - patching, availability, a second place credentials live - so do not adopt them as a compliance measure. Nothing in this setup suggests private reachability, so start without one.

Local execution is the trap here. It looks like a middle ground, but it leaves applies running with laptop credentials while giving the illusion of central governance. It makes sense only for a pilot on a workstation with no other option.

2. Remove the long-lived AWS keys without introducing new secrets. Describe the mechanism, the workspace settings, and how you would scope blast radius.

Read the worked answer

Use dynamic provider credentials with OIDC, so each run exchanges a short-lived HCP Terraform identity token for temporary AWS credentials.

  1. In each AWS account, create an IAM OIDC identity provider trusting app.terraform.io.
  2. Create one IAM role per environment whose trust policy restricts sub to the organization and the specific workspace name (or project), not a wildcard, and whose permission policy is scoped to what that environment genuinely touches. A prod role should not be assumable from the dev workspace.
  3. On each workspace set TFC_AWS_PROVIDER_AUTH=true and TFC_AWS_RUN_ROLE_ARN=arn:aws:iam::<acct>:role/<name> as environment variables.
  4. Delete AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY from every workspace and from the provider configuration, then run a plan to prove the assumption works.

Scoping matters more than the mechanism. One shared role would just recreate the current problem with a different shape: any workspace could then touch prod. Separate roles per environment also give you clean CloudTrail attribution - the role session name identifies the run. Put shared non-secret values in a variable set so they are not duplicated four times.

3. Make prod apply reviewable and attributable, and stop modules being copy-pasted. Name the concrete settings.

Read the worked answer

Reviewable and attributable:

  • Turn off auto-apply on prod; every run stops at a confirmed plan that a human must approve.
  • Drive prod from VCS, not the CLI, so each run records a commit SHA, author and PR link. This is what makes it attributable - a CLI run has no provenance beyond the token used.
  • Keep PR review as the first gate and the run approval as the second; the same person should not be able to do both for prod.
  • Add policy-as-code (Sentinel or OPA) on prod to block known-bad shapes - public buckets, missing required tags, instance types above the approved list. Policy evaluation happens on the plan, before approval, so reviewers see a filtered plan.
  • Use the audit log/API to answer who approved what, months later.

Modules: publish them to the organization's private registry from tagged VCS releases, then pin version in every module block. Copied modules drift silently and cannot be patched. Add a run trigger from network to the three app workspaces so ordering is deterministic instead of accidental, and keep the registry modules semver-tagged so a fix can be rolled out workspace by workspace.