What is Infrastructure as Code (IaC), and how does it support CI/CD?
This tests if you link declarative definitions to repeatable pipelines. A strong answer covers idempotence, versioned templates, and preventing snowflake environments. A red flag is calling IaC mere scripting without CI/CD integration.
What's really being asked
The interviewer wants to know if you understand Infrastructure as Code as a foundational DevOps practice that underpins continuous delivery, rather than viewing it as a simple tooling or scripting exercise. They are specifically looking for your grasp of declarative models, idempotence, version control, and how these concepts work together to eliminate environment drift and snowflake servers. The question also probes whether you treat infrastructure changes as first-class citizens within the same software delivery pipeline as application code, subject to review, testing, and automated deployment.
The full answer
First, define IaC as the practice of managing and provisioning infrastructure through machine-readable definition files rather than through manual configuration or interactive dashboards. Second, emphasize the declarative approach where you specify the desired end state, such as in JSON, YAML, or Bicep templates, and allow the underlying platform to determine the exact steps required to reach that state. Third, explain idempotence as a core principle, meaning that a deployment command produces the same environment configuration regardless of the starting state, achieved either by reconciling existing resources or by discarding and recreating them. Fourth, connect this directly to CI/CD by explaining that version-controlled infrastructure definitions can be validated, tested, and deployed through the same pipelines as application code, which enables teams to spin up production-like test environments rapidly and reliably at scale.
The mistakes people make
A major red flag is describing IaC as merely writing bash or PowerShell scripts to install software on servers, which completely misses the declarative model and idempotence principles that distinguish true IaC. Another mistake is failing to mention environment drift or snowflake environments, revealing that you do not understand the core operational problem IaC was designed to solve. Candidates also err by ignoring the CI/CD integration entirely, treating infrastructure provisioning as a separate manual or ticket-driven process rather than as code that flows through automated build and release pipelines.
What usually comes next
Expect the interviewer to ask how you handle secrets, credentials, and sensitive configuration within IaC templates without exposing them in version control. They may also probe rollback strategies when an infrastructure change fails or causes service degradation, or ask you to compare imperative versus declarative approaches with concrete trade-offs. Another common follow-up is how you test infrastructure code before it reaches production, perhaps through static analysis, policy as code, or ephemeral environments, and how you manage state and concurrency in tools like Terraform as opposed to ARM or Bicep.
A concrete example
Suppose a team needs three identical environments for a microservice application. Without IaC, an engineer manually configures a staging server through a cloud portal and over time it silently diverges from production, causing a deployment failure that is difficult to reproduce. With IaC, the team stores an ARM template or Terraform configuration in a Git repository. A pull request triggers automated validation and security scanning in the CI pipeline, and upon merge the CD pipeline deploys an identical environment. When staging breaks or drifts, the team destroys and recreates it in minutes rather than debugging manual configuration, because the code defines the desired state and the tool enforces idempotence.
Interview question
What key characteristic separates Infrastructure as Code from traditional imperative server scripting?
- a.IaC executes configuration steps sequentially each time a deployment runs
- b.IaC files are written in JSON or YAML rather than Bash or PowerShell
- c.IaC requires manual approval through ticketing systems before any changes apply
- d.IaC defines the desired end state and achieves idempotence through automated reconciliationCorrect
Why? this is the answer
True IaC is defined by its declarative, idempotent model that lets the platform reconcile to a desired state, not by the file format used. While IaC definitions are often written in JSON or YAML, simply using those formats without declarative idempotence is still just scripting.
Just read this? Test yourself on what you have been reading.
Read the original → learn.microsoft.com
- #iac
- #cicd
- #devops
- #infrastructure
- #declarative
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on iac — each one lists the topics its interview covers.
See open roles