2.3 Multi-Cloud, Hybrid, and Service-Agnostic Workflows

2.3 Multi-Cloud, Hybrid, and Service-Agnostic Workflows

Quick Answer: Terraform is not a cloud. It is a workflow (init / plan / apply), a state file, and provider plugins that call each vendor's API. That design is how one HCL codebase can drive AWS, Azure, Google Cloud, Kubernetes, SaaS products, and on-prem systems such as VMware/vSphere. The workflow is cloud-agnostic; the resource types are still vendor-specific. There is no universal virtual_machine that works everywhere.

Objective 1c on Terraform Associate (004) asks you to explain how Terraform manages multi-cloud, hybrid cloud, and service-agnostic workflows. This is the "why Terraform instead of only CloudFormation or only Bicep" question, and it is also the "Terraform is not itself a hypervisor or a public cloud" question. HashiCorp's 004 content list points this objective at the multi-cloud deployment use case and the core intro material.

Why this matters on Terraform Associate (004)

The exam wants a precise claim: Terraform gives you one language and one workflow across many APIs. It does not give you one resource type that abstracts every vendor into a lowest-common-denominator VM. Candidates who oversell "cloud-agnostic" as "write once, run on any cloud without changing resources" get that item wrong.

This still matters on Terraform 1.12. Provider installation and version constraints are later objectives (2a–2c). For 1c you only need the architectural picture: providers are how Terraform reaches each API; the workflow does not change when the API does.

Terraform is workflow, state, and providers—not a cloud

The three pieces

Terraform creates and manages resources on cloud platforms and other services through their APIs. Providers are the plugins that know each API. HashiCorp and the community have published thousands of providers on the Terraform Registry, including Amazon Web Services, Azure, Google Cloud Platform, Kubernetes, Helm, GitHub, Splunk, and Datadog. If a service exposes an API, someone can write a provider for it; you can write your own.

So the product is three pieces working together:

1. Workflow — initialize the working directory (install providers), plan the delta, apply the plan. Destroy is the same workflow aimed at teardown.
2. State — the mapping of configuration addresses to real objects, including objects that live in different clouds or in a datacenter.
3. Provider plugins — the per-vendor implementations that perform create, read, update, and delete against each API.

Same language across editions

Terraform Community Edition, HCP Terraform, and Terraform Enterprise all use this same Terraform language. HCP Terraform is the current name of HashiCorp's hosted SaaS (it was previously marketed as Terraform Cloud). It runs Terraform in a remote environment and stores state and secrets; it does not invent a second configuration language. Terraform Enterprise is the self-hosted distribution of that collaboration product. For objective 1c, remember: edition changes where Terraform runs and how teams share state; it does not change the multi-cloud idea.

One workflow against many platforms

A single configuration can declare an AWS VPC, an Azure DNS zone, a Google service account, a Kubernetes deployment, a Datadog monitor, and an Okta application. You still run:

• terraform init — download each required provider plugin (and modules).
• terraform plan — refresh state, walk the graph, show creates, updates, and destroys across all of those providers.
• terraform apply — execute the plan in dependency order, including cross-cloud dependencies (for example, write an Azure DNS record whose value is an AWS load-balancer hostname).

That is HashiCorp's multi-cloud pitch in exam form. Provisioning infrastructure across multiple clouds can increase fault tolerance, but it adds complexity because each provider has its own interfaces, tools, and workflows. Terraform does not erase those interfaces. It lets you manage them with the same workflow and handle dependencies in one graph.

Hybrid cloud

Hybrid is the same mechanism with an on-prem provider in the mix. A common exam picture is VMware vSphere (or another private-cloud API) for virtual machines that must stay in a datacenter, plus a public cloud for burst capacity, object storage, or a global CDN. Those resources can live in one configuration or in coordinated configurations that pass outputs through remote state. Either way, you are not switching CLIs: you are still writing HCL and running plan/apply.

Service-agnostic workflows

Service-agnostic means the pattern is not limited to "clouds." DNS (DNSimple, Cloudflare), identity providers, monitoring, incident tooling, Git hosts, and PaaS add-ons are all fair game. HashiCorp's classic composition example is an application on a platform such as Heroku, a CNAME at a DNS provider, and a CDN at Cloudflare—one unified syntax instead of three web consoles.

