DevOps Interview Questions: Declarative vs Imperative IaC

Declarative IaC describes the desired end state — what the infrastructure should look like — and leaves it to the tool to figure out how to get there. Imperative IaC, by contrast, lists the explicit sequence of actions (create this, then configure that). Terraform, CloudFormation, and Pulumi's declarative DSLs are declarative; a shell script that runs aws ec2 run-instances three times is imperative.

Declarative IaC states the desired final state of the infrastructure (for example, three web servers behind a load balancer) and leaves the sequence of actions to the tool, which also reconciles drift when the real state diverges. The option describing exact ordered commands is the imperative approach, and the option requiring the operator to specify creation order step by step is also imperative in nature. The option claiming declarative IaC cannot be expressed as code files is false, since declarative IaC is written as code files such as manifests or templates.

This is false because a declarative IaC tool like Terraform only requires you to declare the desired end state, for example three web servers behind a load balancer. The tool itself computes the necessary actions, their order, and any reconciliation of drift. Specifying the exact sequence of commands is a hallmark of the imperative approach, not the declarative one.

Declarative infrastructure-as-code tools let you specify the desired outcome, and the tool works out the sequence of actions needed to reach that state. Imperative IaC, such as shell scripts calling the AWS CLI, requires you to write out each step explicitly: create the security group, launch the instances, register them with the load balancer, and so on. Terraform is a canonical example of the declarative approach, so the statement is true.

Declarative IaC tools like Terraform and CloudFormation let you describe the desired end state of your infrastructure; the tool's provider/executor computes the diff and applies the necessary changes to converge reality to that state. Imperative tools require you to spell out each step (e.g., create this, then update that). The option that says "A declarative tool requires you to write the exact sequence of API calls to reach the desired state, while an imperative tool lets you specify only the end state" reverses the definitions. The option that says "A declarative tool can only provision resources once and cannot detect drift on subsequent runs, whereas an imperative tool continuously reconciles state" is incorrect because declarative tools typically DO support drift detection on re-apply. The option that says "A declarative tool is always idempotent, while an imperative tool can never be made idempotent" overstates the claim — imperative scripts can be written to be idempotent, and declarative tools are not 'always' idempotent in every edge case, but the key distinction is the level of abstraction, not a guarantee of idempotency.

Declarative IaC describes the desired state rather than the sequence of operations. Because the tool compares the current state to the desired state and only applies changes where they differ, reapplying an unchanged configuration is a no-op, which is the hallmark of idempotency. The statement is therefore true. Imperative scripts, by contrast, may re-execute every step regardless of current state unless explicitly guarded.

Declarative IaC (Terraform, CloudFormation, ARM, Pulumi in declarative mode) defines the desired end state, such as three VMs with these tags, and the tool computes and applies the steps to reach it, reconciling on each run. Imperative IaC (shell scripts, aws cli sequences, manual docker run chains) gives explicit step-by-step instructions to reach the state. The option that swaps the two definitions is wrong, the option claiming a location restriction for each style is false because both work on-premises and in cloud, and the option claiming declarative is always faster per run is false because per-run speed is not inherently better for either approach.

Declarative IaC tools such as Terraform, CloudFormation, and Kubernetes manifests store or observe the current state and compare it with the desired configuration on each run. If the two already match, the tool plans no changes and the end state stays the same, which is the definition of idempotency. Imperative scripts do not perform this comparison by default, so re-running them can create duplicate resources or fail unless the commands are explicitly guarded.

