HCP Terraform Governance practice questions

It calculates costs based on real-time AWS billing API calls.

Why it fails: Cost Estimation uses published list prices from its pricing data, not live AWS billing API calls, so it excludes discounts, credits and negotiated rates. Real-time billing data belongs in AWS Cost Explorer or the Cost and Usage Report.

It applies to all resources, including custom providers.

Why it fails: Cost estimation relies on provider pricing data, so custom or unlisted providers are excluded and resources show no cost. It applies to supported AWS, Azure and Google resources; custom providers would be correct only if their pricing metadata were integrated.

It only works for paid HCP Terraform tiers.

Why it fails: Cost Estimation runs on all HCP Terraform tiers, including the free tier, so restricting it to paid plans misstates the licensing model. It is tempting because several governance features, such as Sentinel policy enforcement and audit logging, genuinely require paid tiers, which leads teams to assume cost estimation is bundled with them.

Implement Sentinel policies on the registry.

Why it fails: Sentinel policies evaluate plan data during runs; they cannot restrict which module versions appear in the registry. It is tempting because Sentinel enforces organisational guardrails, but version approval requires registry-level controls such as module version tagging or curation, not policy-as-code checks.

Enable auto-publish for all versions.

Why it fails: Auto-publish pushes every committed version into the registry, directly contradicting the need to limit availability to approved versions only. It is tempting because it reduces manual publishing effort, but that convenience is exactly what allows unvetted versions to reach workspaces.

Set the module to Private and grant access only to specific organizations.

Why it fails: Setting a module to private and scoping organisation access controls who can consume the module, not which versions are approved. It is tempting because it sounds like restriction, but visibility and version approval are separate axes; version curation is required here.

Set the workspace status to 'Locked'.

Why it fails: Locking only prevents concurrent runs.

Change the workspace execution mode to local.

Why it fails: Execution mode does not affect deletion rights.

Enable 'Prevent Destroy' in Terraform code.

Why it fails: This prevents resource destruction, not workspace deletion.

The workspaces are moved to a 'default' project.

Why it fails: Workspaces are destroyed if not moved.

The workspaces are unassigned but remain.

Why it fails: They must be moved before deletion or they are removed.

The Private Module Registry does not host providers.

Why it fails: The registry supports modules, and Terraform Registry supports providers; they are distinct.

The workspace is in 'Local' execution mode.

Why it fails: Execution mode does not dictate provider availability.

The organization's subscription does not allow custom providers.

Why it fails: This is not a feature-locked item.

Permission to create new organizations.

Why it fails: That requires a higher-level user account in the HCP platform.

Read access to logs only.

Why it fails: Admin grants full control over organisation settings, members and repositories, not merely log viewing. Read-only log access is the Auditor role's purpose, so choosing Admin for visibility alone over-privileges the account. Admin would be correct only when the person must manage billing, members or security settings.

Access to view the billing credit card information.

Why it fails: Billing is usually managed at the account level.

Faster plan execution speeds.

Why it fails: Plan execution speed is determined by the number of resources and provider API throughput, not by project grouping; projects partition state and access, not compute. It tempts because projects do isolate environments, which suits team separation or blast-radius control, but they never accelerate apply runs.

Automatic state backup.

Why it fails: Projects group workspaces and manage variables, run permissions and remote state, but state backup is configured separately through the backend, such as S3 versioning. Teams expecting projects to handle backup confuse organisation with storage durability.

Using a local API key for authentication.

Why it fails: API keys allow access, but they don't trigger runs on their own.

Modifying the state file directly.

Why it fails: Editing state directly bypasses the run pipeline entirely, so no plan or apply is queued. It is tempting because state manipulation does alter infrastructure tracking, and is the correct action when repairing corrupted or drifted state manually, but it never triggers a workspace run.

Executing 'terraform apply' locally.

Why it fails: Local terraform apply executes against your own CLI and credentials, not the HCP Terraform workspace's remote execution environment, so no workspace run is queued. It is tempting because the same command does trigger runs in a CLI-driven workspace when remote backend execution is configured.

A paid subscription license key.

Why it fails: Sentinel is bundled with Terraform Enterprise and needs no licence key; a policy set comprises policies, an enforcement level, and a scope. A paid key would be relevant to standalone Sentinel licensing, not to defining a policy set.

A list of allowed IP addresses.

