Infrastructure as Code

Cover this or you fail the question

• Infrastructure is defined in files, kept in version control, and applied by tooling — so an environment is a product of code rather than of accumulated manual actions.
• The practical benefits are reproducibility, because a second environment is the same code with different parameters; reviewability, because a change is a diff someone can read before it happens; and history, because you can see what changed, when and why.
• It shifts the response to a broken environment from repair to replacement, which is a meaningful reliability change: rebuilding from a known definition is more predictable than fixing something whose current state nobody fully knows.
• Declarative tools describe the desired state and work out the steps; imperative scripts describe steps and must be written to be safe to re-run. Declarative is the default for infrastructure for exactly that reason.

What separates a solid answer

• Declarative tooling keeps a record of what it believes exists, and compares desired configuration against it to compute changes. That record is the most operationally sensitive artifact in the system.
• It belongs in remote shared storage with locking, so two engineers applying simultaneously cannot corrupt it or race each other. Local state files are how teams lose an environment's definition.
• State frequently contains sensitive values, including generated passwords and keys, so it must be encrypted and access-controlled like any secret store.
• Split state by boundary — per environment and per broadly independent component — so the blast radius of a mistake is limited and applies are fast. One state file for an entire estate makes every change slow and every mistake enormous.

Common trap: Describing infrastructure as code without mentioning state at all. It is the first thing an experienced interviewer probes, because it is where the real operational difficulty lives.

What separates a solid answer

• Drift is the divergence between what the code says and what actually exists, and it appears the moment somebody changes something in the console during an incident.
• It matters because the next apply will either revert that change — potentially re-breaking something at the worst moment — or fail, and both are unpleasant surprises.
• Detect it by running the plan on a schedule and alerting when a difference appears with no corresponding code change, so drift is found in hours rather than discovered during an urgent deployment.
• Handle the human reality rather than pretending it away: emergency console changes will happen, so the process should be that they are allowed and must be reconciled into code within a defined window. Restricting console write access in production makes this the default rather than a rule people are asked to remember.

What separates a solid answer

• Modules encapsulate a pattern — a standard service, a database with its backup and monitoring configuration — so teams consume a reviewed building block rather than assembling primitives.
• Pin module versions and upgrade deliberately. Consuming the latest version automatically means an upstream change can alter production without any change in the consuming repository, which is a genuinely alarming property.
• Keep environments as the same code with different parameters, rather than copies that have been edited independently. Copies diverge, and then the staging environment stops predicting production, which removes most of its value.
• Keep modules composable and reasonably small. A module with fifty parameters that tries to cover every case is harder to use correctly than two focused ones.

The senior signal

• Apply only through a pipeline, never from an engineer's machine. Otherwise the change depended on that person's permissions and local tool version, and neither is reproducible or auditable.
• The plan is a review artifact: it should be produced automatically on a pull request and read by a human, because a plan showing a resource being destroyed when the intent was a small edit is the single most valuable safety check available.
• Policy checks in the pipeline enforce organisational rules before anything is created — required tags, no public storage, approved regions — which is far better than detecting the violation afterwards.
• Some changes are destructive in ways the plan states plainly but people skim past, notably resources that must be replaced rather than updated in place. Treating replacement of a stateful resource as requiring explicit acknowledgement prevents a whole category of incidents.
• The honest limitation to acknowledge: infrastructure as code manages what it created. An estate that predates it needs importing, and until then the code and reality disagree in ways the tooling cannot see — which is why adoption on an existing estate is mostly an inventory and import exercise rather than a writing exercise.