Explain What IaC Is

Suppose you need a virtual network, three servers, and a load balancer. You can open a cloud provider's web console and click each one into existence, or you can write a short file that declares those resources and let a tool build them for you. That file is the whole idea behind infrastructure as code^[1]: you manage infrastructure with configuration files rather than through a graphical user interface.

Infrastructure as Code (IaC) is the practice of provisioning and managing infrastructure through machine-readable configuration files instead of manual, point-and-click actions. Terraform^[2] is an IaC tool that lets you build, change, and version cloud and on-prem resources safely and efficiently by defining them in human-readable configuration files. The word code is doing real work here: the configuration is a durable artifact you keep, not a sequence of clicks that vanishes once performed.

That point is easy to misread. IaC is not merely a script that replays GUI clicks or a macro that drives a console; the configuration itself codifies the intended infrastructure, so it can be stored, reviewed, and reused like any other source code. Across this page, keep three ways of provisioning in view: the manual console, imperative scripts that list ordered commands, and declarative IaC, where you state the end result and the tool works out the steps. The comparison table above sets these three side by side. The two sections that follow pin down the properties that make Terraform's approach infrastructure as code and not just automation: it is declarative, and it is codified.

The single most important property of a Terraform configuration is that it is declarative: it describes the desired end-state of your infrastructure rather than the ordered steps to build it. You write what you want to exist, for example a network with three servers attached, and Terraform determines the operations needed to reach that state. Terraform's configuration language is declarative^[1], in contrast to procedural languages that require step-by-step instructions to perform a task.

A Terraform configuration is therefore not an imperative or procedural script that lists commands in execution order. In an imperative approach you specify the how: create this, then wait, then attach that, then configure the next thing, in exactly that sequence. In the declarative approach you specify the what, and the tool computes the how. Because it works from the finished picture, Terraform calculates the dependencies between resources^[2] and creates or destroys them in the correct order for you, so you do not hand-sequence the graph yourself.

Declaring end-state does not mean Terraform bypasses the platform. Terraform creates and manages resources through their application programming interfaces (APIs)^[2], the same APIs a console or a hand-written script would call. What makes it more than a thin wrapper around those calls is that it records the resources it manages in a state file and reconciles the real infrastructure back to the declared configuration on every run. That reconciliation is what a raw API call lacks: an imperative call fires once and forgets, whereas Terraform keeps comparing what exists against what you declared.

Terraform runs this reconciliation in three stages, its canonical write, plan, apply workflow. You write the configuration that declares the desired state. Terraform then builds a plan by comparing the desired state in your configuration against the current state of your real infrastructure^[2], and describes what it will create, update, or destroy. On approval it applies that plan, performing the operations in dependency order until the real infrastructure matches the desired state. The figure traces that path from configuration to matching infrastructure.

The payoff of codifying infrastructure is that the same configuration produces the same result every time. Apply it to an empty account and you get the environment; apply it again and Terraform makes no changes, because reality already matches the declared state. Manual or ad-hoc provisioning, clicking through a console or running undocumented one-off commands, cannot make that guarantee, because the exact sequence lives only in someone's memory or shell history. IaC lets you build, change, and manage infrastructure in a safe, consistent, and repeatable way^[1] by defining resource configurations you can version, reuse, and share.

Once infrastructure is expressed as code, it inherits the everyday practices of software engineering. You can commit your configurations to version control^[1] so every change has an author, a timestamp, and a diff; changes can go through code review before they are applied, exactly as application code does; and common patterns can be packaged and reused rather than rebuilt by hand each time. Human-readable configuration files that you can version, reuse, and share^[3] are what make this possible.

Being codified is not the same as merely using an API. A one-off, undocumented API or CLI call is still ad-hoc: it is not infrastructure as code just because it goes through an API, because nothing about it is codified, versioned, or repeatable. The line is whether the definition is captured in a durable, reviewable file, not which transport carries the request. Terraform also keeps track of your real infrastructure in a state file^[2], a recorded source of truth for what it manages, where console clicking leaves no such record at all.

Reading the figure left to right shows infrastructure as code following the same path a code change takes: you edit the configuration, commit it to version control, have the change reviewed, run terraform apply to reach the desired state, and the state file records the resources that now exist.

TA-004 items for this objective test whether you can state what infrastructure as code is and separate the declarative model from an imperative one, with no provider-specific detail required. The stems are short and definitional, so the work is matching a precise description rather than recalling a command.

A common stem asks you to pick the best description of infrastructure as code. The right answer names managing and provisioning infrastructure through machine-readable configuration files; the tempting wrong answers describe automating console clicks, or call any use of a cloud API infrastructure as code. Reject both: a macro over a GUI and a bare API call are not codified, versioned, or repeatable, which is the property the definition turns on.

Another common stem contrasts declarative and imperative configuration. When a question asks how a Terraform configuration describes infrastructure, choose the option that says it declares the desired end-state and lets Terraform determine the steps; reject any option describing an ordered list of commands the author sequences by hand, which is the imperative model. A related distractor claims Terraform replaces provider APIs with its own protocol. It does not: it calls those same APIs and adds state tracking and reconciliation on top.

A third pattern asks for a benefit of IaC. Safe answers are the software-engineering ones: version control and history, code review, repeatable and consistent provisioning, and reuse of shared configurations. A distractor often offers a benefit IaC does not claim, such as removing the need for provider APIs or guaranteeing zero cost; match only the benefits that follow from infrastructure being expressed as versioned, declarative code.