Infrastructure as code: declarative and imperative

Why this matters

Infrastructure as code is one of CompTIA's named bullets and it runs underneath half the rest of the exam. Provisioning, migration, lifecycle management, drift, misconfiguration and CI/CD all assume it, and several troubleshooting scenarios only make sense if you know what a template and a state file are.

The idea is small and the consequences are large: describe infrastructure in files, keep those files in source control, and let a tool make reality match them. Everything people like about it — repeatability, review, auditability, environments that are actually identical — follows from the description living in a file rather than in somebody's memory of what they clicked.

The lesson

What IaC replaces, and the console click that no one can reproduce

Before IaC, infrastructure was built by hand through a web console or a series of commands. That approach has failure modes which are worth naming, because each is something IaC fixes:

• It is not reproducible. Nobody can rebuild the environment exactly, because nobody recorded every setting. The difference between staging and production becomes a mystery that only appears under load.
• There is no history. No record of who changed what, when, or why. When something breaks after a change, the change itself is not visible.
• There is no review. A console change goes live the moment it is made. There is no equivalent of a second pair of eyes.
• It does not scale. Forty resources by hand is tedious; four hundred across three environments is not achievable accurately.
• Documentation drifts immediately. Any description separate from the thing it describes starts going stale the moment it is written.

IaC addresses all five at once, because the code is the documentation and it is executable, so it cannot silently disagree with reality the way a wiki page can.

The benefits worth stating in exam terms: repeatability, version history, peer review, disaster recovery (an environment that can be rebuilt from code is an environment you can recreate in another region), and consistency across environments.

Declarative templates describing an end state, and imperative scripts describing steps

This is the distinction the objective names and it is the most likely single question on it.

Declarative code describes what you want. The tool inspects current reality, computes the difference, and makes the changes needed. You state that three instances of a given size exist on a given network; you do not say how to get there from here.

Imperative code describes the steps to take. Create this, then attach that, then configure the other. You are responsible for the order and for what happens when a step has already been done.

Declarative is the dominant style for infrastructure, for one main reason: it handles change as naturally as creation. The same file that created the environment updates it, because the tool always compares desired state to actual state. An imperative script that created something needs a different script to modify it.

This is also the same idea as the orchestrator's desired-state loop from objective 1.5, and noticing that the two are the same concept is a genuine insight rather than a coincidence.

Imperative still has legitimate uses: one-off operational tasks, steps with complex conditional logic, and gluing together things the declarative tool does not model. The mature position is declarative for infrastructure, imperative where it genuinely helps, and a clear boundary between them.

Idempotence, and the re-run that must not create a second copy of everything

Idempotent means applying the same operation repeatedly produces the same result as applying it once. Running a template twice does not create two environments; the second run finds reality already matches and does nothing.

This is what makes IaC safe to use, and it enables behaviour that is otherwise impossible:

• Re-running after a failure. A partial apply can simply be run again; it will complete what is missing rather than starting a duplicate.
• Running on a schedule to correct drift. If reality has been changed by hand, the next apply puts it back.
• Using one definition for many environments, parameterised.

Declarative tools are idempotent by construction. Imperative scripts are not unless you write them that way, which means checking whether something exists before creating it, and making every step tolerant of having already been done. A script that does create X without checking will fail — or worse, succeed and create a second X — on its second run. That is the exam's favourite illustration of the term.

A caution: idempotent does not mean harmless. An apply that brings reality in line with a definition can legitimately destroy things, which is what the next lesson's review discipline is for.

Provider-native templates against provider-neutral tools, and the trade

Two families of tooling.

Provider-native. The cloud vendor's own templating service. Strengths: always current with new services and features, deeply integrated, no extra state to manage because the provider tracks it, usually free. Weakness: it describes one provider's resources and does not travel.

Provider-neutral. A third-party tool with providers for many platforms, using its own language. Strengths: one language and one workflow across providers and often across SaaS platforms too; a large ecosystem of reusable modules. Weaknesses: support for a brand-new service can lag the provider's own tooling, and you become responsible for state (the next lesson's subject), which the native tools handle for you.

The honest note on portability, because it is oversold: a neutral tool gives you one language, not portable templates. Resources are still provider-specific, so a template does not move from one cloud to another by changing a setting. What you carry across is skills, workflow and structure — which is genuinely valuable and is not the same as portability.

Choose native for a single-provider estate wanting the least moving parts; choose neutral for multi-cloud, for teams standardising one workflow, or where the module ecosystem saves real time.

Version, review and pipeline: infrastructure code treated as code

The practices that make IaC deliver its benefits are borrowed wholesale from software development, and skipping them keeps the file format while losing the point.

• Everything in source control. One repository per logical boundary, full history, and the ability to see exactly what an environment looked like at any past commit. Objective 5.2 covers the mechanics.
• Change by pull request, reviewed by someone else. This is where the second pair of eyes that the console never had comes back. Infrastructure changes are exactly as dangerous as application changes and have historically had far less scrutiny.
• Automated checks before merge: format, lint, validate, and a security or policy scan that refuses obviously bad configurations — a public storage bucket, an unencrypted volume, an over-broad role. Catching those here is far cheaper than catching them in the posture scan from objective 6.5.
• Plan as part of review. A declarative tool can show what it would change without changing anything. Attaching that output to the review means the reviewer sees the effect, not just the diff. Reading a plan properly is the single most valuable habit in this lesson: the line that says a resource will be replaced rather than updated is the one that causes outages.
• Apply from a pipeline, not a laptop. Consistent credentials, an audit trail, and no dependence on one person's local environment. Objective 5.3 covers the pipeline itself.
• Promote the same code through environments, varying only parameters. This is what makes staging predictive of production.

A closing caution the exam likes: the pipeline that applies infrastructure holds credentials able to create and destroy it, which makes it one of the most privileged things in the estate. That is a security consideration in its own right, revisited in objective 5.3.

What to take into the exam

• Declarative = end state, tool computes the steps, safe to re-run. Imperative = steps, order is yours, idempotence must be written in.
• Idempotence is why a template can be applied repeatedly and why a naive script cannot.
• Provider-native is current and integrated; provider-neutral gives one workflow across platforms and makes state your responsibility.
• A neutral tool gives one language, not portable templates.
• Plan output in review is what catches a change that replaces a resource instead of updating it.
• Apply from a pipeline, and treat that pipeline as highly privileged.