Infrastructure as Code (IaC) with Terraform

Picture the difference between clicking through a cloud console to launch a server and writing a short file that says a server of this size, on this network, should exist, then letting a tool make it so. That second style is Infrastructure as Code (IaC): provisioning and managing infrastructure through machine-readable configuration files instead of manual console actions or point-and-click tools. Terraform is an IaC tool, and its configuration is declarative, so each file states the desired end-state of your infrastructure and Terraform works out which operations, in which order, reach that state. Hold on to that one fact, that configuration is code declaring a result, because every advantage and capability in this domain is a consequence of it. The classic exam trap is to read 'declarative' as 'a script': a declarative config is not an ordered list of imperative commands you sequence by hand, it is a description of the end-state that Terraform reconciles toward.

The three subtopics build on each other as a single line of thought. First, Explain What IaC Is pins down the definition above: machine-readable, declarative configuration versus manual provisioning, and why codified infrastructure is repeatable where console clicking is not. Reach for it whenever a question asks what IaC or declarative configuration actually means. Second, Advantages of IaC Patterns explains why teams adopt it: because configuration is text you commit to a version control system (VCS) such as Git, changes gain history and peer review, terraform plan previews every add, change, and destroy before terraform apply touches anything, repeatable definitions cut configuration drift (the gap that grows when running infrastructure diverges from its intended definition), and immutable infrastructure replaces resources instead of patching them in place. Third, Multi-Cloud, Hybrid, and Service-Agnostic Workflows shows how far the model reaches: one write, plan, and apply workflow drives many providers (the plugins that connect Terraform to each platform's API), so the same process manages AWS, Azure, GCP, on-prem, and SaaS alike.

Across this domain, the exam rewards a consistent instinct: when two options both seem to work, prefer the one that treats infrastructure as declarative, version-controlled code reconciled toward a desired state, and prefer a single consistent workflow over a different tool for each platform. That is why a reviewable terraform plan beats an undocumented console change, and why standardizing on one workflow across clouds is framed as reducing vendor lock-in rather than as mere convenience. One caution keeps the instinct honest: 'one workflow across many clouds' does not mean Terraform flattens every provider into a single universal resource model. The workflow is unified, but each provider still exposes its own distinct resource types and its own platform API; the provider plugin maps the one workflow onto each platform, it does not merge them into one.