Infrastructure as Code Interview Questions & Answers

The Parameters section is how you make a CloudFormation template reusable: instead of hardcoding a value, you define it as a parameter, and then you can plug in different values each time you create or update a stack without ever touching the template itself.

State locking prevents two processes from writing to the same state file at the same time, which could corrupt it or cause conflicting changes. The second engineer's apply has to wait, or fails with a lock error, until the first operation completes.

CloudFormation has a built-in integration with CodeDeploy specifically for blue/green rollouts on an Auto Scaling Group: it spins up a brand new group alongside the old one, gradually shifts traffic over, and only terminates the old instances once the new ones are confirmed healthy, rather than you manually swapping things yourself.

CloudFormation treats a whole stack update as one all-or-nothing operation. If even one resource fails partway through, it automatically undoes everything and puts the stack back to the last state that was known to work, rather than leaving things half-changed.

Configuration drift is when the real infrastructure slowly stops matching what your code says it should be, usually from manual tweaks. Regularly re-applying your IaC catches and corrects that drift after the fact, while immutable infrastructure (replacing servers instead of patching them) prevents most manual tweaks from ever happening in the first place, so using both together covers it from two directions.

One giant Terraform configuration for 100+ accounts means one mistake can affect everything at once, and the state file becomes a nightmare to manage. Terragrunt keeps the code DRY across many separate account directories, gives each its own remote state, and manages the order dependencies get applied in, all without one single, risky state file.

terraform plan lets you review the exact changes Terraform intends to make without touching real infrastructure, so mistakes like an accidental resource deletion can be caught before they happen. terraform apply is the step that actually performs those changes.

copy is for files that don't need to change, it just transfers them as-is. template is for files that need customization per host, like a config file, it renders a Jinja2 template (such as config.j2) and substitutes in your variables before delivering the final, host-specific file.

Ubuntu uses apt and CentOS uses yum, so a single hardcoded package-install task would break on one of them. The ansible_os_family fact tells you which family a host belongs to, so a task can branch and use the right package manager automatically instead of you maintaining entirely separate playbooks per OS.

Ansible doesn't need any special software installed on the machines it manages, it just connects over the SSH you probably already have set up and pushes what it needs to run. Puppet and Chef, by contrast, both require an agent process running persistently on every managed machine.