Deployment & Infra
Infrastructure as Code: multiple-choice review
Crux Multiple-choice synthesis across the IaC unit — declarative desired state, the plan/apply diff engine, remote state, locking, drift, and immutable infrastructure.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one mirrors a judgment call you make at a terminal during a real change window — not a definition to recite, but a tradeoff to weigh while production is watching.
Goal
Confirm you can connect declarative desired state, the plan/apply diff engine, the role of the state file, locking under concurrency, and drift handling — the synthesis the lesson built toward.
Quiz
Completed
Your config declares an S3 bucket. You run apply once, then run apply again with no change to the config and no out-of-band change. What should happen on the second apply, and which property guarantees it?
Heads-up That would be imperative scripting. IaC is convergent: the recorded state file lets the tool see the bucket already exists, so it proposes no change. Stacking duplicates is exactly what idempotency prevents.
Heads-up The tool does not blindly issue a create — it diffs against state first, sees the bucket is already managed, and computes an empty plan. No error, no duplicate.
Heads-up Destroy/recreate happens only when an immutable attribute changes. An unchanged config yields an empty diff; nothing is touched.
Quiz
Completed
A teammate asks: 'Why keep a state file at all? Just refresh against the live cloud every time and diff that.' What is the strongest reason the state file is not optional?
Heads-up Speed is a side benefit, not the point. plan and apply refresh against the provider anyway. The irreplaceable role is identity: mapping symbolic config names to concrete resource IDs.
Heads-up Cloud APIs absolutely expose reads — that is how refresh works. The gap a refresh cannot fill is ownership: knowing which live resource a given config block manages.
Heads-up The desired state lives in your version-controlled .tf / Pulumi code, not in state. State records last-known reality and the id-to-resource mapping.
Quiz
Completed
Two CI jobs both run `terraform apply` against the same backend nine seconds apart, with locking disabled via `-lock=false`. What is the core failure mode?
Heads-up -lock=false explicitly opts out of the lock the backend would otherwise take. Without it, concurrent writes race; that is the entire reason state locking exists.
Heads-up It is not clean last-writer-wins. Both plans were computed against a moving target, so the merged result can describe neither reality — an inconsistent, corrupt state.
Heads-up There is no cross-team atomic transaction on the state file. The only thing that prevents the race is an explicit lock acquired before the write — which -lock=false disables.
Quiz
Completed
A CI run crashed mid-apply and left a stale lock. The next pipeline fails fast with `Error acquiring the state lock`. A junior wants to run `terraform force-unlock` immediately and re-apply. What is the senior caution?
Heads-up A lock error can equally mean a legitimate apply is in flight. Force-unlocking that one mid-write is precisely how you corrupt state. Confirm nothing is writing first.
Heads-up The lock lives in the backend, not on the runner — rebooting does nothing. force-unlock is the supported tool; the discipline is verifying no active writer first, then re-planning.
Heads-up That disables locking entirely and reintroduces the concurrency race. The fix is to clear the one stale lock with force-unlock, not to abandon locking.
Quiz
Completed
During a 2am incident a teammate hand-edited a security-group rule in the console to stop the bleeding. Nobody touched the code. A routine `terraform apply` runs Tuesday morning. What is the danger, and what should have happened first?
Heads-up It does the opposite. Anything not in the desired config is treated as drift to be reconciled away. The manual rule is removed unless someone codifies it first.
Heads-up Apply does not error on drift — it silently plans the change that reconciles reality back to config. That silence is exactly the hazard.
Heads-up The reverse: the manual change is not in the config, so apply erases it. Drift surfaces in plan; the fix is to decide intent and update config when the change should stay.
Quiz
Completed
A generated database password ends up as a Terraform output, and the state file lives in an S3 bucket several engineers can read. What is the exposure, and what is the right pattern?
Heads-up Marking an output 'sensitive' only redacts it from CLI display; it is still stored in plaintext in state by default. The bucket readers still have it.
Heads-up Bucket access control narrows the blast radius but the secret is still in state in plaintext — any future reader, backup, or replicated copy leaks it. Don't put it there in the first place.
Heads-up Outputs and resource attributes are both serialised into the state file. That is exactly why a password routed through state is exposed to anyone who can read it.
Recap
The through-line: you declare desired state, plan diffs it against the recorded state file (refreshing the provider first), and apply executes the diff idempotently. The state file is the identity map — source of truth and hazard at once: keep it in a versioned, locked remote backend, never route secrets through it, and confront drift deliberately with plan -refresh-only, deciding intent before an apply silently reverts an emergency fix. Lean toward immutable infrastructure so there is less to drift in the first place.