Infrastructure as Code (IaC) with Terraform · Topic 2 of 2

Multi-Cloud, Hybrid Cloud and Service-Agnostic Workflows

Terraform Associate (004): how providers let one Terraform workflow manage several clouds, on-premises platforms and SaaS services together.

5 min

In a nutshell

Providers are what let Terraform manage any platform with an API: public clouds, on-premises systems and SaaS services.
Multi-cloud uses several public clouds; hybrid cloud mixes cloud and on-premises; service-agnostic covers non-infrastructure services.
One configuration can use several providers, and Terraform builds one dependency graph across them.

What it is

Terraform manages many platforms with the same language, the same commands and the same state. Its reach comes from providers: plugins that translate Terraform resources into API calls for one platform each.

A multi-cloud workflow uses more than one public cloud. A hybrid cloud workflow mixes public cloud with on-premises or private cloud platforms. A service-agnostic workflow manages SaaS and platform services, such as source control, monitoring or DNS, alongside the infrastructure.

How it works

Providers make Terraform platform independent

Terraform core does not know any cloud API. It reads configuration, builds a dependency graph, compares it with state and asks providers to create, read, update or delete objects.

Each provider is published separately, most often on the public Terraform Registry, and is downloaded by terraform init. Because a new platform only needs a new provider, Terraform can manage anything that exposes an API.

Workflow	Example providers	Typical use
Multi-cloud	`aws`, `azurerm`, `google`	Spread workloads or regions across clouds
Hybrid cloud	`vsphere`, `nutanix`, `openstack` alongside a public cloud	Keep some systems on premises, burst or extend to cloud
Service-agnostic	`github`, `datadog`, `pagerduty`, `kubernetes`, `helm`	Manage repositories, monitors, on-call and clusters as code

One configuration, several providers

A single configuration can declare resources from different providers. Terraform builds one dependency graph across all of them, so a resource in one platform can use an attribute from another.

resource "aws_eip" "web" {
  domain = "vpc"
}

resource "google_dns_record_set" "www" {
  name         = "www.example.com."
  managed_zone = "example-zone"
  type         = "A"
  ttl          = 300
  rrdatas      = [aws_eip.web.public_ip]
}

Here the DNS record in Google Cloud refers to the AWS Elastic IP. Terraform creates the IP first, then the record, because the reference creates an implicit dependency. One terraform apply handles both clouds.

The same workflow everywhere

Operators learn one set of commands and one review process. The plan shows every change across every provider in one place, and state tracks every managed object whichever platform it lives on.

What Terraform does not do

Terraform does not translate one cloud's resources into another's. An aws_instance block only works with AWS; to run a similar server on Azure you write an azurerm_linux_virtual_machine block with Azure's own arguments.

Teams that want a common interface write their own modules, for example one module per cloud that each accept the same input variables. The workflow is shared; the resource definitions are not.

Why this matters for teams

Benefit	How Terraform delivers it
One skill set	HCL and the same commands for every platform
Cross-platform dependencies	One graph orders changes across providers
Single view of changes	One plan covers clouds, on-premises and SaaS
Less tool sprawl	One tool replaces several platform-specific tools
Easier migration and failover	Infrastructure for each platform lives in versioned code

How the exam asks about this

"A company runs workloads on AWS and Azure and wants one tool and one workflow for both." Use Terraform with the AWS and Azure providers, in one configuration or separate ones.
"A team wants to manage GitHub repositories and Datadog monitors with Terraform." Possible, because providers exist for SaaS services, not only for clouds.
"True or false: the same aws_instance resource block can be deployed unchanged to Google Cloud." False. Resource types belong to one provider.

What to remember for the exam

Providers are what let Terraform manage any platform with an API: public clouds, on-premises systems and SaaS services.
Multi-cloud uses several public clouds; hybrid cloud mixes cloud and on-premises; service-agnostic covers non-infrastructure services.
One configuration can use several providers, and Terraform builds one dependency graph across them.
References between resources of different providers create dependencies just like references within one provider.
The workflow (write, init, plan, apply) and the language are the same for every provider.
Resource types are provider specific; Terraform does not convert resources between clouds.

Watch out

"Cloud agnostic" in Terraform means the tool and workflow work everywhere, not that one configuration deploys unchanged to any cloud. An option claiming write once, deploy to any cloud is a trap.

Common mistakes

Thinking Terraform only manages clouds. Many providers manage SaaS and platform services such as GitHub, Datadog, Kubernetes and DNS hosts. Anything with an API can have a provider.

Believing multi-cloud needs separate tools per cloud. Terraform handles every cloud with its own provider in one tool. You can even combine them in one configuration and one apply.

Assuming providers are built into Terraform. Providers are separate plugins, downloaded by terraform init from a registry or a mirror. Terraform core alone cannot create any resource.

Check yourself

What lets Terraform manage both an on-premises vSphere cluster and an AWS account?
Providers. Each platform has its own provider plugin that turns Terraform resources into that platform's API calls, so one workflow can drive both.
Can a resource from one provider use an attribute of a resource from another provider?
Yes. Terraform builds one dependency graph across all providers in a configuration, so a reference such as aws_eip.web.public_ip in a Google DNS record works and sets the order.
Does a Terraform configuration written for AWS run unchanged on Azure?
No. Resource types and arguments are specific to each provider, so Azure needs its own resources; only the language and workflow are shared.

Topic 2 of 2 in Infrastructure as Code (IaC) with Terraform

Test yourself on Infrastructure as Code (IaC) with Terraform

The full HashiCorp Terraform Associate 004 question bank has 600 questions, with timed practice exams and an explanation for every answer.

Get Full Access Try Sample Exam

This study guide is independent and is not affiliated with, endorsed by, or sponsored by HashiCorp. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.