TF-Associate-004 - Infrastructure as Code (IaC) with Terraform (8% of the exam) - Section 1c
Explain how Terraform manages multi-cloud, hybrid cloud, and service-agnostic workflows.
One configuration language and workflow spanning many providers, so the same plan/apply loop manages AWS, Azure, GCP and on-premises resources side by side. Candidates should understand that the provider plugin abstracts each platform's API while the core workflow stays constant, and why that reduces tool sprawl.
provider-agnostic workflowmulti-cloudhybrid cloudsingle workflow across providers
Practice question for this objective
lock_openFree sampleInfrastructure as Code (IaC) with Terraformmedium
A team runs Terraform against AWS, Azure, and a private VMware estate. They describe their setup as a provider-agnostic workflow. Which statement best captures what makes the Terraform workflow provider-agnostic?
ATerraform translates one cloud's resource definitions into another cloud's resources automatically, so a single resource block deploys to every provider at once.
BThe same write, plan, and apply workflow and HCL language manage resources across every provider, while each provider plugin maps that configuration to its own platform API.check_circle Correct
CTerraform can only be provider-agnostic when every provider in the configuration is an official HashiCorp-maintained provider from the public registry.
DProvider-agnostic means Terraform stores a single normalised state format that hides which provider created each resource so tooling cannot tell them apart.
A provider-agnostic workflow keeps one language and one workflow constant while provider plugins handle each platform's API. Terraform separates the consistent write-plan-apply workflow and HCL from provider plugins, which translate declared configuration into calls against each platform's own API rather than converting resources between clouds.
Why A is wrong: This is tempting because a single workflow spans many providers, but Terraform never auto-translates resources between clouds; each provider exposes its own distinct resource types that you declare separately.
Why B is correct: Correct: the workflow and configuration language stay constant across providers, and provider plugins handle the platform-specific API calls, which is exactly what provider-agnostic means.
Why C is wrong: Registry tier is unrelated to the workflow; community and partner providers use the same workflow, so restricting it to official providers misstates the concept.
Why D is wrong: State does record the provider and resource type for every managed object, so the claim that provider identity is hidden is false, even though state is indeed a shared mechanism.
Exam traps in Infrastructure as Code (IaC) with Terraform
Answers that look right on this material and are not. Each one is a distractor from a different question in the TF-Associate-004 bank for this domain.
Terraform requires a separate apply per provider, so the colleague is correct that two runs are needed to reach the desired state.
errorWhy it is wrong: This is tempting because each cloud has its own account and API, but Terraform's single workflow spans providers, so one apply suffices.
Terraform can manage the AWS resources but the Kubernetes objects must be applied separately with kubectl, since Terraform has no Kubernetes support.
errorWhy it is wrong: This is tempting for teams used to kubectl, but a Kubernetes provider exists, so Terraform can manage those objects directly.
Multi-cloud, because any configuration that touches more than one region of a single public cloud provider is by definition multi-cloud.
errorWhy it is wrong: Multiple regions of one provider is not multi-cloud, and the scenario mixes public cloud with on-premises rather than two public clouds, so this misapplies the term.