All jobs / DevOps / SRE / cloud

Infrastructure as Code interview questions

Infrastructure as Code questions a DevOps / SRE / cloud can be asked, from first job to senior. Open one to see the strongest answer and why it works.

  1. Prod kube YAML is a copy-paste from staging with “a few edits.” What will bite you?

    The strongest answer: Drift: a leftover staging URL, a missing limit, a secret name that does not exist — I want the same pipeline to render both, not a human memory

    Why it works: Exactly. Hand-copied YAML is drift. Render it. Do not pet prod.

    • One pipeline, two values files.
    • Do not copy-paste prod.
    • Diff before apply.
    • Do not edit live to “match.”

  2. Prod is wrong. A teammate SSHes in and “fixes the file.” What is the problem?

    The strongest answer: The next deploy undoes it, nobody else has the change, and we learned nothing in the artifact — I treat a live edit as an incident, not a workflow

    Why it works: Exactly. Pets versus cattle. The artifact is the plan. A live edit is a snowflake.

    • Change the artifact.
    • Use SSH as break-glass.
    • Do not leave snowflakes.
    • Do not “fix” with 777.

  3. Terraform, CloudFormation and Bicep are called declarative. What does that mean compared with a script of CLI commands?

    The strongest answer: You describe the end state and the engine computes and applies the difference, so re-running converges; a script is ordered steps that often fail or double-create when run twice

    Why it works: Exactly — desired state plus a diff is why you get a plan, idempotency and drift detection for free.

    • Describe the end state.
    • The engine computes the diff.
    • Re-runs converge.
    • Scripts drift and duplicate.

  4. When do you apply infrastructure changes?

    The strongest answer: After a reviewed plan in the PR (or the equivalent), against the state we trust — I do not apply from a laptop on Friday with no diff

    Why it works: Exactly. Plan, review, apply the plan. Laptop-Friday is folklore we retired.

    • Plan in the PR.
    • Review the diff.
    • Apply that plan.
    • Do not click-and-remember.

  5. An Ansible playbook reports `changed` on the same task every time it runs, though nothing on the server is different.

    Why does that matter, and what do you fix?

    The strongest answer: The task is not idempotent — usually a shell or command step; use the proper module (copy, template, package, service) or add creates / changed_when so a converged host reports no change and handlers stay quiet

    Why it works: Right — a converged run should be all green; a permanent `changed` hides real drift and restarts services for nothing.

    • Idempotent tasks, green when converged.
    • Modules over shell.
    • creates or changed_when where needed.
    • Changed should mean changed.

  6. Terraform plan is clean on CI and dirty on the apply runner. What do you suspect?

    The strongest answer: Different credentials, workspace, or someone clicked in the console — I do not apply until I understand the drift

    Why it works: Exactly. Drift or a different identity. Understand, then apply.

    • Compare identity and workspace.
    • Look for console clicks.
    • Do not apply a surprise.
    • Do not delete state to “refresh.”

  7. Twelve squads copy the same 400-line Terraform. What do you do?

    The strongest answer: A versioned module with a changelog and a paved example — I do not force a mega-module that hides every knob, and I do not let twelve forks rot

    Why it works: Exactly. A module is a product. Global state is a blast radius. Clicks are drift.

    • Version the module.
    • Pave an example.
    • Do not share one state.
    • Do not rewrite for freshness.

  8. One Terraform root module and one state file hold dev, staging and prod, switched by a variable.

    What is the risk, and how do you separate them?

    The strongest answer: One state means a dev mistake can plan a destroy in prod and every apply locks everyone; split state per environment — separate backends or directories, shared modules, per-environment variables — with separate credentials and prod apply behind review

    Why it works: Exactly — environments are separated by state and credentials, not by an if statement. Shared modules keep them consistent.

    • State per environment.
    • Shared modules, per-env variables.
    • Separate credentials.
    • Prod apply behind review.

  9. The console is still a second control plane. What do you do?

    The strongest answer: Lock dangerous writes to IaC / pipelines, leave read and a break-glass, and detect drift — I do not shame people for a click I still allow

    Why it works: Exactly. Make the safe path the only write path. Shame without a lock is theatre.

    • Write via IaC.
    • Detect drift.
    • Keep break-glass.
    • Do not shame instead of locking.