Terraform Associate Exam Cram - Part 8

This is the Part 8 of the Terraform Associate 004 Exam Cram. It covers the following Terraform Associate Certification exam objectives:

< Prev: Objective 7 - Maintain infrastructure with Terraform

HCP Terraform (HashiCorp Cloud Platform Terraform) is a cloud-based service for managing Terraform deployments in secure and collaborative environment. It provides:

• Remote operations - Terraform runs in secure cloud environment.
• Remote state storage - shared, versioned, encrypted.
• State locking - prevents concurrent modifications in team settings.
• Run history.
• Audit logging.
• Policy enforcement with Sentinel or OPA.
• Private registry for sharing modules and providers.
• Integration with version control systems (VCS).
• Workspaces - isolated environments.
• Cost estimation - preview cloud costs before apply.
• Integration with security, compliance, and validation tools.
• Automated drift detection.

HCP Terraform is available in several tiers or plans - Free, Essentials, Standard, Premium, and Enterprise (Self-Managed) which mainly differ by pricing, scalability, governance, and collaboration features. While all plans support core Terraform functionality (e.g., remote runs, state management, and VCS integration), advanced capabilities like team-based access control, policy enforcement (Sentinel), audit logging, and larger resource limits are only available in higher-tier or Enterprise plans.

Remote Operations

HCP Terraform is designed as an execution platform for Terraform, and can perform Terraform runs on its own disposable virtual machines. Remote runs can be initiated by webhooks from your VCS provider, by UI controls within HCP Terraform, by API calls, or by Terraform CLI. When using Terraform CLI to perform remote operations, the progress of the run is streamed to the user's terminal, to provide an experience equivalent to local operations.

Execution Modes

HCP Terraform supports the following execution modes:

• Organization Default: Uses the organization's execution mode. This is either Remote or Local.
• Remote: Plan and apply operations run on HCP Terraform's or Terraform Enterprise's infrastructure. You and your team have the ability to review and collaborate on runs within the application.
• Local: Plan and apply operations run on machines that you control. HCP Terraform and Terraform Enterprise only store and synchronize state.
• Agent: Plan and apply operations that your agent executes are managed by HCP Terraform or Terraform Enterprise.

Workspaces

HCP Terraform always performs Terraform runs in the context of a workspace. The workspace serves the same role that a persistent working directory serves when running Terraform locally: it provides the configuration (managed as a series of configuration versions), state, as well as input and environment variables for the run.

Note: HCP Terraform workspaces and Terraform CLI workspaces function differently. Terraform CLI workspaces are associated with a specific working directory and isolate multiple state files in the same working directory, allowing to manage multiple groups of resources or environments with a single configuration.

Projects

Projects organize workspaces into groups. Every workspace must belong to exactly one project. By default, all workspaces belong to an organization's Default Project. The Default project can be renamed, but cannot be deleted.

A workspace is assigned to a project at the time of creation and can be moved to a different project at any time.

Workflows

HCP Terraform supports the following workflows:

• UI/VCS-driven run workflow: HCP Terraform fetches your configuration from your version control repository and automatically starts plan and apply operations whenever you make changes to the repository. This keeps your repository as the single source of truth for the workspace.
• CLI-driven run workflow: Use your local Terraform CLI to start remote operations in HCP Terraform. HCP Terraform runs the operation and manages the state file.
• API-driven run workflow: Use the HCP Terraform API to upload Terraform configuration changes and manage Terraform operations.

Back to Top

HCP Terraform is designed for team-based infrastructure management. It includes the following collaboration and governance features.

Teams

Teams are groups of HCP Terraform users within an organization. If a user belongs to at least one team in an organization, they are considered a member of that organization.

Every organization has an Owners team whose members have the maximum available permissions within the organization. This includes all organization-level permissions and the highest level of permissions on every workspace.

Teams can be used to:

• manage access to workspaces, projects, and organization,
• configure notification via Slack / Microsoft Teams / Email.

Team management is available in HCP Terraform Essentials, Standard, and Premium editions.

Projects

Projects let you organize your workspaces and Stacks and scope access to those workspace and Stack resources.

