Your team has adopted a declarative IaC tool. Where does imperative scripting against a cloud SDK or CLI still legitimately win, and how do you keep those scripts from becoming invisible operations?

## The line: durable resource versus one-shot action The question behind "should this be declared or scripted?" is not "which tool do I like" but **does this thing have a desired state that persists?** A VPC, a queue, a role, a DNS record — these should still exist tomorrow, in a known shape. They belong in the declarative description, because you want three specific properties: someone can read the file and know what exists; a change is previewable and reviewable; and deleting the declaration removes the thing. A restore, a node drain, a credential rotation, a data backfill, a forced failover — these are *events*. There is no "already true" condition to assert, so there is nothing for a declarative engine to converge on. Modelling them as resources produces the well-known anti-pattern: a resource that exists only to record that a script was run once, which then has to be tricked into re-running with a fake input change. ## Where scripting genuinely wins **Operational, day-two actions.** Everything in the events list above. These are procedures, and procedures are imperative by nature. **Investigation.** Answering "how many of these do we have, and which ones are misconfigured?" across an estate is a read-only loop. Nobody should be writing a resource declaration to find something out. **Bulk operations over existing objects.** Tagging ten thousand objects, migrating data between buckets, walking every account to check one setting. The declarative tool would need each object modelled; a loop needs none. **Bootstrapping the tooling itself.** The classic chicken-and-egg: the declarative tool needs somewhere to keep its records and an identity to run as, and neither exists yet. Something has to create those prerequisites, and that something is usually a small script run once. **Gluing the pipeline together.** The wrapper that decides which directories to run in, assembles credentials, passes an approved change through to the apply step — that is orchestration, and it is imperative code by definition. **Anything the provider has not modelled.** Providers lag their own cloud's APIs. When a service is a month old, or a setting only exists on the API and not as a resource, a script may be the only route. Treat this one as temporary: revisit it, because the reason it is a script is expected to expire. ## Where scripting is the wrong answer The common failure is using a script because the declarative route is *awkward right now*: a stubborn resource, a change nobody wants to preview, a hurry. That trades a permanent loss of visibility for a temporary convenience. Once a durable resource is created imperatively, it is invisible to the tool — never reviewed, never diffed, never cleaned up with the rest of the estate — and the next person to read the repository will believe it does not exist. The other failure is the escape hatch that shells out *from inside* a declarative apply. It defeats the preview, since the engine cannot show what an arbitrary command will do; it defeats removal, since deleting the declaration cannot undo the command's effects; and it usually defeats idempotency too. Sometimes it is still the pragmatic choice, but say out loud what it costs. ## Keeping the scripts from becoming invisible operations The risk with imperative operational tooling is not that it is imperative — it is that it tends to live outside every control the team put around infrastructure change. Treat it as production code: - **In the repository, and reviewed.** A script that touches production gets the same review as the declarative code that does. Being short is not an exemption. - **Parameterised, not edited.** A script whose account or resource id is edited in place before each run is a script that will one day be run against the wrong environment because someone forgot to change a line back. - **Idempotent or explicitly guarded.** If it can be safely re-run, say so and make it true. If it truly cannot, make it refuse to run twice — confirmation prompt, existence check, or a recorded marker. - **Dry-run first.** Provide a mode that prints what it would do. This is the poor engineer's plan step, and it recovers most of the review value the declarative flow gives you for free. - **Least privilege and an audit trail.** Run it through the same identity path as the pipeline where you can, so there is a record of who did what. A long-lived personal admin key used to run a helper script is a bigger finding than the script itself. - **Revisit the reason.** Keep a note of *why* it is a script. Provider gaps close; when the resource lands, migrate it and delete the script. ## How to say this in an interview The answer interviewers want is not "never script" — that reads as dogma from someone who has not run anything. It is the boundary plus the discipline: **declare the things that should exist, script the things that happen, and hold the scripts to the same review, repeatability and audit standard as the declarations.** Then name one thing you would genuinely never declare, and one thing you would genuinely never script, so it is clear the line comes from experience rather than a blog post.