What is IaC and its CI/CD benefits over manual provisioning?
Your understanding of IaC as versioned, declarative infrastructure that stops snowflake environments and drift.
Cover descriptive models, idempotency, and on-demand environments for repeatable CI/CD.
What's really being asked
This question checks whether you see Infrastructure as Code as a foundational DevOps practice rather than just automation trivia. The interviewer wants to know if you understand that IaC uses versioned, descriptive models to define networks, virtual machines, load balancers, and connection topologies, and that it is a core component of continuous delivery. They are also listening for your ability to contrast this with manual provisioning and to articulate specific pipeline benefits like repeatability and drift prevention.
The full answer
First, define IaC as the practice of managing infrastructure through machine-readable definition files rather than manual configuration. Second, emphasize the declarative approach where files specify desired state and components, not step-by-step installation procedures. Third, explain idempotence as the principle that a deployment command always produces the same environment regardless of the starting state, either by reconfiguring the existing target or recreating it fresh. Fourth, connect these concepts to CI/CD by noting that pipelines can version infrastructure alongside application code, spin up production-like test environments on demand, and tear them down automatically, which prevents the snowflake environment problem and eliminates configuration drift between stages.
The mistakes people make
A weak answer treats IaC as simply writing bash or PowerShell scripts to install software. Another red flag is focusing only on speed without mentioning consistency or idempotency. Candidates sometimes confuse imperative and declarative approaches, describing IaC as a sequence of commands rather than a desired-state model. Avoid suggesting that IaC is only about cloud resources; it also covers on-premises and hybrid topologies. Finally, do not claim that IaC removes the need for testing; in fact, infrastructure code itself should be validated and tested.
What usually comes next
An interviewer may ask how you would test infrastructure code before deployment, or which tools you prefer for declarative IaC such as ARM templates, Bicep, or Terraform. They might probe how you handle secrets and sensitive values in versioned infrastructure definitions, or how you manage state files in a team setting. Another common thread is how you roll back infrastructure changes when a deployment fails, or how you enforce compliance and detect misconfiguration automatically.
A concrete example
Imagine a team that manually configured three deployment environments for a web application. Over time, the staging server received a patch that production did not, causing a release to fail only in production. By moving to IaC using JSON-based ARM templates stored in the same repository as the application code, the team ensures that every pull request triggers a pipeline validating both the app and its required Azure infrastructure. When developers need a temporary integration environment, the pipeline provisions it from the same template and destroys it after tests pass, guaranteeing that what ran in testing matches production exactly.
Interview question
Which practice best describes how Infrastructure as Code prevents configuration drift across CI/CD environments?
- a.Teams maintain detailed runbooks that document every manual change made to production servers
- b.Deployment speed is increased by automating infrastructure changes without defining desired state
- c.Operators run standardized shell scripts to configure each server identically
- d.Environments are defined by versioned declarative files that specify the desired state and can be recreated on demandCorrect
Why? this is the answer
Declarative, versioned definitions ensure every environment matches the desired state and can be reproduced identically, which stops drift. Standardized shell scripts are imperative and still risk configuration drift because they depend on the server's starting state and do not enforce a unified model.
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