Each project has a separate permissions set that you can use to grant teams access to all workspaces and Stacks in the project, defining access control boundaries for teams and their resources. Project-level permissions are more granular than organization-level permissions, but more specific than individual workspace-level grants.

Projects are available to all users, but managing project permissions requires HCP Terraform Essentials, Standard, or Premium edition.

Explorer

The Explorer improves workspace visibility and helps discover a wide range of valuable information from across your organization. The Explorer page displays buttons grouped by Types and Use Cases. Each button offers a detailed view into your organization or workspace's data. In addition, the explorer's query builder allows you to execute queries with custom filter conditions and save the resulting views.

Health

HCP Terraform can perform automatic health assessments in a workspace to assess whether its real infrastructure matches the requirements defined in its Terraform configuration. Health assessments include the following types of evaluations:

• Drift detection determines whether your real-world infrastructure matches your Terraform configuration (configuration drift).
• Continuous validation determines whether custom conditions within the check blocks in the workspace's configuration continue to pass after Terraform provisions the infrastructure.

Health assessments are available in HCP Terraform Standard and Premium editions.

Private Registry

HCP Terraform's private registry works similarly to the public Terraform Registry and helps you share Terraform providers and Terraform modules across your organization. It includes support for versioning and a searchable list of available providers and modules.

HCP Terraform allows users to create and confidentially share infrastructure modules within an organization using the private registry. With Terraform Enterprise, the private registry allows you to share modules within or across organizations.

Modules from the private registry can be referenced using a registry source address of the form app.terraform.io/<ORGANIZATION-NAME>/terraform/<NAME>/<PROVIDER>.

Change Requests

Change requests are a way to create a backlog of action items recorded on a workspace, enabling administrators to notify teams directly if a workspace requires action. New change requests can be created directly from explorer queries on workspace data.

Workspaces manage and track their change requests directly, and team members can archive a change request once they've completed that request’s task.

Change requests are available in the HCP Terraform Standard and Premium editions.

Policy Enforcement

Policies are rules that HCP Terraform enforces on Terraform runs. You can use two policy-as-code frameworks to define fine-grained, logic-based policies: Sentinel and Open Policy Agent (OPA).

• Sentinel: You define policies with the Sentinel policy language and use imports to parse the Terraform plan, state, and configuration.
• OPA: You define policies with the Rego policy language.

A policy consists of:

• The policy controls defined as code.
• An enforcement level that determines run behavior in the event of policy failure.

Policy sets are a named grouping of policies and their enforcement levels. Each policy set can apply to specific workspaces, or to all workspaces within an organization. Policy sets are the mapping between policies and workspaces.

Enforcement levels establish whether or not an operation can proceed if a policy fails. Sentinel provides three enforcement levels:

• Hard-mandatory requires that the policy passes. If a policy fails, the run stops. You must resolve the failure to proceed.
• Soft-mandatory lets an organization owner or a user with override privileges proceed with the run in the event of failure. HCP Terraform logs all overrides.
• Advisory will notify you of policy failures, but proceed with the operation.

OPA provides two enforcement levels:

• Advisory: Failed policies never interrupt the run. They provide information about policy failures in the UI.
• Mandatory: Failed policies stop the run, but any user with Manage Policy Overrides permission can override these failures and allow the run to complete.

HCP Terraform Free edition includes one policy set of up to five policies. In HCP Terraform Standard and Premium editions, you can connect a policy set to a version control repository or create policy set versions with the API.

Policy publishing workflows:

• HCP Terraform web UI: Add individually-managed policies manually in the HCP Terraform UI, and store your policy code in HCP Terraform.
• Version control: Connect HCP Terraform to a version control repository containing a policy set. When you push changes to the repository, HCP Terraform automatically uses the updated policy set.
• Automated: Push versions of policy sets to HCP Terraform with the HCP Terraform Policy Sets API or the tfe provider tfe_policy_set resource. This workflow is ideal for automated Continuous Integration and Deployment (CI/CD) pipelines.

Back to Top

HCP Terraform workspaces

