Introduction
Understanding infrastructure automation terms is essential for managing systems effectively.
Our Terraform glossary simplifies complex concepts for smoother learning and improved knowledge of automation tools.
Terraform Terms
A
API: API stands for Application Programming Interface, which refers to any interface created to enable the automated manipulation of a software system. In today's software development landscape, HTTP-based APIs are the most prevalent. Terraform leverages cloud service provider APIs to oversee resources; each provider is tasked with translating Terraform's resource model into the necessary API calls for creating, verifying, adjusting, or removing actual infrastructure resources within the cloud service. Additionally, Terraform Cloud provides its own API for handling tasks such as team membership, policies, and workspaces. This API is utilized by the tfe Terraform provider, enabling users to utilize Terraform for managing the infrastructure that supports Terraform itself.
Apply (noun): During a Terraform run, the apply stage involves modifying real infrastructure resources to align with their specified state, which is the opposite of the plan stage. In Terraform's command-line interface (CLI), apply actions are executed using the terraform apply command, whereas Terraform Cloud performs apply operations using a plan file as input.
Apply (verb): To bring actual infrastructure into alignment with the desired state, as defined by a Terraform configuration and variables, changes are implemented. In discussion, the terms 'applying a plan' and 'applying a configuration' are frequently used, with the former typically referring to Terraform Cloud's workflow and the latter to the Terraform CLI workflow.
Argument: In Terraform's configuration language, an argument is a syntax element that assigns a value to a specific name. These arguments follow the format <IDENTIFIER> = <EXPRESSION> and are typically found within blocks. The majority of a Terraform configuration involves utilizing arguments to tailor Terraform resources. Each resource type specifies the arguments available for its resources, the valid values for each argument, and whether they are mandatory or optional. Detailed information about a particular resource type can be located in the documentation provided by the respective provider.
Attribute: In Terraform's configuration language, an attribute is a named data component associated with an object. These attribute values can be accessed in expressions using a dot-separated format, such as aws_instance.example.id. Attributes in Terraform resources and data sources expose all their arguments as accessible attributes, and often include extra read-only attributes for additional information.
B
Backend: The component within Terraform's core responsible for managing state storage and executing operations such as plan, apply, and import is known as the backend. Terraform offers a selection of backends that can be configured in different manners. Backends are distinct from plugins, meaning it is not feasible to install additional backends. In a broader computer science context, a backend typically refers to a foundational implementation supporting higher-level functionalities. However, within Terraform, 'backend' consistently refers to the internal code managing state and operations.
Blob Storage: A service that stores and retrieves data blocks using unique, non-transparent identifiers, which are organized within a directory structure, represents a blob storage system. A well-known instance is AWS's S3. While knowledge of blob storage services' properties and benefits is not required for Terraform or Terraform Cloud usage, it may be necessary to manage or configure a blob storage service if you are responsible for administering a Terraform Enterprise instance.
Block: In Terraform's configuration language, a block is a construct that encloses other content, often representing the configuration of an object, such as a resource. Blocks have a type, may or may not include labels, and encompass any number of arguments and nested blocks within their body. A majority of Terraform's functionalities are governed by top-level blocks in a configuration file.
Branch: In certain version control systems, a branch refers to a separate, semi-autonomous history of modifications to repository content. Branches typically share some history with other branches in the same repository, but at some point, they branch off to incorporate alterations not yet found elsewhere. A default branch, often named master in Git, is typically present in a repository, and successful changes are eventually integrated into it. Modern development workflows often involve topic branches for exploring, refining, and verifying specific changes, and may also include long-lived branches other than the default branch.
C
CI/CD: Continuous Integration/Continuous Delivery (CI/CD) platforms execute predetermined tasks, such as tests or builds, triggered by events like new commits in a project. This automation enhances the predictability, understanding, and efficiency of new releases. Additionally, infrastructure management, traditionally overseen by operations teams, can seamlessly integrate into an automated release process by leveraging infrastructure as code with Terraform.
CLI: Command-line interface (CLI). The terraform command operates within a CLI, such as a Unix shell or the Windows command prompt, to accept instructions and display text output. In discussions, 'Terraform CLI' often signifies the core Terraform Community edition binary, serving to differentiate it from other components of the Terraform ecosystem, such as Terraform Cloud or Terraform GitHub Actions.
Commit: In a version control system, a commit represents a cohesive set of changes that are saved to the version history of a repository. In Git, commits function as comprehensive snapshots of the repository's contents at a particular moment in time, on a specific branch or a group of branches with shared history. Each commit also references its parent(s), allowing for a complete view of the repository's history up to any given point. Furthermore, comparing a commit to its parent(s) can reveal the precise alterations introduced by that commit; applying these changes as a diff enables them to be incorporated into a different branch without merging the entire history of the commit.
(Terraform) Configuration: Additionally referred to as 'config', this is code written in Terraform's declarative configuration language, which outlines the desired state of your infrastructure. A comprehensive configuration, or 'config', encompasses a root module that can optionally include any number of child modules.
Configuration Version: Also known as 'config version', this term refers to the state of a Terraform configuration at a particular point in time. This concept is exclusive to Terraform Cloud, as the Terraform CLI does not track repeated runs of a specific configuration over time. Each phase of a run is associated with a distinct configuration version. Config versions can be automatically generated when new commits are merged into a workspace's repository, uploaded through the API, or created by executing 'terraform plan' or 'terraform apply' as a remote operation. The process of introducing a new config version is sometimes referred to as 'ingressing'.
Cost Estimation: During a run, Terraform Cloud calculates cost estimates for each resource identified in the plan after generating the plan file. The plan data is utilized to estimate costs for both previous and proposed resources, enabling the calculation of an estimated cost delta between the two. These results can be utilized in Sentinel policies.
D
Data Source: A configuration language construct similar to resources, data sources can be configured in Terraform. However, unlike resources, data sources do not create or manage infrastructure. Instead, they provide information about external objects in the form of readable attributes, which can be incorporated into a Terraform configuration. This feature enables the use of data defined outside Terraform or by another separate Terraform configuration. Data sources are executed by providers.
Deposed: This status pertains to a resource that has been designated for deletion but remains in both the Terraform state and infrastructure due to a previous apply error. Terraform intended to replace the existing resource with a new one by creating the new resource and then removing the existing resource, but an error occurred during the apply before the removal. Existing references to the resource point to the new resource, and Terraform is programmed to remove the deposed resource during the next apply. This scenario can only arise in resource configurations that include the lifecycle configuration block with the create_before_destroy argument set to true.
E
Expression: In Terraform's configuration language, an expression is a syntax element that denotes a value, either directly or by referencing and combining other values. These expressions are utilized as values for arguments or within other expressions. Before Terraform 0.12, [interpolation][] was the sole method for incorporating non-literal expressions in Terraform configurations; from version 0.12 onwards, expressions can be employed autonomously.
F
Fork: Also known as a "forked repository" or "forked repo," this refers to a version control system (VCS) repository that has been created by duplicating content and history from another repository. Various VCS providers handle forks differently, but typically a fork is owned by a different individual or organization than the original repository, and it often does not inherit all access permissions from the original. In Terraform Cloud, VCS repositories are extensively utilized, with the assumption that forks of a trusted repository may not be inherently trusted. Consequently, Terraform Cloud refrains from executing any code from external forks, thereby preventing speculative plans for pull requests from forks. In Terraform Enterprise, administrators have the option to enable speculative plans on pull requests from forks.
G
Git: A distributed version control system used to monitor changes in source code throughout software development. While primarily intended for facilitating collaboration among developers, it can also be employed to monitor changes in any collection of files.
H
HCL: The HashiCorp Configuration Language (HCL) is a structured configuration syntax that underpins Terraform's configuration language and serves as the configuration foundation for various other HashiCorp products. HCL defines the syntax used by Terraform for elements such as arguments, blocks, literal values, and expressions. However, the Terraform language encompasses more than just syntax; it includes built-in functions, Terraform-specific block types (e.g., resource and variable), and unique named values accessible within expressions, all of which are specific to Terraform's implementation.
I
ID: An identifier is a unique, opaque string associated with a specific object, containing no information about the object but used to retrieve information or perform actions via an API. In Terraform, resource types often have an ID attribute linking the state to the managed infrastructure resource. In Terraform Cloud, internal application objects like workspaces, users, policies, etc., can be identified by both a name and an opaque, permanent ID, which is sometimes referred to as an "external ID." These IDs are often available in the URL bar when viewing an object in Terraform Cloud's UI and are used in API endpoints instead of names, as names can change.
Infrastructure as Code: Infrastructure-as-Code (IaC) is a method of managing infrastructure by defining and configuring resources in files, rather than manually through a user interface. IaC can encompass various infrastructure resources, such as virtual machines, security groups, network interfaces, and more.
Ingress: The term "ingress" refers to the process of importing content into Terraform Cloud, typically a configuration version, but it can also include private module versions or other types of content. While not commonly used in documentation or the user interface, the term "ingress" can appear in API contexts or support conversations.
Input Variables: In Terraform, "variables" generally refer to input variables, which are key/value pairs used during a run. These variables allow for customization in Terraform modules, with the parent module providing a value for child modules and values for the root module being supplied during runtime. Terraform Cloud enables setting values for root input variables in a workspace, ensuring that all collaborators use the same values. Variable values can be marked as "sensitive" to become unreadable in the UI and API, and all variable values are securely managed by Vault.
Interpolation: Utilizing a specific placeholder to incorporate a calculated value within a string.
J
JSON: JSON stands for "JavaScript Object Notation," a widely used text-based data interchange format that can represent strings, numbers, booleans, null values, arrays, and objects/maps. Terraform and Terraform Cloud frequently interact with JSON data to utilize or provide APIs. Additionally, Terraform supports JSON as an alternative format for configurations.
L
Locking: Workspace locking functionality allows for the prevention of new runs from initiating in a specific workspace. Workspaces are automatically locked during an ongoing run and can also be manually locked.The remote backend in Terraform Cloud adheres to the lock status set in workspaces. Certain other Terraform backends can also enforce state locking during runs.
Log: The textual representation of actions performed during a run, such as the output generated when executing terraform plan.
M
Module: A Terraform module is a self-contained set of Terraform configurations that manages a group of related infrastructure resources. Other Terraform configurations can invoke a module to manage the resources described within that module. Modules specify input variables, which the calling module can set values for, and output values, which the calling module can utilize in expressions.
O
OAuth: OAuth is an open standard for authorization between internet applications using tokens. Terraform Cloud employs OAuth to establish a connection with your version control system (VCS) provider, typically requiring an id and secret from the VCS provider to grant access to Terraform Cloud and enable it to retrieve configuration data.
OAuth Client: A component that gathers the necessary configuration details for a Terraform Cloud organization to establish a connection with a particular VCS provider. An OAuth client requires an OAuth token to access data associated with a user or organization within the VCS provider. This client can be generated using an existing token from the VCS provider (limited to API-only and not available for all VCS providers), or it can be created with the specific information required by Terraform Cloud to request a token. Obtaining a token involves a user granting approval by clicking through and authorizing access with their VCS provider account.
OAuth Token: In Terraform Cloud, an "oauth-token" is an entity that links an OAuth token (as a secret string) with a persistent ID and metadata, including the applicable VCS provider and the VCS user who approved the token. This term is used to denote an entity that can be interacted with via the API.
Organization: Terraform Cloud's primary entity for managing access and organizing resources, typically representing a company or a department within a company. An organization encompasses a collection of workspaces, teams, Sentinel policies, and various settings. Users are added to an organization through teams.
Output Values:Outputs are data generated by a Terraform module, which can be presented to a user and/or utilized by other Terraform code.
OSS: "OSS" stands for "Open-Source Software." Terraform providers that are publicly accessible are open-source. HashiCorp products, including Terraform, are provided under a source-available license that permits extensive copying, modification, and redistribution. On the other hand, Terraform Cloud and Terraform Enterprise are proprietary commercial software that leverage Terraform and the available Terraform providers.
P
Permissions: Permission levels in Terraform Cloud refer to the specific access levels granted to users, which can be managed at the workspace and/or organization level. For instance, a user with "read" permissions for a workspace can view a list of runs but cannot approve a run, unlike a user with "write" permissions.
Plan (verb): The term "queue plan" refers to the initiation of a new run, which commences with the execution of a Terraform plan (noun).
Plan (noun): During this phase of a run, Terraform evaluates the current state of the managed infrastructure against the configuration and variables, identifies required changes to align the real state with the desired state, and provides a user-friendly summary. This process is the counterpart to an apply action.
In Terraform's command-line interface (CLI), plans are executed using the following commands:
terraform plan, This command performs a plan and can optionally generate a plan file, allowingterraform applyto execute the exact planned changes specified in the file.terraform apply, This command executes a plan and, upon user approval, immediately applies the planned changes.terraform destroy, This command is analogous toterraform apply, but it employs a desired state where none of the managed resources are present. If the plan is approved, the resources will be destroyed.
Plan File:The term .tfplan, "saved plan", or simply "plan" refers to a binary artifact that can be optionally generated by the terraform plan command. This artifact can be used by terraform apply to perform the exact changes decided during the planning phase. In Terraform Cloud, a saved plan is always utilized as input for an apply, ensuring that any changes executed during the apply stage were previously shown to the user after the plan, even if the configuration or variables were modified in the meantime.
Policy: Sentinel policies that can be enforced on runs and grouped into policy sets.
Policy Check: As a component of a run, Terraform Cloud executes Sentinel after collecting the configuration, state, and plan file to validate this data against active policies. The policy checks result in either success or failure. If a required policy fails, it can halt the run before reaching the apply stage.
Policy Set: A collection of Sentinel policies to be enforced globally or on specific workspaces.
Private Terraform Registry: The term "private module registry" refers to a built-in version of the Terraform Registry within Terraform Cloud, facilitating code sharing within an organization. It incorporates a configuration designer, which enables the combination and customization of modules to generate a Terraform configuration that utilizes them.
Private Terraform Enterprise (PTFE): Before mid-2019, "Terraform Enterprise" (TFE) was the name of the Terraform Cloud application, while "Private Terraform Enterprise" (PTFE) was the name of the on-premises distribution.
(Terraform) Provider: AnswerA Terraform plugin that offers a set of interconnected resources. Provider plugins in Terraform are responsible for interpreting API interactions with a particular service and exposing resources based on that API. These providers are typically associated with a specific infrastructure provider, which could be an infrastructure as a service (IaaS) provider such as AWS, GCP, Microsoft Azure, OpenStack, a platform as a service (PaaS) provider like Heroku, or a software as a service (SaaS) provider like Terraform Cloud, DNSimple, Cloudflare. While numerous providers are readily available, custom providers can also be developed to interface with any API.
Pull Request (PR): GitHub introduced a feature known as a "pull request" to review and discuss modifications made to a Git repository branch, which a user intends to merge into another branch. Collaborators can suggest changes, approve, or reject these changes. In informal settings, people often use the term "pull request" to refer to the review-before-merging workflow, even when working with a version control system provider that uses a different term (e.g., GitLab, which refers to this as a "Merge Request").
Q
Queue: The term "run queue" refers to the list of runs awaiting processing in Terraform Cloud. It employs multiple run queues, such as a per-workspace queue (to prevent conflicts and state corruption, only one run is allowed at a time in a specific workspace) and a global per-instance queue (due to finite compute resources and limited access to virtual machines).
R
(Terraform) Registry: The Terraform Registry is a collection of modules developed by the Terraform community. These modules can be directly utilized in a Terraform configuration or customized by forking them. This registry serves as a valuable resource for expediting your Terraform journey, offering insights into Terraform coding practices, and providing ready-made modules for the infrastructure components you need.
Remote Operations: The feature of initiating a run (or executing a few other tasks) from your local command-line interface (CLI) while displaying the output inline is known as remote operations. Although Terraform Cloud performs Terraform runs in its own transient virtual machines (VMs), enabling the capture of information and controlling access to secrets, many users are familiar with running Terraform on their local machines. Remote operations aim to bridge this gap by allowing users to run Terraform commands locally while benefiting from Terraform Cloud's capabilities.
Remote Backend: The Terraform CLI offers a feature called "remote backends," which enables Terraform to connect with Terraform Cloud. This is achieved by specifying the organization and workspace(s) to use in the Terraform configuration. Remote operations in Terraform Cloud workspaces and state storage in Terraform Cloud's free edition utilize this feature. In older documentation, backends like s3 or consul were referred to as "remote backends" since they stored Terraform's state in a remote service instead of the local filesystem. However, today, the term "remote backend" typically refers to the specific backend whose name is remote.
Repository: The term "repo" refers to a collection of files and a record of modifications managed by a version control system. In the context of Terraform Cloud, a "repo" typically denotes a Git repository that houses a Terraform configuration, while private modules are also built on Git repositories.
Resource: The term "infrastructure resource" encompasses various meanings within Terraform: In Terraform's configuration language, it refers to a block detailing one or more infrastructure objects. These resources can include virtual networks, compute instances, or more advanced components like DNS records. In other Terraform-related contexts, it denotes an infrastructure object that falls within the scope of management by Terraform.
Root Module:The root module signifies the starting point for Terraform's configuration evaluation. It comprises all the configuration files located in Terraform's working directory.
Root Outputs: The term "root-level outputs" refers to the output values of a configuration's root module. These outputs can be accessed by another configuration using the terraform_remote_state data source.
Run: A "Terraform Run" denotes the process of employing Terraform to align real infrastructure with the desired state, as defined by the configuration and variable values at a specific moment in time. In Terraform Cloud, runs progress through a sequence of stages, including plan, policy check, and apply, although not every stage is involved in every run. Terraform Cloud retains information about historical runs for future reference.
Run Triggers: Within Terraform Cloud, there is a feature that enables linking a specific workspace to one or multiple workspaces within an organization, referred to as "source workspaces." These connections, known as run triggers, facilitate the automatic queuing of runs in your workspace upon successful application of runs in any of the linked source workspaces.
S
S3: Amazon Web Services' "Simple Storage Service" (S3) is a cloud storage service designed for storing and retrieving various types of data in the form of arbitrary blobs. The Terraform aws provider is capable of managing S3 resources. Similarly, Terraform Enterprise can be configured to utilize an S3-compatible blob storage service for storage purposes when employing External Services.
SAML: SAML represents an XML-based standard for authentication and authorization. Terraform Enterprise can function as a service provider (SP) or Relying Party (RP) in conjunction with your internal SAML identity provider (IdP). It's important to note that the SAML Single Sign On feature is exclusively available on Terraform Enterprise, and it is not supported in the Terraform Cloud Software as a Service (SaaS) offering.
Sentinel: Sentinel is a language and runtime designed for managing policy as code, enabling users to establish rules governing operations within Terraform Cloud.
Site Admin: An individual responsible for administering a Terraform Enterprise instance, who possesses the ability to modify application settings that have an impact on all organizations utilizing the instance.
Speculative Plan: A speculative plan is a type of run that solely aims to display potential alterations to infrastructure based on a specific configuration version and set of variables. These plans are strictly for visualization purposes and cannot be executed. They are typically initiated in response to pull requests made to a workspace's repository or by running terraform plan with remote operations configured on the command line.
SSH Key: SSH keys serve as a form of access credential based on public key cryptography, primarily employed for logging into servers. Terraform Cloud utilizes SSH private keys for two primary purposes: Downloading private Terraform modules with Git-based sources during a Terraform run. These keys are assigned on a per-workspace basis. And, Transferring content from a connected version control system (VCS) provider into Terraform Cloud, often when incorporating a Terraform configuration for a workspace or importing a module into the private module registry. While not all VCS providers necessitate an SSH key, an SSH key is required if your repositories include submodules that are exclusively accessible via SSH (rather than the VCS provider's API).
State: Terraform maintains information about your managed infrastructure and configuration through a state mechanism. This state is essential for mapping real-world resources to your configuration consistently across runs, tracking metadata, and enhancing performance for large infrastructures. In the absence of state, Terraform lacks the ability to recognize the resources it created during previous runs. Therefore, when multiple individuals collaborate on shared infrastructure, it is crucial to store state in a shared location, such as a free Terraform Cloud organization.
Terraform maintains information about your managed infrastructure and configuration through a state mechanism. This state is essential for mapping real-world resources to your configuration consistently across runs, tracking metadata, and enhancing performance for large infrastructures. In the absence of state, Terraform lacks the ability to recognize the resources it created during previous runs. Therefore, when multiple individuals collaborate on shared infrastructure, it is crucial to store state in a shared location, such as a free Terraform Cloud organization.
State Version: A representation of your infrastructure's state at a given moment is referred to as a state snapshot. This snapshot can be manually uploaded to Terraform Cloud or generated as a result of an apply.It's important to note that the Terraform CLI does not incorporate any concept of historical state data; it only interacts with the most recent state and generates a snapshot of the new state in the configured backend following modifications. The system that the backend writes to determines whether to preserve previous state; Terraform Cloud retains historical snapshots, and certain other backends (like S3) can also be configured to do so. However, the local backend does not.
T
Team: A Terraform Cloud user group, known as a "team," can be granted authorization to access and/or modify various resources (workspaces, policies, etc.) within an organization. Each team is associated with a single organization, while users can be part of any number of teams across multiple organizations.
Terraform: Terraform is a versatile tool designed for constructing, modifying, and versioning infrastructure in a secure and efficient manner. It has the capability to oversee a wide range of established service providers along with custom in-house solutions.
Terraform Cloud: Terraform Cloud is an application that facilitates collaborative Terraform utilization among teams. It offers a consistent environment for Terraform runs and hosts Terraform state and other shared data. Terraform Cloud is accessible as a hosted service at https://app.terraform.io. Additionally, it is available in an on-premises distribution known as Terraform Enterprise. Before mid-2019, the on-premises distribution was identified as "Private Terraform Enterprise" (PTFE), and the Terraform Cloud application was named "Terraform Enterprise" (TFE).
Terraform Enterprise: Terraform Enterprise is an on-premises distribution of Terraform Cloud, which empowers large enterprises to operate their own private instance of the application. Before mid-2019, the Terraform Cloud application was recognized as "Terraform Enterprise" (TFE), and the on-premises distribution was known as "Private Terraform Enterprise" (PTFE).
Terraform Version: A specific edition of the terraform binary designated for utilization within Terraform Cloud workspaces. It defines a URL, a SHA256 checksum, and flags for enabling or marking it as beta. Administrators on the platform can set up the accessible Terraform versions for a Terraform Enterprise instance.
TFE Provider / Terraform Cloud Provider:A Terraform provider that administers Terraform Cloud, enabling management of Terraform Cloud via a Terraform configuration.
(API) Token: A revocable secret string, known as a Terraform Cloud API token, serves to authenticate a user for the purpose of utilizing Terraform Cloud's API or the remote backend. Different types of tokens confer distinct permissions. Tokens can be granted at the user, team, or organization level. While numerous applications, including Terraform Cloud, employ token-based authentication, within Terraform Cloud's documentation and user interface, the term "token" typically refers to a Terraform Cloud API token.
Trigger: An event that initiates a new run to be queued. Runs can be triggered by user interface (UI)/version control system (VCS) actions, such as a new VCS commit or a UI interaction, API calls, or command-line interface (CLI) commands.
V
VCS: A Version Control System (VCS), such as Git, is a software tool that records modifications to a set of files over time, enabling users to monitor changes, revert modifications, and merge concurrent alterations made by multiple users. VCS is commonly employed for any significant coding endeavor, including infrastructure as code. Different VCS systems employ distinct models for tracking history. For instance, Git models changes as a directed acyclic graph of commits, and parallel changes originating from the same parent commit result in diverging branches, which might be merged together at a later stage.
VCS Provider: A particular platform that offers VCS functionalities, aiming to facilitate team collaboration on code. Terraform Cloud can interface with VCS providers to access your Terraform configurations and modules, currently supporting GitHub, GitHub Enterprise, GitLab.com, GitLab Enterprise Edition (EE) and Community Edition (CE), Bitbucket Cloud, Bitbucket Data Center, Azure DevOps Server, and Azure DevOps Services.
W
Webhook: A server-to-server HTTP communication where one system notifies another system of a change in its internal state. The recipient system of a webhook can respond by providing information back, triggering additional webhooks, executing actions silently, or disregarding the request entirely. Terraform Cloud utilizes webhooks in various ways, notably by setting up webhook configurations on VCS providers. This setup ensures that VCS providers send webhook requests to Terraform Cloud whenever linked repositories receive pull requests or new commits (as detailed in Terraform Cloud documentation: UI/VCS-driven Runs). Additionally, users have the ability to configure webhooks on Terraform Cloud workspaces, enabling Terraform Cloud to dispatch run notification webhooks to platforms like Slack or other external services (as outlined in Terraform Cloud documentation: Run Notifications).
Working Directory: The location where the terraform init command is executed, resulting in the creation of a .terraform subdirectory. It is essential to run all subsequent commands related to the same configuration from this specific working directory. The root module encompasses all configuration files located at the top level of Terraform's working directory. Additionally, subdirectories within the working directory can house child modules.
Workspace: Within the Terraform CLI, a workspace denotes a segregated entity of state data. Employing multiple workspaces enables the management of distinct, non-overlapping infrastructure sets from a unified configuration within a single working directory.In Terraform Cloud, a workspace embodies a comprehensive entity encompassing all elements essential for overseeing a specific collection of infrastructure resources across time. This includes: A Terraform configuration (with multiple versions over time, sourced from a repository or manual uploads), A collection of variables, State data reflecting the present and past state of the infrastructure, and Historical data pertaining to runs.