Back to HashiCorp Certified: Terraform Associate (TA-004)

HCP Terraform

Use HCP Terraform (formerly Terraform Cloud) for collaboration, governance, and enterprise workflows.

This domain covers HashiCorp Cloud Platform (HCP) Terraform, formerly known as Terraform Cloud and Terraform Enterprise. It includes using HCP Terraform to create infrastructure, understanding collaboration and governance features like remote execution and policy as code, organizing and using workspaces and projects, and configuring local Terraform to integrate with HCP Terraform.
5 minutes 5 Questions

HCP Terraform (formerly known as Terraform Cloud) is HashiCorp's managed service platform that provides a collaborative environment for teams to use Terraform effectively. It offers a centralized workflow for infrastructure as code management, making it easier for organizations to adopt and scale t…

Concepts covered: HCP Terraform overview, Remote execution in HCP Terraform, HCP Terraform runs and applies, Team collaboration features, Run triggers and notifications, Policy as Code with Sentinel, Cost estimation features, HCP Terraform workspaces, Workspace variables and settings, Projects for workspace organization, Workspace execution modes, Configuring the cloud block, CLI-driven runs with HCP Terraform, VCS integration and workflows, API tokens and authentication

Test mode:
Start practice test
TA-004 - HCP Terraform Example Questions

Test your knowledge of HCP Terraform

Question 1

Scenario: ByteWave Technologies manages a Terraform Cloud organization that has grown to 175 workspaces over the past year. The company operates three distinct business segments: B2B Enterprise, Consumer Mobile, and IoT Devices. Each segment has dedicated engineering teams with different deployment cadences - B2B Enterprise deploys weekly with extensive approval workflows, Consumer Mobile deploys daily, and IoT Devices has bi-weekly firmware update cycles. The operations manager reports that the current organization structure creates confusion during incident response because on-call engineers cannot quickly determine which workspaces belong to which business segment. Last quarter, variable set updates intended for Consumer Mobile accidentally propagated to IoT Devices workspaces because both shared similar workspace naming patterns. The engineering leadership wants to implement a structure where variable sets can be scoped to specific business segments, on-call engineers can filter workspaces by segment during incidents, and team permissions can be managed at the segment level rather than workspace-by-workspace. Which implementation approach should ByteWave Technologies pursue to achieve segment-scoped variable management, improved workspace filtering, and consolidated permission management?

Correct Answer: Create three Projects aligned to business segments, move existing workspaces into their respective Projects, associate variable sets at the Project level, and configure team permissions on each Project

The correct approach is to create three Projects aligned to business segments (B2B Enterprise, Consumer Mobile, and IoT Devices), move existing workspaces into their respective Projects, associate variable sets at the Project level, and configure team permissions on each Project.

This solution directly addresses all three requirements outlined in the scenario:

  1. Segment-scoped variable management: By associating variable sets at the Project level, ByteWave can ensure that variable updates intended for one business segment (like Consumer Mobile) will only affect workspaces within that specific Project. This prevents the accidental cross-segment variable propagation issue they experienced when Consumer Mobile updates affected IoT Devices workspaces.

  2. Improved workspace filtering: Terraform Cloud Projects provide a natural organizational boundary that allows on-call engineers to quickly filter and identify workspaces by business segment during incidents. This solves the confusion reported by the operations manager.

  3. Consolidated permission management: Project-level team permissions allow engineering leadership to manage access at the segment level rather than configuring permissions workspace-by-workspace across 175 workspaces.

The approach of maintaining variable sets at workspace level rather than Project level defeats the purpose of segment-scoped variable management. The scenario specifically identifies that workspace-level granularity led to the accidental variable propagation problem.

Using a single Project with tags and organization-level variable sets does not provide the isolation needed between business segments. Organization-level variable sets would still apply across all segments, and tag-based filtering doesn't provide the same permission management capabilities as Projects.

Organizing Projects by deployment cadence (weekly/daily/bi-weekly) rather than business segment misaligns the structure with the actual business needs. The issue isn't about deployment frequency - it's about business segment ownership, incident response clarity, and preventing cross-segment variable contamination. Different teams own different segments, and the organizational structure should reflect that ownership.

Question 2

