HashiCorp Terraform Associate (004) Question 16
Single answer1c Explain how Terraform manages multi-cloud, hybrid cloud, and service-agnostic workflowsA company is standardizing infrastructure delivery for two environments: customer-facing workloads in AWS and internal analytics workloads in Azure. They also need to configure Datadog monitors for both environments from the same workflow. The platform team wants one Terraform codebase that can provision resources across these platforms while keeping cloud-specific details isolated. Which approach best demonstrates how Terraform supports multi-cloud, hybrid cloud, and service-agnostic workflows?
- A
Use Terraform providers for AWS, AzureRM, and Datadog in the same configuration, organize reusable modules by capability, and pass provider-specific inputs into those modules where needed.
- B
Use a single generic Terraform provider that abstracts AWS, Azure, and Datadog resources into one common resource type so the same syntax can manage every platform.
- C
Run separate infrastructure tools for each platform because Terraform state can only track resources from one cloud provider at a time.
- D
Convert all cloud and monitoring resources into local-exec provisioner scripts so Terraform can remain service-agnostic without using providers.
Show answer and explanation
Correct answer: A
Explanation
Terraform manages multi-cloud, hybrid cloud, and service-agnostic workflows through its provider architecture. Providers are plugins that allow Terraform to interact with different platforms, including public clouds like AWS and Azure, private or on-premises systems, and third-party services such as Datadog. In practice, a single Terraform workflow can initialize multiple providers and manage resources across them in one configuration. Modules help teams encapsulate cloud-specific logic while keeping the overall workflow consistent. HashiCorp documentation emphasizes that Terraform uses providers to manage nearly any platform or service with an accessible API, which is the foundation of its multi-cloud and service-agnostic model. Best practice is to use providers and modules declaratively, and to avoid relying on provisioners except as a last resort.
- A. Correct.
Correct. Terraform is provider-based, which is what enables multi-cloud and service-agnostic workflows. A single configuration can use multiple providers such as aws, azurerm, and datadog together. Reusable modules help isolate cloud-specific implementation details while preserving a consistent workflow for plan and apply. This matches real-world best practice: use providers for each target platform and modules to structure code, rather than expecting one universal resource model.
- B. Incorrect.
Incorrect. Terraform does not provide a single built-in generic provider that normalizes all cloud and SaaS resources into one common resource type. Each provider exposes its own resource types and data sources based on the target platform's API. This option reflects a common misconception that Terraform hides all provider differences behind one universal abstraction.
- C. Incorrect.
Incorrect. Terraform state is not limited to a single cloud provider. A single state can contain resources from multiple providers if they are managed in the same configuration. While teams may choose to separate states for operational reasons, Terraform absolutely supports managing AWS, Azure, and third-party services together.
- D. Incorrect.
Incorrect. Provisioners such as local-exec are not the recommended primary mechanism for managing infrastructure across platforms. Terraform's service-agnostic model comes from its provider ecosystem, not from replacing resource management with scripts. Using scripts for cloud and SaaS resource lifecycle management reduces Terraform's ability to detect drift, calculate plans accurately, and manage dependencies declaratively.