HCP Terraform / Enterprise Operations

TERRAFORM-PRO-002 · 42 questions

• A new platform team is onboarding 40 microservices owned by five product teams into HCP Terraform. Each service has dev and prod, every team must manage only its own services, and shared credentials and policies should be applied per team rather than per service. How should the hierarchy be laid out?
• The payments team must be able to create, configure, run and delete any workspace in the payments project, including future ones. It must not rename or delete the project, change which teams can access it, or touch workspaces in other projects. Which permission should the team receive?
• A repository holds the configuration for a shared networking stack. The team wants HCP Terraform to queue a run automatically whenever a pull request is merged to main, and to show a plan on every pull request, without writing any pipeline code. Which workspace workflow fits?
• A team must keep its state in HCP Terraform for locking and history, but its plans and applies have to execute on each engineer's laptop with credentials already present there. Which workspace execution mode should be set?
• During a two-hour database maintenance window, operations needs to stop anyone from applying changes to the prod-db workspace, whether the run comes from VCS, the CLI, the API or a run trigger. Which action meets this need?
• A prod workspace has cost estimation enabled and a Sentinel policy set attached. A run finished planning, showed an estimate, and is now paused without applying, and the run page shows the state Policy Override. Which statement correctly describes the run's progress?
• Engineers want a message in their Slack channel whenever a run in the prod-api workspace is waiting for someone to approve the plan or a policy override, but not for every run that starts or finishes. What should they configure?
• A regulated customer cannot send state or run data to any SaaS service, but its teams want the same workspaces, private registry, policy sets and VCS-driven runs that HCP Terraform provides. Which offering should the customer use?
• Workspaces, team access and variables in an HCP Terraform organization are created by hand in the UI, and settings now differ between teams in ways nobody can explain. The platform team wants every change to these settings reviewed and versioned. What should it do?
• Before approving any production apply, finance wants each HCP Terraform run on AWS, Azure and Google Cloud resources to show the estimated monthly cost and how much the change raises or lowers it. What provides this?
• With cost estimation enabled, the platform team wants a guardrail that stops any run whose change would raise the estimated monthly cost by more than 500 dollars, while allowing an authorized approver to let an exception through. How should this be implemented?
• Leadership asks how the organization's HCP Terraform Standard bill is calculated so it can forecast next year's cost. Which description of the usage measure is accurate?
• A security advisory requires upgrading the hashicorp/aws provider in every workspace that still uses a 4.x release. The platform team needs a list of affected workspaces across the whole organization today, without changing any configuration. What should it use?
• Finance cannot attribute the AWS bill to teams because resources created through Terraform carry inconsistent tags. The platform team wants every taggable AWS resource in a configuration to get cost-center and team tags without editing each resource block. What should it do?
• An organization has hundreds of workspaces that nobody has applied in over a year, and many still hold managed resources that cost money. The platform team wants to find them and clean them up safely. Which approach is correct?
• Developers create short-lived test environments in their own HCP Terraform workspaces, and many are forgotten and keep running for weeks. The platform team wants such environments torn down automatically when nobody has changed them for a few days. What should it configure?
• A director wants a quick organization-wide view of how many resources HCP Terraform currently manages, together with counts of projects, workspaces and applies and the plan's limits, without building any tooling. Where should the director look?
• One Terraform configuration for an order service must be deployed to dev, stage and prod in HCP Terraform. Each environment needs its own state, its own variable values and its own approval settings, while the code stays identical. How should the workspaces be organized?
• All workspaces in the dev project need the same TFVARregion value and the same non-production credentials, including workspaces added later. Workspaces in the prod project must not receive these values. What should the platform team configure?
• A CLI-driven configuration links to several HCP Terraform workspaces through a cloud block with workspaces { tags = { app = "billing" } }. The matching workspaces are billing-dev, billing-stage and billing-prod. An engineer must run a plan against prod. What should the engineer do?
• A monorepo holds envs/dev, envs/stage, envs/prod and a shared modules directory. The VCS-backed prod workspace currently plans on every commit to any file. It should plan only when files under envs/prod or modules change. How should the workspace be configured?
• The networking repository uses main for ongoing work and a release branch for approved changes. The dev workspace should run on merges to main, while the prod workspace, connected to the same repository, must run only on changes to the release branch. What should be configured?
• Reviewers want per-environment, non-secret values such as instance sizes and replica counts to appear in pull request diffs and in Git history next to the code. Each environment has its own directory and HCP Terraform workspace. Where should these values live?
• The stage workspace reads outputs from the prod-network workspace through terraformremotestate. Security requires that no other workspace, including the dev workspaces in the same project, can read prod-network's state. How should prod-network be configured?
• Stage and prod workspaces each call the company's network module from the private registry. Platform wants prod to receive exactly the module code that was already applied and verified in stage, with no edits in between. Which promotion approach meets this?
• Developers want a temporary environment for each feature branch: a workspace that runs that branch's code, receives the team's dev variable set, and is removed when the branch is merged. The platform team wants this automated through its pipeline. What should it use?
• A production workspace is pinned to Terraform 1.9.8 and must move to 1.15. The configuration's requiredversion allows both releases. The team wants the change done with the least risk of surprise infrastructure changes. Which approach is best?
• Several HCP Terraform workspaces were set to always use the newest Terraform release. After a new release came out overnight, plans in those workspaces began showing different behaviour, and nobody had approved an upgrade. What change prevents this from happening again?
• Two hundred HCP Terraform workspaces must move from Terraform 1.13 to 1.15 in controlled batches, and every change has to be reviewable and repeatable. Clicking through each workspace's settings page is not acceptable. What should the platform team do?
• A workspace was upgraded from Terraform 1.12 to 1.15 and a successful apply ran. A week later an engineer wants to switch the workspace back to 1.12 because a colleague prefers its output format. What is the correct guidance?
• A configuration declares requiredversion = "~> 1.15.0". Its HCP Terraform workspace is still set to Terraform 1.14.3, and every run now fails during initialization with an unsupported Terraform version error. What is the correct fix?
• A producer workspace publishes network outputs, and five consumer workspaces read them with terraformremotestate. All six are on Terraform 1.10 and will move to 1.15 on different days. Which sequencing minimises the risk of consumers failing to read the producer's state?
• Before changing a workspace from Terraform 1.13 to 1.15, the team wants to see how the configuration behaves on 1.15 without altering the workspace's version setting and without any risk of an apply. What should it do?
• Terraform 1.9 has reached end of life inside the company, and the platform team needs a current list of every workspace in the organization that still runs a 1.9.x release, with no changes to any workspace. Where should it look?
• Teams in one HCP Terraform organization start runs from VCS merges, from the CLI with the cloud block, and from a CI system calling the API, and every workspace uses remote execution. Security needs one set of Sentinel rules enforced on every run, whatever started it. What should the platform team do?
• Policy authors keep their Sentinel policies in a VCS-connected policy set repository. A recent merge contained a logic error that blocked many production runs. They want every pull request to that repository to prove each policy passes and fails on the right sample data. What should the repository's pipeline do?
• A GitHub Actions workflow drives HCP Terraform through the API: it uploads a configuration version and then reports success. A hard-mandatory Sentinel policy failed on a recent run, yet the workflow showed green and nobody noticed. What should the workflow do?
• A team runs Terraform in Jenkins with an S3 backend, outside HCP Terraform, and must enforce the same policy-as-code rules on proposed changes before any apply. Which pipeline design does this?
• A new Sentinel rule requiring encryption on all storage resources would fail for many existing workspaces if enforced today. The governance team wants the rule live in every workspace without breaking teams on day one, and to block violations later. What rollout should it use?
• Developers complain that a Sentinel policy only reports the main rule as false, so they cannot tell which resource broke it or why, and each fix reveals another failure on the next run. What change to the policy addresses this?
• A Sentinel policy limits the number of instances a single run may create. The data project should allow 20, while every other project should allow 5. The governance team wants one copy of the policy code. How should this be implemented?
• Policies in an HCP Terraform organization are currently edited directly in the web UI. A faulty edit last month blocked deployments, and nobody could see who changed what or roll back quickly. What should the governance team move to?