Scenario: MedTech Industries runs a healthcare platform using Terraform Cloud with 85 workspaces. The organization has four distinct departments: Clinical Systems, Research & Development, Administrative Operations, and Patient Portal. Each department has a dedicated infrastructure team, and the company recently hired a new CTO who requires monthly reports showing which department owns which infrastructure resources. Currently, all workspaces exist at the organization root level with a naming convention like 'clinical-prod-api' and 'research-dev-database'. The compliance officer has flagged that access reviews are becoming increasingly complex because workspace permissions are granted individually, making it difficult to verify that only authorized personnel can access sensitive clinical infrastructure. The infrastructure director wants to streamline permission management so that granting a new team member access to all departmental workspaces can be accomplished through a single configuration change. What organizational restructuring should MedTech Industries implement to address ownership visibility, simplified access management, and departmental grouping requirements?

Correct Answer: Create four Projects corresponding to each department and migrate existing workspaces into their respective Projects, then assign team permissions at the Project level for streamlined access control

The correct answer is to create four Projects corresponding to each department and migrate existing workspaces into their respective Projects, then assign team permissions at the Project level for streamlined access control.

This solution addresses all three requirements outlined in the scenario:

  1. Ownership Visibility: Projects in Terraform Cloud provide a hierarchical organizational structure that clearly groups workspaces by department. The CTO's monthly reports can easily show which department owns which infrastructure by looking at Project membership.

  2. Simplified Access Management: The key requirement from the infrastructure director is to accomplish access grants through a single configuration change. Project-level permissions allow teams to be granted access to all workspaces within a Project at once. When a new team member joins, assigning them to a team with Project-level permissions automatically grants access to all workspaces in that Project.

  3. Departmental Grouping: Projects are specifically designed to logically group related workspaces, making them perfect for organizing the 85 workspaces by department (Clinical Systems, Research & Development, Administrative Operations, and Patient Portal).

The second option suggests using Projects but then recommends configuring workspace-level permissions. This defeats the purpose of simplified access management because permissions would still need to be managed individually per workspace, which doesn't solve the compliance officer's concern about complex access reviews.

The third option relies only on tagging and workspace-level variable sets. While tags help with reporting, they don't provide the permission inheritance that Projects offer. Access management would remain complex with individual workspace permissions.

The fourth option of creating separate organizations is overly complex and introduces unnecessary administrative overhead. Cross-organization workspace sharing adds complexity rather than simplifying management, and it fragments the company's infrastructure governance unnecessarily.

Question 3

A software consulting firm uses Terraform Cloud to manage infrastructure for multiple clients. They have a 'shared-services' workspace that provisions common monitoring and logging resources, with run triggers configured to three client workspaces: 'client-alpha', 'client-beta', and 'client-gamma'. The operations manager wants to set up notifications so their external ticketing system receives HTTP callbacks whenever a triggered run in any of the downstream client workspaces encounters a Sentinel policy failure. They configured a webhook notification on the 'shared-services' workspace with the 'Run Errored' event type, expecting it to capture policy failures across all triggered workspaces. After a policy check failure occurs in 'client-beta', the ticketing system does not receive any callback. The operations manager is confused because the run trigger successfully initiated the run in 'client-beta'. What explains why the ticketing system did not receive the callback when 'client-beta' experienced a policy failure?

Correct Answer: Webhook notifications are workspace-specific and must be configured on each workspace where events need to be captured, so the 'client-beta' workspace needs its own webhook configuration

Webhook notifications are workspace-specific and must be configured on each workspace where events need to be captured, so the 'client-beta' workspace needs its own webhook configuration.

In Terraform Cloud, notification configurations (including webhooks) are scoped to individual workspaces. When you configure a webhook notification on the 'shared-services' workspace, it will only send notifications for events that occur within that specific workspace - not for events in other workspaces, even if those workspaces are connected via run triggers.

Run triggers establish a relationship where a successful run in a source workspace can automatically trigger runs in downstream workspaces, but this does not extend the notification scope. Each workspace maintains its own independent notification configuration. When 'client-beta' experiences a policy failure, that event occurs within the 'client-beta' workspace context, not the 'shared-services' workspace.

To receive callbacks for policy failures across all client workspaces, the operations manager needs to configure webhook notifications on each of the downstream workspaces ('client-alpha', 'client-beta', and 'client-gamma') individually.

The other answers are incorrect:

  • There is no separate 'Policy Check Failed' event type in Terraform Cloud notifications. Policy failures that cause a run to fail would fall under run error events, but this is irrelevant because the notification was configured on the wrong workspace.

  • Run triggers do not create any 'isolated notification context' or batch events. This is not how Terraform Cloud's notification system works.

  • Webhook notifications on a source workspace do not capture downstream workspace events at all. The 'Needs Attention' event type exists but it wouldn't solve the fundamental issue that notifications are workspace-scoped.

More HCP Terraform questions
447 questions (total)
Start 100 question test