• Workspace contain one Terraform configuration and can integrate with version control systems to automatically trigger runs on commit.
• Each workspace has its own dedicated state file, managed by HCP Terraform.
• They include workspace-specific variables (environment and Terraform variables), credentials, and secrets.
• Manage Terraform runs and retain detailed history and logs.
• Support role-based access control (RBAC) for fine-grained team permissions.
• Workspaces can be organized into projects for better grouping and management.

Terraform Version

Each HCP Terraform workspace has an assigned Terraform version that it uses for all remote operations in the workspace.

When you create a new workspace, HCP Terraform automatically selects the most recent version of Terraform available. HCP Terraform lets you change the version a workspace uses on the workspace's settings page to control how and when your projects use newer versions of Terraform.

Projects organize workspaces into groups. Every workspace must belong to exactly one project. By default, all workspaces belong to an organization's Default Project. The Default project can be renamed, but cannot be deleted.

A workspace is assigned to a project at the time of creation and can be moved to a different project at any time.

Workspace Variables

HCP Terraform workspace variables store configuration values used during Terraform runs. Common use cases include defining environment-specific inputs, setting static credentials, or securely managing dynamic provider credentials.

There are two types of HCP Terraform variables: environment variables and Terraform variables (also known as input variables).

Variables can be set specifically for each workspace or groupped into variable sets to share the same variables across multiple workspaces.

Each environment and Terraform variable can have one of the following scopes:

• Workspace run-specific - Applies to a specific run within a single workspace. You can set run-specific Terraform variable values by:
  • Specifying -var and -var-file arguments.
  • Creating local environment variables prefixed with TF_VAR_.
• Workspace-Specific - Applies to a single workspace.
• Workspace-Scoped Variable Set - Applies to multiple workspaces within the same organization.
• Project-Scoped Variable Set - Automatically applied and available to all current and future workspaces and stacks within a project.
• Global Variable Set - Automatically applied to all current and future workspaces and stacks within an organization.

Note: HCP Terraform does not evaluate workspace variables or variable sets in local execution mode.

Sensitive Values

You can mark any Terraform or environment variable as sensitive data by clicking its Sensitive checkbox that is visible during editing. Marking a variable as sensitive makes it write-only and prevents all users (including you) from viewing its value in the HCP Terraform UI or reading it through the Variables API endpoint.

It is recommended to pass credentials to Terraform as environment variables instead of Terraform variables when possible, since Terraform runs receive the full text of all Terraform variable values, including sensitive ones.

An alternative to passing static credentials for some providers is to use dynamic credentials which allows for using temporary per-run credentials and eliminates the need to manually rotate secrets.

Dynamic Credentials

HCP Terraform's dynamic provider credentials let you establish a trust relationship between HCP Terraform and your cloud provider. When you use dynamic credentials, HCP Terraform begins each run by authenticating with your cloud provider, passing it details about the workload, including your organization and workspace name. Your cloud provider then responds with temporary credentials which HCP Terraform uses to provision your resources for the run. This workflow is based on the OpenID Connect protocol (OIDC), an open source standard for verifying identity across different systems.

Using dynamic credentials in a workspace requires the following steps for each cloud platform:

• Set up a Trust Relationship: You must configure a relationship between HCP Terraform and the other cloud platform
• Configure Cloud Platform Access: You must configure roles and policies for the cloud platform to define the workspace’s access to infrastructure resources.
• Configure HCP Terraform: You must add specific environment variables to that workspace to tell HCP Terraform how to authenticate to the other cloud platform during plans and applies. Each cloud platform has its own set of environment variables to configure dynamic credentials.

The process for each step is different for each cloud platform. Refer to the cloud platform configuration instructions for full details.

Run Triggers

HCP Terraform provides a way to connect your workspace to one or more workspaces within your organization, known as "source workspaces". These connections, called run triggers, allow runs to queue automatically in your workspace on successful apply of runs in any of the source workspaces. You can connect each workspace to up to 20 source workspaces.

A common way to share information between workspaces is the terraform_remote_state data source, which allows a Terraform configuration to access a source workspace's root-level outputs.