Contrast with single-platform templates

AWS CloudFormation, Azure Resource Manager (ARM) templates, and Bicep (and similar tools such as OpenStack Heat) are infrastructure as code for one platform. They are excellent inside that platform. HashiCorp's comparison page is blunt: those tools codify infrastructure so it can be created, modified, and destroyed, and Terraform is inspired by the problems they solve. Terraform goes further by being cloud-agnostic in the sense that multiple providers and services can be combined and composed. You can orchestrate an AWS and OpenStack cluster at the same time and attach third-party CDN and DNS providers. The goal is to represent the entire supporting infrastructure, not only the subset that lives in one vendor.

Terraform also keeps plan separate from apply, so operators inspect the full multi-provider delta before anything changes. That matters more as the graph crosses account and vendor boundaries. Other tools often combine planning and execution, which HashiCorp argues becomes intractable in large infrastructures.

If a question asks "we must create Route 53 records and Datadog monitors in the same change as the VMs," Terraform's answer is "add those providers." If the question is "we will only ever use Azure and want Azure-native tooling," Bicep can be a valid design choice—the Associate exam still wants you to know Terraform's multi-provider distinction.

Service-agnostic HCL patterns stay the same

The HCL patterns stay the same even when the vendor changes:

• A required_providers entry names the source and version.
• A provider block configures authentication and defaults (region, org, datacenter).
• resource and data blocks use a vendor-specific type (aws_instance, azurerm_linux_virtual_machine, vsphere_virtual_machine, cloudflare_record, okta_user, datadog_monitor).
• References stitch the graph (record.value = aws_lb.app.dns_name).

That is what "service-agnostic workflow" means: same language features, same review process, same plan. It does not mean the arguments are portable. An AMI id is meaningless to Azure. A vSphere template name is meaningless to Google Compute Engine. A module can hide those differences from callers, but someone still wrote vendor-specific resources inside the module.

Hybrid worked example

A hospital must keep an electronic health record database on vSphere in its own datacenter (latency and data-residency) but wants burst web front ends and object storage in AWS. One Terraform configuration—or a pair of configurations linked by remote state—can:

1. Declare vsphere_virtual_machine resources for the database tier.
2. Declare AWS compute or container resources for the front end.
3. Declare a DNS provider record that points a public hostname at the AWS load balancer and an internal record at the on-prem database VIP.

terraform plan shows all three providers in one report. The on-call engineer does not run a VMware-only CLI, then click AWS, then open a DNS portal. Hybrid is a provider composition problem, not a different Terraform product.

A second story is fully service-agnostic and never touches a VM: Terraform creates an Okta application, a Datadog monitor, and a Cloudflare DNS record for a SaaS product. The exam still calls that Terraform IaC, because infrastructure now includes identity and observability objects, not only hypervisors.

Kubernetes and "is this still Terraform?"

Kubernetes is both something Terraform can provision (a managed cluster on a cloud) and something Terraform can talk to (the Kubernetes and Helm providers manage pods, deployments, and charts). The HCP Terraform Operator can even drive workspaces from inside a cluster. None of that makes Kubernetes a replacement for Terraform's workflow. On 1c, treat Kubernetes as another provider target in a hybrid or multi-cloud design.

Exam trap: cloud-agnostic workflow, vendor-specific resources

Memorize this sentence: Terraform is cloud-agnostic in workflow, not in resource types.

Wrong mental model: resource "virtual_machine" "web" works on every cloud.

Correct mental model: resource "aws_instance" "web", resource "azurerm_linux_virtual_machine" "web", and resource "google_compute_instance" "web" are different types, each understood by a different provider.

Other 1c traps:

• Terraform is not a cloud and does not host your VMs.
• Adding a second provider does not require a second state file by default; one state can track many providers (workspaces and remote state are later objectives).
• "Service-agnostic" is not "protocol-agnostic magic." If there is no provider (and you do not write one), Terraform cannot manage that API.
• Using CloudFormation inside AWS while also using Terraform for everything else is a composition choice, not a requirement. Terraform's AWS provider talks to AWS APIs directly.
• HCP Terraform does not use a different language from Community Edition. Same HCL, different run location and collaboration features.

Official references: What is Terraform?, Multi-cloud deployment, Terraform versus CloudFormation and similar tools, and Terraform editions.