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. 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.
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.