TERRAFORM-004 Practice Questions: Infrastructure as Code Concepts Domain

Terraform and CloudFormation are both declarative IaC tools, but Terraform is provider-agnostic and can manage resources across many platforms (clouds, SaaS, etc.) using providers (B). This is a key IaC concept: one tool, many providers.

(A) Terraform can manage many types of resources, not just servers. (C) Terraform is also declarative; you describe desired state, not step-by-step procedures. (D) Terraform can import existing resources using `terraform import` or import blocks; it is not limited to resources it originally created.

Infrastructure as Code means infrastructure is defined, versioned, and changed through code, not manual clicks. Option B aligns with IaC by requiring all changes to go through Terraform configuration and `terraform apply`, ensuring reproducibility, auditability, and reduced configuration drift. Option A still relies on manual creation and only imports later, which breaks consistent IaC practice. Option C adds an unnecessary manual step and still uses the console to apply changes. Option D accepts ongoing manual changes, which causes drift and undermines the benefits of IaC, even if `terraform plan` reveals differences.

The scenario highlights consistency and easy recreation of environments. Terraform, as an IaC tool, provides idempotent, repeatable infrastructure changes defined in code and stored in version control (B). This is the core benefit here.

(A) Auto-scaling is a cloud feature; Terraform can configure it but does not automatically scale based on CPU without explicit configuration. (C) Zero-downtime is not guaranteed; it depends on how resources are modeled (e.g., blue/green, rolling updates). (D) Terraform does not automatically roll back to a previous state when a plan has changes; you must choose whether to apply or not, and rollbacks are a manual design decision.

Storing Terraform code in Git and using PRs with terraform plan in CI aligns infrastructure changes with software development practices: changes are version-controlled, reviewable, and revertible. A is incorrect because plans can still fail at apply time due to external factors. C is incorrect because Git tracks configuration, not live resource state; Terraform state is still required. D is incorrect because Terraform does not autonomously fix resources without explicit apply and human approval in this workflow.

Terraform is provider-agnostic and uses the same core workflow (init/plan/apply) and HCL language across many providers, which is attractive for multi-cloud IaC. B is incorrect; there is no built-in automatic conversion from CloudFormation to Terraform. C is incorrect because CloudFormation itself is also declarative for AWS. D is incorrect because Terraform still requires provider configuration (e.g., aws, azurerm, google) for each platform.

In a common IaC pattern, Terraform handles provisioning and lifecycle management of infrastructure (networks, instances, managed services), while Ansible focuses on configuration management inside those resources (packages, files, services). B is incorrect because they are not interchangeable and have different strengths. C is incorrect because Terraform is widely used for cloud infrastructure, not limited to SaaS. D is incorrect because Terraform interacts directly with providers’ APIs and does not require Ansible to create resources.

Terraform is typically used for provisioning and lifecycle management of infrastructure resources (VMs, networks, managed services) as declarative IaC, while Ansible is often used for configuration management and application deployment on top of those resources (B). Many teams use both together.

(A) Terraform does not necessarily replace Ansible; they solve different layers of the stack. (C) Terraform is not limited to DNS; it manages a wide range of resources. (D) Both tools can express dependencies, but Terraform is declarative; you describe desired state, not a strict sequence of imperative tasks like a script.

IaC best practice is to treat Terraform configuration as the single source of truth and require all infrastructure changes to go through code review and Terraform workflows. This minimizes drift caused by manual console changes. A is harmful; locking helps prevent conflicting state changes. C is not a sustainable process; -replace is for targeted recreation, not routine workflow. D moves away from centralized, auditable IaC and makes drift and conflicts more likely.

A core IaC practice is that infrastructure changes are made through code and applied via Terraform, keeping configuration, state, and real infrastructure aligned (B). Direct console changes create drift and can cause unexpected plans or failures.

(A) Terraform will show drift in `terraform plan`, but it will not automatically revert console changes; you must choose to apply. (C) `terraform refresh` is deprecated and not part of recommended workflows in Terraform 1.x; and it still wouldn’t enforce using code as the source of truth. (D) Terraform state is critical for managing existing resources; console changes can break assumptions in state and configuration.

Terraform lets you define infrastructure declaratively in code and store it in version control, so you can consistently recreate environments and track changes over time. This is a core benefit of IaC. A is incorrect because Terraform does not automatically optimize costs; you must design resources accordingly. C is incorrect because Terraform manages infrastructure, not application performance tuning. D is incorrect because Terraform helps reduce drift when used properly, but it cannot guarantee the absence of drift, especially if changes are made outside Terraform.