Why it fails: A policy set is defined by its policies, enforcement level, and scope; IP allowlists belong to network or API configuration. Allowed addresses would matter when restricting access to a Terraform Enterprise instance, not when composing a Sentinel policy set.

A soft-mandatory Sentinel policy warning.

Why it fails: A soft-mandatory Sentinel policy warning is advisory; the run continues and is not marked Error. It is tempting because Sentinel failures do affect runs, and soft-mandatory is correct when you want visibility without blocking, since only hard-mandatory failures halt execution.

A hard-mandatory Sentinel policy failure.

Why it fails: This results in a 'Policy Failed' status, not an 'Error' status.

The workspace is locked by another run.

Why it fails: A workspace locked by another run causes the new run to queue or wait, not to report Error. It is tempting because locking blocks progress, and this behaviour is correct when concurrent runs must be serialised, but the run simply waits for the lock to release.

Global IP firewalling.

Why it fails: IP firewalling is an org-level security setting.

Organization billing limits.

Why it fails: Billing is an org-wide setting.

The provider source code.

Why it fails: Sentinel's tfrun import exposes plan, state and run metadata, not provider source code, which never enters the policy evaluation context. It is tempting because provider versions and sources appear in configuration, and inspecting source would be correct only if the policy engine were given that code explicitly.

The raw state file contents.

Why it fails: tfrun exposes structured values from the plan and run, not the raw state file's serialised contents, so parsing state text is unavailable. It is tempting because state underpins the plan, and reading raw state would be correct only for tooling that inspects the state file directly outside Sentinel.

Create a new policy set containing a policy with an exception for the specific workspace or operation, scoped to that workspace, and ensure it is advisory or soft-mandatory.

Why it fails: While scoping a policy set to a workspace is possible, changing the enforcement level to advisory or soft-mandatory would not override an existing hard-mandatory policy. The existing hard-mandatory policy would still block the run. This does not provide a controlled exception and could weaken governance unintentionally.

Create a new Sentinel policy with a higher priority that explicitly allows the operation, and add it to a policy set that applies to the workspace.

Why it fails: Sentinel policy sets do not have a numeric priority system that overrides hard-mandatory policies. Adding a permissive policy does not bypass an existing hard-mandatory failure; all policies in applied sets are evaluated, and any hard-mandatory failure blocks the run. This approach would not achieve the exception and could create confusion about policy precedence.

Use the HCP Terraform API to mark the specific run as an override, providing a reason that is stored in the audit log.

Why it fails: HCP Terraform does not provide a run-level override API for hard-mandatory Sentinel policies. Overrides are not a native feature; attempting to use an API endpoint that does not exist would fail. Auditability is maintained through other mechanisms, but this method is invalid and would not permit the operation.

hard-mandatory

Why it fails: hard-mandatory mode prevents the run from proceeding if the policy fails, and it cannot be overridden by any user. It provides the strongest enforcement but does not allow for a manual override, so it fails to meet the requirement for an operator to grant an exception.

audit-only

Why it fails: audit-only is not a valid enforcement mode for Sentinel policy sets in HCP Terraform. The available modes are advisory, soft-mandatory, and hard-mandatory. Choosing this would not configure any policy enforcement and would leave the run unaffected by the policy result.

advisory

Why it fails: advisory mode logs a warning when a policy fails but allows the run to continue automatically. It does not pause the run or require an operator to manually approve an override, so it cannot provide the control you need to review and potentially allow exceptions.

Assign the team the 'plan' permission on the development project.

Why it fails: The 'plan' permission only allows team members to view runs and plans, not to create or manage workspaces. It is too restrictive for the stated need, as developers must be able to create and manage workspaces, so it fails to meet the requirement.

Assign the team the 'admin' permission on the development project.

Why it fails: The 'admin' permission grants full control over the project, including deleting workspaces and modifying project settings. This is the opposite of the required restriction, as it would allow developers to perform actions that should be prevented, so it is incorrect.

Assign the team the 'write' permission on the development project.

Why it fails: The 'write' permission on a project grants the ability to create and manage workspaces, but it also includes the ability to delete workspaces and change project-level settings. This exceeds the required restriction, so it does not meet the goal of preventing deletions.

Modify the Sentinel policy code to check the project name and only enforce if it matches.

Why it fails: Sentinel policies evaluate the Terraform plan and state, not HCP Terraform organizational metadata like project names. The policy code cannot access the project name to conditionally enforce. Scoping is handled at the policy set level, not within the policy logic. This approach would not correctly apply the policy set only to a specific project.