Back to Top

The Terraform CLI integration with HCP Terraform lets you use HCP Terraform and Terraform Enterprise on the command line. Using HCP Terraform through the command line is called the CLI-driven run workflow. When you use the CLI workflow, operations like terraform plan or terraform apply are remotely executed in HCP Terraform's run environment by default, with log output streaming to the local terminal. This lets you use HCP Terraform features within the familiar Terraform CLI workflow.

To connect Terraform CLI to HCP Terraform:

• Provide credentials to HCP Terraform.
• Define connection settings in your Terraform configuration.
• Initialize the working directory.
• Migrate state data (optional).

Credentials

The terraform login [hostname] command obtains an API token for HCP Terraform, Terraform Enterprise, or other host that offers Terraform services. Use this command only in interactive scenarios.

If no hostname is provided, the default hostname is app.terraform.io (HCP Terraform).

If not overridden by credentials helper settings in the CLI configuration, the terraform login command writes credentials to local file .terraform.d/credentials.tfrc.json.

The terraform logout [hostname] command removes locally-stored credentials for specified hostname.

For unattended automated deployments configure credentials manually in the CLI configuration file (.terraformrc or terraform.rc):

• credentials - configures credentials for use with HCP Terraform or Terraform Enterprise.
• credentials_helper - configures an external helper program for the storage and retrieval of credentials for HCP Terraform or Terraform Enterprise.

Alternatively, use a host-specific environment variable to provide an API token. Environment variable names should have the prefix TF_TOKEN_ added to the domain name, with periods encoded as underscores. For example, the value of a variable named TF_TOKEN_app_terraform_io will be used when the CLI makes service requests to the hostname app.terraform.io.

Connection Settings

Add a cloud block nested within the top-level terraform block to your Terraform configuration and configure the connection settings to link the working directory to HCP Terraform workspaces.

The following should be taken into account when configuring cloud blocks:

• A configuration can only provide one cloud block.
• A cloud block cannot be used with state backends. A configuration can use one or the other, but not both.
• A cloud block cannot refer to named values (e.g., input variables, locals, data source attributes).

Instead of hardcoding connectivity details in the configuration, you can alternatively use the following environment variables:

• TF_CLOUD_ORGANIZATION
• TF_WORKSPACE
• TF_CLOUD_PROJECT
• TF_CLOUD_HOSTNAME
• TF_TOKEN_<host_name>

If the configuration uses remote backend, replace backend "remote" with cloud in the terraform block. Terraform will continue to use the same set of HCP Terraform workspaces.

Initialization and State Migration

Run the terraform init command to initialize the working directory.

If you configure the workspaces block to use a project that does not yet exist in your organization, HCP Terraform will attempt to create a new project with that name when you run terraform init.

If the directory has an existing state file associated with a backend configuration, Terraform prompts you to migrate state from any existing workspaces.

Terraform will also prompt you to create one or more new HCP Terraform workspaces if no workspaces matching the workspaces block specs exist in your organization.

By default, Terraform uploads a copy of Terraform configurations stored in the working directory when you run the terraform plan or terraform apply command, but you can add a .terraformignore file to the directory and specify files to exclude form uploading to HCP Terraform.

If this file is not present, Terraform still excludes by default .git/ directories and .terraform/ directories (exclusive of .terraform/modules). The rules for defining .terraformignore are based on .gitignore files.

Related CLI Commands

terraform init -ignore-remote-version - A option used for HCP Terraform and the remote backend only. Set this to ignore checking that the local and remote Terraform versions use compatible state representations, making an operation proceed even when there is a potential mismatch.

terraform workspace - create new, list, show, select and delete Terraform workspaces.

Back to Top

Back to Top

More Terraform Tutorials:
Terraform Associate Exam Cram
Understanding Terraform Variable Precedence
Terraform Value Types Tutorial
Terraform count Explained with Practical Examples
Terraform for_each Tutorial with Practical Examples
Exploring Terraform dynamic Blocks with GCP Examples
Working with External Data in Terraform
Terraform Modules FAQ