A declarative tool must first load the desired state from the authored configuration, since there is nothing to compare until that state exists. It then compares desired state against the actual infrastructure (Terraform's plan step includes refreshing actual state) to compute the diff. Only after the diff is computed can it apply the changes that move the real infrastructure toward the desired state. Each step depends on the output of the one before it, so the order is strict.

This is the foundational IaC distinction. A declarative approach states what you want — 'three web servers behind a load balancer with this config' — and the tool diffs that desired state against reality and figures out how to converge (create what's missing, change what differs, leave correct things alone). Because the spec is the end state, re-applying it is naturally idempotent and the tool can detect and correct drift. An imperative (or procedural) approach states how: an ordered list of commands ('create server, then install package, then edit file') that you must make safe to re-run yourself, since the script doesn't inherently know the current state. Most modern IaC and orchestration tools are declarative for exactly these reasons — idempotency, drift detection, and reproducibility — while shell-style provisioning scripts are imperative. Knowing which model a tool uses tells you how it will behave on a second run.

The declarative approach is defined by the tool holding a model of desired state and recorded state (Terraform's state file) and computing a diff, so it only applies the delta; when the real infrastructure already matches the declaration, a rerun produces no changes, which is idempotency. Imperative Bash scripts issue a fixed sequence of commands with no memory of prior runs, so they are not idempotent by default and must add explicit existence checks to approximate the same behaviour. The statement about retrying CLI calls is wrong because retries do not make a create command safe to repeat, the statement about file order is wrong because Terraform builds a dependency graph rather than following file order, and the statement about scripts keeping a state file is wrong because plain Bash scripts have no built-in state.

The central difference is that declarative tools (e.g., Terraform, CloudFormation) describe the desired end state and reconcile toward it idempotently. Reapplying the same declaration yields the same end state because the tool diffs current state against desired state and only makes the changes needed. Imperative tools (e.g., shell scripts calling cloud APIs) encode the exact sequence of commands to reach the state; nothing inherent guarantees idempotency, so the author must add guards or conditional checks to avoid duplicating resources or re-running destructive steps. A strong answer therefore names idempotency and contrasts desired-state specification with step-by-step specification.

Terraform is declarative: it maintains a state file and compares the actual cloud resources against the desired configuration declared in HCL. On re-application it computes a diff and produces a plan showing what must change to converge reality toward the declared state, including detecting the manually added ingress rule as drift. The imperative bash script has no such state model; it re-runs each CLI command in order regardless of what already exists. Without explicit existence checks (which the scenario rules out), the script cannot detect the manual change, may error on resources that already exist, or may run commands that succeed or fail without any awareness of the extra rule. The core distinction is that a declarative tool with state enables drift detection and idempotent reconciliation, while an imperative script without existence checks cannot detect or undo out-of-band changes.

During a default terraform plan, Terraform performs three steps: (1) it refreshes the state file by querying the real infrastructure to capture the current actual state of each managed resource, (2) it reads the .tf configuration files to determine the desired state, and (3) it computes a diff between the refreshed state and the desired configuration, presenting the result as an execution plan. The claim that the state file defines desired state is wrong because the state file does not define desired state (the configuration files do), and plan never modifies resources—that requires apply. The claim that Terraform only queries real infrastructure during apply is wrong because Terraform queries real infrastructure during plan via the refresh step, not only during apply. The claim that the state file is merely a performance cache is wrong because the state file is not merely a cache; without it, Terraform has no mapping between resource blocks in the configuration and existing real resources, and would attempt to recreate everything, likely failing on name conflicts.

Terraform's declarative model means each invocation refreshes the recorded state against the real resources, diffs that against the declared configuration, and produces a plan containing only the changes needed to converge, so an interrupted run can be re-applied. An imperative bash script executes commands sequentially, so a re-run repeats completed commands and can create duplicates or fail with 'already exists' errors unless each command has an explicit idempotency check. The other statements are wrong: neither approach provides automatic rollback or atomic all-or-nothing provisioning, and it is Terraform, not the bash script, that maintains a state file.

The state file is what makes declarative IaC fundamentally different from imperative scripting. First, it binds declared resource addresses to real-world cloud resource IDs; without this mapping Terraform cannot know which aws_instance.web refers to which EC2 instance, nor which resources to destroy when a block is removed from configuration. Second, it records last-known attribute values and dependency metadata, giving Terraform a baseline to diff against the desired configuration. Drift detection then relies on refresh: on a normal plan Terraform queries the provider for each managed resource's current attributes and compares them with the recorded state and the desired configuration, so out-of-band changes surface as planned changes. An imperative script using the AWS CLI keeps no persistent record of what it created or what attributes those resources should have, so it cannot detect that a resource has been modified out-of-band.

This is an open design question with no single key, so it is graded by keyword matching on the four required aspects: import mechanics (terraform import or import blocks, with no recreation and a clean plan as verification), remote state with locking (S3 plus DynamoDB or an equivalent backend), coexistence during transition (group-by-group migration with no dual management), and drift prevention (CI plan gating, restricted manual access, and scheduled terraform plan -detailed-exitcode checks). A strong answer names concrete mechanisms for each of these rather than saying only that Terraform will be used. The keyword rule requires the import, plan, and locking terms, plus at least one drift or pipeline term.

This is an open senior-level design question with no single key, so it stays SHORT_ANSWER and is graded by keywords plus the sample answer. A strong answer draws a principled boundary: declarative tooling for idempotent steady-state resources with plan and drift detection, and imperative logic confined to runtime-dependent ordering and external API gaps. It manages state remotely with per-account and per-environment isolation and scheduled drift checks, and it layers the codebase so foundational outputs feed service-layer inputs. For the ordering scenario, the sample answer correctly places the propagation wait in an orchestration layer rather than assuming a data source's depends_on will wait for routes to converge.

In Terraform's declarative model, plan always begins with a refresh phase that queries each provider's Read to sync the state file with real-world cloud state. After refresh, Terraform diffs the refreshed state against the configuration to determine what actions are needed. When drift has occurred (an attribute changed out-of-band), the refreshed state diverges from the config, producing a non-empty diff. For a mutable, non-force-new attribute, that diff resolves to an in-place update — Terraform will modify the existing resource to match the declared desired state. If the attribute were force-new, the plan would instead show a destroy-and-recreate. The key insight is that declarative IaC tools converge actual state toward declared state on every run; they do not treat 'configuration unchanged since last apply' as a reason for a no-op when the real world has drifted. This is the core distinction from imperative IaC, where there is no persistent state mapping and no automatic drift detection or reconciliation.

This is an open system-design question with no single correct implementation, so it stays a short answer graded against its rubric rather than a fixed key. A strong answer must (1) separate a declarative desired-state layer (Terraform for infrastructure, a GitOps controller for application manifests, all desired state in Git) from the runtime layer, and show that rollbacks, canary shifts, and emergency scaling are expressed as desired-state fields the controller converges on rather than raw mutations it fights; (2) specify automated drift detection with a defined cadence, namely continuous GitOps reconciliation plus a scheduled Terraform plan for infrastructure drift; (3) define emergency guardrails that are time-boxed, audited break-glass access, a way to pause reconciliation per workload, and a mandatory post-incident Git commit; and (4) give an ownership model that distinguishes who owns desired state (platform team for infrastructure and GitOps configuration, application teams for charts and release manifests) from who makes the runtime reconciliation decision during an incident (SRE on-call).

Both Terraform and a GitOps controller are declarative: the engine derives the steps from a declared end state, so the option claiming Terraform is imperative is wrong, and the option saying the user writes ordered commands in both tools is wrong for the same reason. The real architectural split is execution model and state handling. Terraform performs a one-shot plan-and-apply that diffs against an external state file it depends on. A GitOps controller runs a continuous loop that re-derives drift on every iteration by comparing Git-declared desired state with the live cluster API, and it does not need a separate Terraform-style state file. The option saying a GitOps controller stores no state at all is wrong because controllers persist status inside Kubernetes (for example Argo CD Application status or Flux resource state in etcd), and Terraform does not keep its state in etcd. The push-versus-pull delivery model is orthogonal to this distinction.

In a declarative IaC system that maintains state (Terraform, CloudFormation), removing a resource block from the configuration signals that the resource is no longer desired, so the next apply schedules its destruction — this is the defining lifecycle behavior of stateful declarative tools. Imperative provisioners (such as Terraform's local-exec/remote-exec) run on creation or destruction triggers, but their effects are not tracked in the tool's state, so repeated applies may not converge to the same result, breaking the idempotency guarantee that makes declarative IaC valuable. The tool can only reconcile what its provider schema models: if a resource attribute is mutated externally in a way the schema cannot represent (e.g., database schemas inside an RDS instance, in-cluster Kubernetes objects), the tool will not detect or correct it even after a refresh. Drift detection is therefore still necessary, contradicting the claim that reconciliation is automatic. Resource creation order is determined by the dependency graph derived from implicit references and explicit depends_on, not by the order of blocks in the configuration file.

This question tests the boundary of declarative IaC: the tool reconciles only what its provider models. Schemas, extensions and roles are not in the RDS provider's API surface, so they need either an external migration tool run by the pipeline or in-band provisioners. Both patterns move state outside Terraform's state file and refresh loop, so plan cannot see schema drift and repeated applies cannot converge that state. The lost guarantee is convergence (idempotent drift detection and correction) for the internal database state.

This is an open design question with no single correct answer, so it is graded against the sample answer's content rather than a keyed option. A strong answer must name the exact boundary between Terraform-managed infrastructure (networking, IAM, EKS clusters, RDS instances) and imperative or self-reconciling layers (in-database schemas, roles and extensions via a migration tool; cluster add-ons via Helm and ArgoCD), state explicitly what guarantees are lost there, and separate state by account and tenant to bound blast radius. It must also give a concrete drift workflow (scheduled plan with detailed exit codes, ticketing, codify-or-revert) and honestly acknowledge what the Terraform-based detection cannot observe.

This is an open staff-level design question with no single fixed answer, so it stays a short-answer item graded against the sample answer and keywords. A strong response must name a concrete import mechanism (terraform import plus plan-driven reconciliation) rather than hand-waving migration, identify where pure declarative fails (ordering-dependent peering routes, stateful RDS with out-of-band schema migrations) and prescribe real escape hatches such as depends_on, local-exec or null_resource triggers, and CI-driven migrations. It must also include an ongoing drift process (scheduled plans with alerting and ownership) rather than a one-time import, and protect stateful resources from destructive replacement via prevent_destroy, ignore_changes, and gated blue-green cutovers. A answer that simply says to rewrite everything in Terraform fails the stateful-resource and escape-hatch criteria.