Create a separate organization for each project and apply the policy set there.

Why it fails: Creating separate organizations is an overcomplicated and impractical approach for applying a policy set to a project. Organizations are top-level containers; projects exist within an organization. This method would fragment management and is not a valid or recommended way to scope policies to a project within a single organization.

Add a tag to the project and configure the policy set to match that tag.

Why it fails: While policy sets can be scoped by workspace tags, projects themselves do not have tags that policy sets can match. Policy set scoping uses workspace tags, not project tags. Projects are organizational containers, and policy sets can be directly associated with projects, but not via tags on the project. This method is not valid.

Define the variable in a 'terraform.tfvars' file in each workspace's VCS repository.

Why it fails: A 'terraform.tfvars' file in each repository would need to be maintained separately and does not leverage HCP Terraform's centralized variable management. It also does not automatically apply to all workspaces unless every repository includes the file. This approach bypasses the platform's governance features and is not scalable.

Use a Sentinel policy to inject the variable into each workspace during runs.

Why it fails: Sentinel policies are used for governance and cannot inject variables into Terraform runs. They evaluate plan data and enforce rules but do not modify configuration or provide variables. Using a policy for this purpose is technically impossible and misinterprets the role of Sentinel.

Add the variable directly to each workspace's variables page.

Why it fails: Adding the variable individually to each workspace is tedious and error-prone. It does not automatically apply to all workspaces in the project, especially when new workspaces are added. While it would work for existing workspaces, it fails the requirement of automatic availability across the project.

Attach a policy set to a run trigger.

Why it fails: Run triggers are used to automatically queue runs in one workspace when another workspace completes, not for applying policies. Policy sets cannot be attached to run triggers. This is a misapplication of the run trigger feature, which is unrelated to policy enforcement.

Attach a policy set to a variable set.

Why it fails: Variable sets are used to manage variables across workspaces, not policies. Policy sets and variable sets are separate constructs. You cannot attach a policy set to a variable set. This option confuses the two features, which serve entirely different purposes in HCP Terraform governance.

Attach a policy set to an organization, which applies to all workspaces in the organization.

Why it fails: While policy sets can be applied at the organization level, this is done by creating the policy set in the organization and then applying it to all workspaces via the organization's policy sets settings. However, the action of 'attaching' a policy set to an organization is not a direct scoping option; policy sets are attached to projects or workspaces. Organization-wide enforcement is achieved by applying to all projects or workspaces.

Sentinel policies can only be written in HashiCorp Configuration Language (HCL).

Why it fails: Sentinel is a separate language with its own syntax, designed for policy enforcement. It is not HCL. While HCL is used for Terraform configurations, Sentinel policies use a distinct language that supports complex logic, imports, and rule definitions. This statement misidentifies the language used for Sentinel policies.

Sentinel policies can be overridden by any user with write access to the workspace.

Why it fails: Override permissions are not granted by workspace write access. Only users with specific organization-level permissions, such as owners, can override soft-mandatory policies. Hard-mandatory policies cannot be overridden at all. This statement incorrectly assumes that workspace-level permissions are sufficient for policy overrides.

Sentinel policies are evaluated only after the apply phase completes.

Why it fails: Evaluating policies after apply would be too late to prevent non-compliant resources from being created. Sentinel policies are designed to run during the plan phase to block undesirable changes before they are applied. This statement contradicts the purpose of policy as code in HCP Terraform.

Sentinel policies that block delete operations on workspaces.

Why it fails: Sentinel policies evaluate Terraform plan data for infrastructure resources, not HCP Terraform workspace management actions. They cannot prevent deletion of workspaces themselves. While Sentinel can enforce rules on resources, it does not control platform-level permissions like workspace deletion.

Workspace locking to prevent any changes, including deletion.

Why it fails: Workspace locking prevents runs from modifying infrastructure but does not block administrative actions like deleting the workspace itself. A locked workspace can still be deleted by a user with permission. Locking is not a permission control for workspace lifecycle operations.

Organization-level variable sets that restrict deletion via environment variables.

Why it fails: Variable sets provide configuration values to Terraform runs; they cannot enforce permissions or prevent workspace deletion. Environment variables might influence provider behavior but have no authority over HCP Terraform's own API actions. This is not a valid method for access control.