Card 1 of 20
Front. State Binding. Why is Terraform state needed even when every resource is declared in code?
These cards are original study material. They are not questions from a named employer or a live hiring loop.
All 20 cards in this deck
1.State Binding
Why is Terraform state needed even when every resource is declared in code?
It maps configuration addresses to remote objects and retains management metadata. Code describes intent; losing the binding can lead to duplicate creation or incorrect reconciliation.
2.State Sensitive
Why must state storage be protected even when outputs are marked sensitive?
Sensitive marking primarily controls display; state can still contain credentials and other values. Restrict access, encrypt storage, and protect backups and downloaded plans.
3.State Lock
What does a backend state lock prevent, and what does it not prevent?
It coordinates supported concurrent writers to that state. It does not stop console edits, other state files, or unrelated tools from modifying the same cloud resource.
4.Force Unlock
What must be established before force-unlocking a state backend?
That the owning operation is no longer active and no writer will resume. Removing a live lock permits conflicting changes; inspect execution history and preserve state recovery options.
5.Address Refactor
Why can renaming a Terraform resource block propose destruction and creation of an unchanged cloud resource?
Its configuration address changed. Use a supported moved declaration or state migration to preserve the binding, then review the plan for unintended replacement.
6.Count Index
Why can removing the first item from a count-indexed resource list affect many resources?
Indexes shift, changing which item each address represents. Stable for_each keys can express identity more faithfully; migrate existing addresses deliberately.
7.Import Boundary
Does importing a cloud resource automatically make its configuration match the intended policy?
No. Import establishes management binding. Review the resulting configuration and plan so the next apply does not unexpectedly change or replace the imported object.
8.Drift Choice
A console edit increased production capacity during an incident. Should the next plan blindly revert it?
First decide whether the change is now desired. Reconcile code and reality intentionally, recording ownership and rationale rather than automatically discarding an operational fix.
9.Ignore Changes
What risk comes from ignoring all changes to a resource indefinitely?
Drift can accumulate without appearing as managed corrections. Ignore only fields deliberately owned elsewhere, with a clear boundary and separate monitoring.
10.Prevent Destroy
Why is Terraform prevent_destroy not a complete backup or deletion-protection strategy?
It blocks certain planned destroys while configured, but does not protect against every external deletion or configuration removal. Use service-level protection and tested backups for critical data.
11.Create Before
Why can create_before_destroy fail even when the provider supports replacement?
Old and new resources may exceed quotas or conflict on unique names. Verify coexistence, dependency behavior, and capacity before relying on replacement order.
12.Partial Apply
An infrastructure apply fails halfway through. Has it rolled back everything it already changed?
Usually not. Inspect actual resources and recorded state, then generate a fresh plan to converge safely. Do not assume database-style all-or-nothing behavior.
13.Stale Plan
Why should a previously reviewed plan not be treated as indefinitely valid?
Configuration, state, provider behavior, credentials, or external resources may change. Use a controlled plan/apply workflow and regenerate when its assumptions no longer hold.
14.Unknown Values
How should a reviewer handle important plan values that are unknown until apply?
Identify why they are unknown and which risks cannot yet be assessed. Restructure dependencies or add explicit validation where necessary; an unknown value is not evidence of safety.
15.Provider Pin
Why should infrastructure CI use a reviewed provider lock file and version constraints?
Provider changes can alter schema, planning, and resource behavior. Reproducible selection makes upgrades deliberate and their plan differences reviewable.
16.Module Boundary
What makes a useful infrastructure module boundary?
A coherent capability with explicit inputs, outputs, ownership, and lifecycle. Wrapping every resource in a separate module can obscure relationships without reducing complexity.
17.State Blast Radius
Why separate unrelated environments or high-risk systems into different state boundaries?
It reduces accidental change scope and ownership contention. Balance isolation against cross-state dependencies and avoid treating separate state as automatic credential isolation.
18.Targeted Apply
Why should targeted applies be followed by a full plan?
A targeted operation can leave related configuration changes unapplied. Use it for a specific recovery purpose, then verify convergence of the complete intended configuration.
19.Health After Apply
A load balancer and instances were created successfully. What remains unproven?
That real requests route correctly, instances are ready, dependencies work, and the service meets its requirements. Follow provisioning with meaningful health and smoke checks.
20.Restore State
Why must restoring an old state snapshot be reconciled with current cloud reality?
Resources may have changed since the snapshot. A stale binding can misdirect subsequent operations; inspect differences and repair management state before applying destructive plans.