A sample of real Infrastructure as Code interview questions with full answers and explanations - practice for interviews or certification exams.
Declarative means you describe the outcome you want ('I want 3 servers running this image') and let the tool figure out how to get there, rather than writing out every individual step yourself like you would in an imperative script or by clicking through a console manually.
Putting a password directly in a template means it's sitting in plaintext for anyone with template access to read. Marking the Parameter NoEcho: true hides its value from the console and CLI output, and pointing it at AWS Secrets Manager means the actual secret is fetched securely at deploy time instead of ever being stored in the template.
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.
Terraform needs some way to remember what it's already created and how that maps to your actual cloud resources, and that's exactly what the state file does. Without it, Terraform couldn't tell what's changed (drift) or compute an accurate plan for what to do next.
Deleting a CloudFormation stack normally deletes everything in it, including data you might actually want to keep, like an S3 bucket's contents. Setting DeletionPolicy: Retain tells CloudFormation to leave that specific resource (and its data) alone even when the rest of the stack gets torn down.
When an apply fails partway through, Terraform's state file might not perfectly reflect what actually got created in the real world. Running terraform refresh first reconciles the state with reality, so the next apply computes an accurate plan for just what's still missing, instead of blindly retrying things that already succeeded.
Before Terraform can do anything, it needs to download the right provider plugins and set up its backend, and that's exactly what terraform init does. It's the required first step, nothing else (plan, apply, validate) works until init has run.
Terraform builds its dependency graph mainly from implicit references, meaning one resource's argument pointing at another resource's attribute; when there's no such reference, as with a provisioner that just shells out and touches a bucket by name, Terraform has no way to know the two are related and may create them in parallel. depends_on exists for exactly this situation, forcing an explicit ordering even without a direct attribute reference. The order resources are written in a file has no effect on apply order, since that's driven entirely by the dependency graph, and a fixed sleep is an unreliable workaround rather than an actual fix.
Without a remote backend that supports locking, nothing stops two people from writing to the SAME state file at the exact same moment. Since Terraform rewrites the WHOLE state file on every apply, not just the parts that changed, a race between two applies can corrupt the file or silently erase one person's changes, even if they were working on totally different resources.
In Terraform's language (HCL), a variable you declared isn't referenced with a dollar sign or double curly braces, it always uses the var. prefix, like var.region, whether you're using it on its own or inside a string.
Real scenario-based DevOps questions, hands-on practice, and clear explanations for every answer.