Specify the desired system state in a readable, maintainable format.

Convey configuration intent without specifying imperative steps.

When configuring infrastructure, deploying applications, configuring services, or defining environment variables.

DevOps, infrastructure as code, configuration management, CI/CD pipelines, cloud provisioning.

declare desired state → let the system reconcile to that state

• YAML
• JSON
• HCL
• Terraform
• Kubernetes manifests
• CloudFormation templates

• imperative scripts (e.g.
• Bash
• Ansible)
• procedural code in languages like Python or Go

1. Assuming order of keys matters → leads to nondeterministic behavior; 2. Omitting required fields because defaults are unclear → runtime errors; 3. Over‑specifying low‑level details → loses benefits of abstraction; 4. Mixing imperative commands inside declarative files → creates maintenance confusion

imperative configuration – focuses on how, not what; configuration management tools (e.g., Chef) – often imperative; declarative UI frameworks (e.g., React JSX) – similar concept but for UI

Coming from Bash: you may write sequential commands assuming execution order → declarative configs treat entries as unordered; Coming from OOP languages: you might expect methods inside config files → declarative formats only describe data

• imperative configuration
• infrastructure as code
• configuration as code
• declarative syntax
• configuration file

Do not use when fine‑grained runtime logic is required; Declarative configs are usually idempotent and cheap to apply, but large diff calculations can be costly; Some systems require all fields to be present, otherwise defaults may cause subtle bugs

Ensures infrastructure state converges reliably, reduces drift, and simplifies version control of environments

Think of a recipe that lists the final dish ingredients, not the cooking steps

Declarative configurations are typically idempotent, making them safe to reapply

imperative configuration