Infrastructure as Code (IaC) with Terraform Study Guide — 004

Infrastructure as Code (IaC) with Terraform

This domain is part of the HashiCorp Terraform Associate 004 exam (004 has been the only version since January 2026; 003 is retired). HashiCorp does not publish objective weightings, so treat it as one of the current blueprint's estimated-even-weight topic areas rather than a confirmed percentage — do not rely on a specific question count. It tests your conceptual understanding of Infrastructure as Code principles, why Terraform exists, how it compares to competing tools, and the foundational mechanics that make Terraform behave the way it does. You will not write much code here; instead, you will be asked to identify the correct definition, the right tool for a scenario, or the precise behavior of a Terraform concept. Weak preparation on this domain is a common reason candidates fall just below the passing threshold.

What Is IaC: Declarative vs Imperative Approaches

Infrastructure as Code (IaC) is the practice of defining and managing infrastructure resources through machine-readable configuration files rather than through manual processes or interactive UIs. The configuration files become the single source of truth for your infrastructure and can be stored in version control, reviewed, tested, and audited like application code.

Declarative vs Imperative

The most important conceptual distinction in this domain is the difference between declarative and imperative approaches to IaC.

Terraform uses HashiCorp Configuration Language (HCL), a declarative language. You declare resources and their properties. Terraform figures out the sequence of API calls needed to produce that state.

Common Traps

• Ansible is not purely declarative. The exam may present Ansible as a declarative tool. It is primarily an imperative, procedural automation tool, though some of its modules provide idempotent behavior.
• Pulumi is not imperative just because you write TypeScript or Python. Pulumi's programming model is still declarative in intent — you describe desired state using familiar languages. The exam may try to categorize Pulumi as "imperative" because of the language choice.
• "Declarative" does not mean "no logic." Terraform supports count, for_each, conditionals, and functions. The declaration itself is still a desired state description.

Worked Scenario

Requirement: A team wants to define cloud resources so that if they run the same script twice, no duplicate resources are created, and the tool determines the correct order to create dependent resources (e.g., a subnet must exist before an EC2 instance).

Reasoning: This points to a declarative IaC tool with built-in dependency resolution and idempotency. Terraform satisfies both. A shell script calling the AWS CLI would require the author to code order and guard clauses manually.

Benefits of IaC: Consistency, Repeatability, Version Control, Auditability

Understanding why IaC matters is tested directly. Memorize the canonical benefits and be able to match them to exam scenarios.

Common Traps

• The exam may list "documentation" as a benefit. IaC configuration files serve as living documentation, but this is a secondary benefit, not the primary one the exam emphasizes. The primary four are consistency, repeatability, version control, and auditability.
• Version control is not automatic. You must store your .tf files in a VCS. Terraform itself does not push to Git. The exam will not trick you on this, but understand that the benefit is achievable, not that Terraform does it for you.
• "Eliminates all errors" is a distractor. IaC reduces human error from manual processes but does not eliminate errors in the code itself.