HashiCorp Terraform Associate (004) Question 20
Single answer1c Explain how Terraform manages multi-cloud, hybrid cloud, and service-agnostic workflowsA platform team needs a single Infrastructure as Code workflow to provision networking in AWS, a resource group in Azure, and DNS records in Cloudflare for the same application deployment. They want to keep one Terraform codebase, use each vendor's native APIs, and avoid rewriting the workflow for each environment. Which approach best explains how Terraform supports this requirement?
- A
Use Terraform providers for AWS, AzureRM, and Cloudflare in the same configuration so Terraform can manage resources from multiple platforms through a consistent workflow.
- B
Use Terraform only for AWS resources, then rely on built-in provider translation to automatically convert the configuration into equivalent Azure and Cloudflare resources.
- C
Use a single generic cloud provider in Terraform because Terraform does not support multiple providers in one configuration.
- D
Use Terraform modules only, without providers, because modules are the mechanism Terraform uses to communicate directly with cloud APIs across platforms.
Show answer and explanation
Correct answer: A
Explanation
Terraform manages multi-cloud, hybrid cloud, and service-agnostic workflows through its provider model. Providers are plugins that expose resource types and data sources for a specific platform or service, such as AWS, Azure, Kubernetes, Cloudflare, GitHub, or VMware. Because Terraform uses a consistent configuration language and workflow regardless of provider, teams can define infrastructure across multiple clouds, on-premises environments, and third-party services in one codebase. This is a key Terraform concept covered in Terraform Associate objectives.
In practice, Terraform is service-agnostic at the workflow level, not because it uses a universal cloud API, but because it standardizes how you declare desired state, generate a plan, and apply changes. Each provider then maps that workflow to the target platform's API. HashiCorp documentation on providers and the Terraform workflow supports this model: Terraform configurations can require and configure multiple providers, and providers are responsible for resource lifecycle operations against their respective services. Modules improve reusability and organization, but providers are the actual integration point with each cloud or service.
- A. Correct.
Correct. Terraform is provider-based, and a single configuration can use multiple providers at once, such as aws, azurerm, and cloudflare. This is the core mechanism that enables multi-cloud, hybrid cloud, and service-agnostic workflows. Terraform provides a consistent language, planning model, state management, and execution workflow, while each provider handles communication with its platform's API.
- B. Incorrect.
Incorrect. Terraform does not translate one provider's resource types into another provider's equivalents. AWS resources are defined by the AWS provider schema, Azure resources by the AzureRM provider schema, and Cloudflare resources by the Cloudflare provider schema. You must explicitly declare the resources you want from each provider.
- C. Incorrect.
Incorrect. Terraform explicitly supports multiple providers in the same root module or across modules. A common real-world pattern is combining cloud providers with SaaS providers such as Cloudflare, Datadog, or GitHub in one workflow. The misconception here is assuming Terraform requires a single cloud-specific provider per configuration.
- D. Incorrect.
Incorrect. Modules are a way to organize and reuse Terraform configuration, but they do not replace providers. Providers are the components that define resource types and interact with external APIs. Modules can encapsulate multi-provider logic, but providers are still required for Terraform to manage infrastructure.